There has been a lot of focus on the desktop lately, and how the desktop should evolve. Rephrasing the questions: what can/should/might KDE 4 become? There are many good ideas out there, some of which I hope will get implemented. But there’s also things I miss in the current debate, things that deal with the fundamentals of desktop computing. What a splendid opportunity to write my first blog entry, I thought, and so I did.
Some background for this article: I had the opportunity to observe an untrained desktop computer user doing real work using KDE 3.4 and Open Office. I also had the possibility to make suggestions to the workflow. The task was straight forward: Someone was sending dozens of doc files as e-mail attachment, and expected translations back. As easy the task sounds, I was surprised about the challenges that desktop computer users do face. I believe I learned valuable lessons from combining that experience with prior observations, and I would like to share my thoughts with you. In case you are a KDE developer who hasn’t yet had a chance to spend some time watching non-techie users using computers, please try to. It’s worth it, and it’s fun, no matter what desktop system they are using, KDE, Windows or Mac OS X. Watching real users doing real work on real computers is likely the best way to gain the experience necessary to create the next generation desktop system. I don’t want to read a manual before using a mobile phone, or operating a DVD player, and I don’t have to. Sending an email, receiving some files, translating them and sending them back is in the same league of complexity, and it shouldn’t require extensive training, or the need to understand how the system works under the hood.
Window management
Nobody likes to do window management. Wirth was right, although few people believed him when he designed Oberon. Users seem to go a long way to avoid having to adjust a windows position or size manually. This isn’t just untrained users, this is everybody. You can observe the same patterns on hackers everywhere. They sit in front of 20″ screens staring at a 1600×1200 background image and then typing commands in an 80×25 text window with a tiny font, having to scroll up and down all the time to read the output. It takes significant pain before someone actually uses the mouse to maximize the window vertically, or puts it to a more central spot on the screen. The same happens with other users. They go a long way scrolling around in a tiny file manager window before they might decide to make the window larger.
Lesson learned: the ideal window manager is the one that you don’t use at all. This needs support from the applications. Applications don’t normally start up with a sane size. Maximizing isn’t always the solution, especially because the most often used applications don’t work very well when being maximized, among them web browsers, consoles, plain text editors (think an email composer). Every application that does line breaks based on the window width has this problem.
Another problem with window management today are secondary windows, also called dialogs. In KDE, we try hard to bind those closer to the application main window. For example, a dialog doesn’t have its own entry in the taskbar; when you raise a task, its dialogs are kept above the application main window; when you minimize a task, you also minimize its dialogs. But the connection isn’t perfect. While dialogs are placed in the middle of their main windows, they don’t adjust position and size when you resize or move the main window. And when you try to activate a modally shadowed main window, the only visual clue you get is that nothing happens. Ideally, dialogs and other stand-alone secondary toplevel windows should go away for standard end-user applications. Having things like Apple’s sheets and drawers that naturally extend and modify the main window itself feels more natural, more elegant and avoids confusion.
Configurability
What I said about window management also applies to configuration. Nobody likes to configure anything. Sometimes people like to customize something, but that’s different. Customization means giving the computer a personal touch, with colors, images, or sounds. Changing the computer’s behaviour is entirely different. Configurability is costly, because it’s code that must be maintained, and it’s getting harder and harder to test all combinations. Even KDE’s own file dialog doesn’t work properly with all the 6 different completion modes that KDE offers for combo boxes. In DropDownList mode, you can no longer navigate with the keyboard to sub directories. Likely an easy bug to fix, but that’s not the point. The point is that with all that configurability, even a community that diverse and large as KDE’s cannot ensure basic functionality working in all modes. KDE 4 is our chance to get rid of all that clutter, I hope we make use of it. “Those who write the code, decide” is a good rule, but it only works if there is a strong maintainer or group of maintainers with a clear and aligned vision. Many parts of the KDE had this, others didn’t. And that’s where we see the issues today.
File manager
Konqueror today is a swiss army knife. That’s cool, people like swiss army knifes. I used to have one, too, and I loved the engineering behind it. Putting so much functionality in one single device is admirable. But I never used it unless I absolutely had to. At the campfire I had to, and I was happy to have it. At home or in my kitchen, I don’t have to. Instead I use whatever knife, screwdriver, or other tool that fits best for the job.
A document manager is not a webbrowser is not a text editor is not an image viewer is not a console is not a trash bin. Profiles are a way around it, but not the solution. Profiles are just like opened swiss army knifes. It’s like buying 4 swiss army knifes and having one lying around as a knife, one as a saw, one as a screwdriver, and one as scissors. Whatever you do to them, they are still swiss army knifes. They can magically convert into something else, and they will if you do something to them.
I get the feeling we do embedding and morphing not because its useful, but because we can. And we are ignoring its downsides. And the biggest downside in my opinion is that it takes mindshare away from dedicated applications which would do the job better.
A little example: you have a browser window that covers 40% of your screen, it contains pictures that you have taken over the weekend. You want to show them to someone else. In KDE today you would probably find an empty spot on the icon view, and then select Preview_In/Photobook. Or you are one of the few chosen ones that know the icon on the toolbar. What you then get is a fairly good embedded image viewer, but it’s still only an embedded image viewer. And it’s only using 40% of your screen. You can then maximize the window, or - if you are an expert power user - select Settings/Full_Screen_Mode. I found it after looking under “Window” and “View” first, by accident. But even then you don’t see any image in full size, you see Konqueror in full size. You still see the side bar, the navigation bar, and a tool bar. Here’s how it should be (and surprisingly this is also how Windows Vista works): Having images in folder results in little button that says “View slideshow”. You click it, you get a full screen viewer that shows your images. Simply, intuitive, what you want, what you expect, and no window management action required.
Konqueror’s future is being a dedicated web browser. What KDE needs in addition is a dedicated document manager. Great preview capabilities, yes, embedding, no. Konqueror is not a document manager, it’s a generic tree structure browser. And if all you have is a tree structure, everything looks like a kio-slave. Our trash bin in KDE 3.4 is a nice example for that rule: it’s a full blown browser window that uses the trash:// protocol. And the one main operation that you want to do with a trash bin (emptying it) is only available in the context menu of the icon, or the free space in between the items. Who is supposed to find that?!
I’ve been discussing design ideas with Zack and Simon, and hopefully we are able to present a prototype of how a modern file manager for KDE 4 could look like. And if that’s done properly, the desktop itself should probably be such a view. Today the desktop is a set of links that show huge tooltips with interesting contents like “myComputer.desktop is a Desktop Config File that is 170B large, owned by ettrich - users with -rw-r-r– and points to media://”. Thanks for letting me know…
A nifty feature I’d like to see in a file manager is that it shows me when I’m visiting a document currently. And while being at it, single click for opening documents is wrong. Initially I thought it was a good idea, too, but after having tried to use it for a while, I changed my mind. Unless I’m the only one who constantly starts applications by accident when I want to move files around, or delete them.
I’m looking forward to aKademy, to heated discussions, and even hotter coding sessions!
(for another two years) which basically mean we will continue putting out patch releases about every half a year or so.
