NOV
17
2003

How to take user requests and innovate with them

Did users ask for Expose?



Yes, they actually did. Most likely they didn't think of this kind of solution, but its intuitiveness even though it is an unpreceded feature, as well as the positive feedback shows that it is something which was wanted. The problems for which Expose is a solution are: How can I find a window by its look? and How can I get a quick overview over all of my desktop(s)?. There already exist several approaches to solve one of those two, Kasbar's windows thumbnails tooltips, KPager desktop thumbnails, OS X's genie effect for minimized windows, to name but a few.



Expose is innovative in that that it takes the technical capability of Quartz (smooth scaling of whole windows) for offering a combined solution for both problems at once, giving an overview over the whole desktop as well as allowing users to recognize individual windows without much of additional abstraction. With Expose Apple is here leveraging some backend features they previously introduced to OS X for offering a completely new user experience.



The same is what KDE is starting to do now. Before the work within KDE was mostly focussed on the backend, the framework, building flexible and easy to use tools for developers. This backend is now being leveraged by more and more applications, Konqueror and Kontact being the most apparent examples. We can now proceed leveraging KDE's backend while trying to solve multiple existing concerns by users. In the best case this will offer innovative and practicable solutions for all users. In the worst case we will still have examples of the power of KDE's backend. Most important is that we make potentially useful (combinations of) existing features visible and accessible to users.



I'd like to show several examples using new components which will be included in the upcoming KDE 3.2:



The first one is Khotkeys2, included due to the never stopping stream of requests for mouse gesture control in Konqueror (a la Opera). Khotkeys2 offers support for custom shortcuts and for custom mouse gestures system wide, not only in Konqueror. Combined with the within KDE widely used DCOP this will allow users to optimize their workflow. This new addition is potentially usable in innovative way by combining mouse gestures with alternative pointer devices like touchpads, tablet system and many others, giving access and control to parts of the system which were not as accessible with the previous pointer support alone.



The other one is the Universal Sidebar kicker extension. By itself, being exactly the sidebar users see in Konqueror already, it might not be very interesting. But the potential applications for the Universal Sidebar as a globally acessible area like the tasbar are manifold:

  • Offering a contact/address list as sidebar tab: Combining the IM contact information by Kopete with the additional address information by KAddressbook as well as email checking/writing offered by KMail. This would be a good starting point for anything related to sending/receiving messages and could integrate other things like KMLDonkey's friends list or any kind of web boards and news feeds. The "innovation" of this would be: You have one single global place where you are informed whether you got new mails, messages or news, and can start the respective task from there.
  • Offering a Klipper sidebar tab as replacing for the current kicker/systray applet: So far Klipper is pretty infamous for its 'actions', and many users stop using Klipper completely even though its non-apparent clipboard history list could be very useful. Klipper as a sidebar could make the clipboard history list globally visible and accessible without further click. Every single clipboard entry could be showed as thumbnail in a speedbar alike interface, the user can then click/drag'n'drop the entry he wants to use or right click it for a lit of possible Klipper action commands. The "innovation" of this would be: Klipper is no longer hidden away but can directly show what it has to offer, making it more vissible and predictable, and thus usable for more users.
  • Offering a progress/network operations sidebar tab: Currently there are many different windows shown when you move/down-/upload files, Konqueror has its progress dialogs which can be combined in one window, KGet has its more advanced but separate window for progresses, so do Kopete, KMLDonkey and other similar applications. These all could be combined in on global list, eventually also showing in-window progresses of other applications like KMail and K3B etc. To make it even more abstract and schedule like it could also include any planned actions by Cron alike applications or to-do and reminder entries in KOrganizer and KAlarm. The "innovation" of this would be: You have one single global place where you can watch and manipulate any kind of schedules and progresses and can start the respective task from there.



Conclusion: There is certainly no lack of ideas for new features and so called "innovations" and there is certainly a lot of useful backend features in KDE which are not really exposed to the user yet. The most important part is however that the resulting graphical interfaces exposed to the average user is both logical and easy to use, only then he might try them and consider them useful. Expose showed how this can be done, successfully combining existing approaches to solve the mentioned two problems while being more logical and easy to use. I'd like KDE to show that this can be done in other areas of the GUI as well.

Cheers.

Comments

Did users ask for Expose?
Yes, they actually did. Most likely they didn’t think of this kind of solution, but its intuitiveness even though it is an unpreceded feature, as well as the positive feedback shows that it is something which was wanted.

But how can you find this out without trying? Take WinFS as an example. I am convinced that, when implemented well, it will make it much easier to find documents on my disk. Luke thinks the opposite. (see the discussion on http://www.kdedevelopers.org/node/view/237). So what's the solution? The only solution that I see is to try it by implementing and hope that its useful. A good prototype may be enough, but it needs to be implemented well and you need some real life experience before you really know it (or alternatively, wait until Longhorn is out).

Aaron suggested that some people implement features only for the sake of having them. I don't think so that anybody does that (with some exceptions to the rule). Every significant feature is a investment, and you don't do this lightly. When you invest in a feature with your time or money, then your are convinced that people will use it. In some cases you may be wrong, obviously, but in general all features are written because somebody thinks that they will be useful. In other words, all features are written *for* the users. The users just don't like each of them.


By tjansen at Mon, 11/17/2003 - 00:56

I am also convinced that, when implemented well, a goggle search approach will make it easier for me to find documents. One good indication that I could need it is the fact that, when searching for a specific text, I'm often using the containing text search field and keeping it running until the text file I wanted appears. That approach is currently very time consuming and error prone, and I guess it could easily be replaced by a Storage system. I also often find myself reluctantly using the open dialog for browsing until I find the wanted file. There I always wish for some kind of embeded search which would simply list all compatible files on the whole system at once to look through instead just browsing through the folder "noise".

The question whether both use cases are common is an interesting one though. On the one hand computer newbies will most likely place all files to only one location, and look for them only there. They will get lost as soon as someone refers to another non-apparent location. They will probably also get lost when the amount of files is getting too much for them to handle. In these cases the user don't care about hierarchy, so the googling approach might suit perfectly. On the other hand there is so far the implicit expectation that everyone is settling to an own hierarchy system after some time, naming and sorting files how he thinks it fits best and starting using folders depending on the amount of files. After such an approach I'd expect them to consider the idea of googling through this hierarchy as unnecessary and even excrescent, but this will only apply to the one person who set up the hierarchy.

I also wouldn't think that anyone implement features only for the sake of having them, I'd expect the one who implemented it to have used it at least a couple of times. But I also don't think users "don't like" some of the features, I'd just expect them to ignore them when they don't know what it is for and how it could be useful for them. One good example is Konqueror's book called menu, it is pretty cramped with many useful tools and options, but they are only starting to be useful for someone when he learned how they can be used usefully for himself. This state asks for more promotion and publicity of specific features. (I'm not asking for a menu redesign, I very much like the way it is. :) I'm also a fan of Mac style menus at the top of the screen and always set up my KDE this way though. ;))


By Na at Mon, 11/17/2003 - 02:07

i didn't quite say that some implement features for the sake of having them; i said that some people chase after the ideas in other systems purely as a way to be able to say "look, we have that feature too". for example, when WinXP came out we were inundated with requests to make the KMenu into a WinXP style menu; since that design has several problems, there is no reason to do this aside from the fact that WinXP has it.

i also stated that it isn't wrong to copy from other people's ideas. perhaps the WinFS idea is a great one, and perhaps we should create something similar. we've done this with many other features/programs in KDE, and it has often worked out well.

but often times we as tech people have this urge to create just because we can, or just because someone else has the same thing (even if it doesn't work for them!). every time we create something like that in KDE, we saddle ourselves with a bit more cruft. fortunately, i don't think that happens very often at all in KDE. i do, however, think that projects such as Mono are very much a less-than-useful knee-jerk reaction.

in your Mono blog (heh) you spoke to the dangers of cloning so as to make something only as good as what else exists; i offered the (non-original) alternative concept of creating based on user need.


By Aaron J. Seigo at Mon, 11/17/2003 - 18:50

@ the google-bar/winFS/Storage point: I think there should be some other way of searching files. Storage and winFS are indeed ways in which gnome resp. M$ try to solve the "I cant find my file" problem. Imho Storage is much better, esp because of its time-related feature (you can go back in the 'past' of a file, to see changes in its contents), and its natural language interface ("I'm looking for the file I created yesterday about cars" will work).

But I think reiserFS 4 whould be able to do what Storage does, and faster. Of course not the natural language part...

Being able to find a file using an google-like textsearch, combined with natural language and time ("the file I created YESTERDAY") whould help users, im convinced about that.

I think M$ and Macintosh can implement these kind of things easier than OSS can - KDE should work together with reiser and the distro's (cuz the distro's should go using reiser, which alot users whouldnt want) and thats difficult.

Anyway, making such a thing (google-like feature to find files and words in konqi pages (wheter html or maps), natural language search, history of files (save undo info?)) - I think that whould be 'new' and 'improved' - it improves usabillity - so it might attract users, and make ppl say - hey, these KDE ppl - they are inovative!

And thats what you guys want, isnt it? :P


By superstoned at Tue, 11/18/2003 - 13:09

A little while ago, I suggested embedding Kopete into Konqueror's sidebar pane: http://bugs.kde.org/show_bug.cgi?id=63516


By eike hein at Tue, 11/18/2003 - 18:43

>Combining the IM contact information by Kopete with the additional address information by KAddressbook as well as email checking/writing offered by KMail.

We at Kopete have started on this combination. In KDE 3.2 Kopete will be able to associate IM contacts with KAddressbook entries and use the KAddressbook name as the contact's display name when chatting.

The next stage will be allowing other apps access to Kopete's presence and messaging functions, either via an expanded DCOP interface and a client library, or a Kopete Part.


By Will Stephenson at Thu, 11/20/2003 - 20:01