On Mon, Dec 20, 2010 at 8:55 PM, Celeste Lyn Paul <cele...@kde.org> wrote: > Hi Everyone, > > This is information on a UX Developer Sprint proposal in Spring 2011. > Feel free to forward or add whoever you may think would be interested > in this sprint. An organization wiki page is located: > http://community.kde.org/Sprints/UX2011 > > The purpose of this sprint is to provide an opportunity for unbridled > creativity and hacking on new and old KDE user experience (UX) > problems. The goal is to produce 3-4 design specifications and code > prototypes of new interaction and interface concepts that could be > integrated into KDE. This is an opportunity to be part of a innovation > that could lead to the next generation KDE. > > Anyone who is interested should think of at least one idea or concept > they would like to explore during the sprint. The idea can be all but > a twinkle in your eye, or a series of hard requirements. You will be > able to present your idea in a group discussion. We will choose > several topics to explore in more detail, eventually leading to > actionable design specifications and prototype code. > > In many ways, I believe this sprint could fit into Aaron's Elegance > vision from Akademy 2010. Here are two examples of concepts I would > bring as my discussion topics: > > * Integration of webservices in a useful way > We have apps that are desktop portals to data on Facebook and Flickr, > but we don't do anything interesting with it. To remain relevant we > have to use the web, not just interface with it. Why can't we connect > to Facebook as a calendar resource, or add Flickr as a seamless image > location in Digikam and Gwenview? > > * Keeping up with current trends: > We need to consider next-generation toolbars, menus, and windowing. > Browsers have been slowly evolving to optimize toolbars and tabs in > the interface, but other apps remain archaic. Microsoft has worked out > kinks in its "ribbon" toolbar design in the next generation of > productivity apps. We've had very interesting proposals for flexible > UIs and alternative menu designs. Why don't we take a serious look at > proposals like this to see if they are the future? > > My vision for this sprint isn't necessarily to solve existing > problems, but to think forward. KDE 4 is stable. We now have the > freedom to hack and experiment for the future. > > Activities include brainstorming, designing, prototyping, and architecture: > > * Brainstorming: I've provided a sample list of "holes" to fill. What > else could we do? How would we do it? > * Designing: What are possible ways we can provide new ways to > interact with and experience KDE? > * Prototyping: Let's see these ideas in action and code out some of > these problems. What would our ideas look and feel like in KDE? > * Architecture: What new technology needs are there to support our > ideas? Do we need widgets? Libraries? Or just a standardized way of > doing things? > > Sprint deliverables could include: > > * Design mockups exploring new interactions > * Technical specifications for new technology > * Prototype code demonstrating new ideas > > There is no date yet, other than Spring 2011. If you are interested, > please add yourself to the participant list on the wiki page with > possible dates. Also add a topic if you have a particular stone you > would like to crush. If you have any questions about the sprint, or > would like help coming up with a personal topic, feel free to ask. > This is a great opportunity to get a diverse group of problem solvers > together to create something new and shiny. Maybe your idea might even > turn into the next KDE gem :) > > Cheers, > > ~ Celeste
If you want some suggestions for topics, I have quite a few, although I am not necessarily sure all are necessarily right for a usability sprint: I wrote a pretty extensive essay on the limitations of input devices with KDE: http://neverendingo.blogspot.com/2010/11/matter-of-control-state-of-input-device.html There are also more clearly usability-related issues with the configuration tools currently available. In my opinion this is the single biggest flaw in all of KDE, but I appear to be in the minority on that. Your idea about integration of web services is good. I suggest looking at this brainstorm idea, which deals with those very issues (this isn't may idea, but I think it is a good one): http://forum.kde.org/brainstorm.php#idea87355 The idea and discussion is about sing kio to allow easy access to web services like web storage, image hosting, and so on. I think it touches on another issue: kio slaves are pretty under-utilized in KDE. They provide a lot of potential for seemlessly integrating services, local and online, into your file browser, but there are few available outside of dedicated network share access. As an example, there are kio slaves for a couple compressed file formats that let you seemlessly browse those folders as though they were files, but the vast majority of compressed file formats lack kio slaves (or better yet, a single kio slave to handle all compressed files). Similarly, the kdropbox interface does not provide a kio slave. The KDE DVD players and rippers do not provide KIO slaves. k3b does not provide a kio slave for simple burning options (which puts KDE behind even windows XP for simple burning operations). KIO slaves could provide more flexible access to the Favorite Applications and Recent Documents list used by the plasma application launchers, as well as the Create New Documents list used by Lancelot. There is also the issue that KDE kio slaves cannot be used by non-KDE applications, including both GTK and command-line apps, severely limiting their usefullness. This could be resolved with a kio-fuse bridge. Some other topics: Integrating your data. Currently information about you and your files is spread over many largely disconnected resources. Your amarok and digikam albums are totally disconnected from your nepomuk data. Your ratings of pictures in flickr and imageshack are not connected with your rating of the same pictures on your hard drive. I think this encompasses two different issues. First, finding out what is preventing other KDE projects from integrating with your nepomuk data store and resolving these issues. (I know, for example, that excluding speed, one big issue is that nepomuk cannot write data to files like pictures and music that store their own metadata). The other is extending your metadata store to your online presence. The latter, however, also has privacy concerns, which makes it somewhat of a complicated issue. Cooperation with other projects. What are the areas where KDE and other open-source projects, like Gnome, are still not working well together? What are the areas where KDE does not integrate will with non-Linux platforms like windows and mac? How far is KDE willing to go to work well with other platforms and projects, and where does KDE draw the line and say that it is sticking to its own way of doing things? KDE configuration. KDE has been working hard on getting configuration simpler and easier to use, but this still is a source of complaints. Although, at least to me, it is easy to move around KDE configuration tools now that I am used to it, I understand that it takes some getting used to for new users. How can existing configuration tools be improved to make it easier for people to find what they want? Over at the KDE forums, I very often see requests for features that are already implemented, either because it never occurred to them it might be an option, they see the option, didn't realize it was what they were looking for, or looked in the wrong place. How can we let people know that something can be changed, and where to change it? Is there a more radical departure from the existing configuration paradigm that might benefit KDE? There have been suggestions about more tightly-integrating short screencasts showing how to do things, while another option might be taking over their mouse to show them what they need to do. Protecting your data. Currently there is a lack of a good, integrated backup solution for KDE. Several projects are underway, but none really integrate deeply with KDE technologies like KIO and all have various limitations compared to competing backup solution like time machine. Key parts of KDE like akonadi and plasma lack backup solutions at all, while others like nepomuk are getting them soon. There is also no way to easily backup and/or transfer your settings (see here: http://forum.kde.org/brainstorm.php#idea86270). Those are some ideas I came up with. Besides the input device and kio slave ideas I am not sure they exactly meet the goals of the sprint, though. But I hope at least a few are helpful. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
