Posts Tagged ‘akonadi’

The Task-Oriented Revolution

12th January 2009

TheBlackCat posted this on an earlier post on this blog, and I thought it was worth sharing more prominently:

What I think will be a key revolution KDE will bring about is the task-oriented desktop. Plasma, Akonadi, Nepmuk, these are all parts of that. It will make computers smarter. Up until now computers did not care what you are doing, they cared about what you were using to do it. They organized themselves around what program you are using, not what you are doing with that program.

But people have different programs to accomplish the same task, and tasks often involve multiple programs. A computer that knows what you are doing and reorganizes itself to make that task easier is a huge leap forward in the way we work with computers. The Office 2007 ribbon interface is another example of that, but it is still embedded in the application-oriented desktop paradigm we have had up until now. It can even be taken a step further, allowing a computer to learn how you like to do certain tasks and organize itself appropriately. For instance such a computer could realize when you are chatting with your IT guy for a certain amount of time you generally pull up certain configuration programs, send him an email with an attachment, and check certain system monitoring applets. Let me get that all ready for your and stick them on a virtual desktop so you can get to it easily. KDE 4 provides the potential for a computer that automatically adapts itself to your work flow instead of you having to adapt yourself to its work flow. Imagine the benefit to businesses if you don’t have to train users to work with the system, the system will train itself to work with the users.

Everybody has different ways they like to do different things, but up until now the best they could do is try go set up their their desktop as best they can to make their most common tasks as easy as possible within the limits imposed by the system. Most people do not even bother to take advantage of the limited abilities their system provides, they simply use the default configuration. They never learn how they can modify and improve their computer experience, their efficiency, and their enjoyment. But a system that knows what users are trying to do, how they like to do it, and knows how take advantage of its own abilities to make those tasks easier would not need to rely on users spending the time and effort to learn the intricacies of the system, it would simply provide what they need when they need it.

Such a system requires four parts, I feel. First it needs a flexible and easily adaptable desktop. Plasma provides that. Second it needs something to track the relationships between data. Nepomuk and akondi provide that, or will soon. Third it needs programs that are able to understand how you perceive their relationship with the data and with each other. As I understand it is this is a major goal of KDE 4 over the long run.

Finally it needs to understand how you like to physically interact with the computer’s hardware. This, I feel, is still where KDE has serious limitations, and I think it is holding back the flexibility found in the rest of the desktop. The ability to configure the UI is amazing, but the ability to configure how the computer’s hardware interacts with and impacts the UI is very limited. Essentially we have keyboard shortcuts, that is it. Little else can be configured by the user.

The way we interact using the mouse is not flexible at all, we have three buttons and a scroll wheel. Modern mice generally have at least 5 buttons and a tilt wheel. The ability to dictate how the mouse interacts with the computer is pretty much limited to touching screen edges to activate a couple of effects, dragging windows across virtual desktops, and a few button presses on windows titles. Shortcuts involving mouse buttons are essentially unsupported. The ability to dictate how certain modes of interaction using the mouse effect the desktop environment is limited, in the relatively few cases where mouse interaction is configurable at all it has at most a couple of options.

Compiz has fairly extensive mouse interaction configuration, allowing pretty much any mouse button to be combined with a modifier key to control most aspects of the window manager. Windows 7 has some interesting ideas about moving windows, like the shaking windows to minimize others and dragging windows to screen edges to maximize them across half the screen. Of course certain people may not like these specific interactions, and in Windows 7 they do not appear very flexible, even compiz does not really support combining keyboard and mouse button presses beyond the use of modifier keys. But in KDE 4 the ability to dictate what effect a certain mouse interaction with a window or with a desktop will have is practically non-existent if you compare it to those examples, and is even more striking next to the extreme flexibility of the rest of the KDE 4 experience. So I think it important to be able to tell the system things like “shaking a window will have this effect”, “moving it to a screen edge will have this effect”, “tilting the scroll wheel left on the desktop will have this effect”, “meta+C+mouse button 5 on an applet will have this effect”.

This is even more limited when it comes to other types of devices. For instance there is no way at all to dictate what pushing a button on a joystick or a bluetooth device will do. They are simply not integrated into the KDE desktop interaction framework at all.

Another biggie that KDE, and Linux in general, essentially does not have at all is voice interaction. But I think this is an extremely natural way for people to interact, giving vocal commands is something people learn from a very early age. It is something that Microsoft has been working hard on supporting, and even most modern cell phones have it, but Linux in general and KDE in particular does not. Things like launching programs, switching desktops, and organizing windows seem particularly suited to voice commands since they are fairly simple and generally do not do anything terrible if there is a mistake.

The output side of hardware interaction is important as well. An example is having the computer know which printer you like to use when doing certain tasks (for instance a black and white office copier when printing PDFs, a color inkjet printer when printing photos). Or knowing that when you go into full screen when viewing a photo you want it to go full screen on your monitor, while if you set go into full screen mode with a video you want it to go full screen on your TV. Phonon and Solid seems to be trying to provide this to the Audio side of things, but it has applications for just about any output device.

Once you have the framework for being able to have a flexible method of interaction between input devices, output devices, programs, the desktop, and windows, it should become much easier for the computer to learn how you like to interact with it and adapt appropriately. For instance it could learn that when you are working with a text document and push the “play” button on your lirc remote you want amarok to open and start playing music, but if you stick a DVD in the drive and immediately after push the same button you want to open Dragon Player and play the DVD. It is extending the task-oriented desktop to the hardware side of things, to learn not only what you do and the process you use to do it but also what devices you use in that process and how you use them.