Hello all, this is my first attempt at describing UI areas of KDE which have room for improvement. I'll try to provide links to related research. C&C is welcome as always.
Well, after reading several papers on e-mail clients and document interaction, a general flaw in the way data is currently presented in desktop environments became somewhat apparent to me: Users only see abstract representations of the data they have stored. This appears to be one of the prime reasons of people still making heavy use of paper [1] and to some extent it also lets users become overwhelmed by data [2]. For those of you who do not have access to the ACM library, I'll try to explain the main points of concern. Basically [1] (as well as [3]) states that paper in the real world can be regrouped and rearranged in order to support people with prioritizing tasks and reminding them of important items. A good example is paper on a typical office desk: Sheets that are close to the user have higher priority than those further away. Sheets at the bottom of a stack have lower importance than those on top. In addition, just by looking at a pile of documents, people can see its contents (through paper size, color, thickness, labels, etc.) and will be able to tell what the documents are about and what tasks they belong to. Further on, the fact that documents are in the same stack can imply that documents are related and belong to the same task. Going to the computer, most of these rather simple real-world actions are not possible at all or only rudimentarily supported. Ever wonder what file "presentation-ces-03-fixed.odp" contains? Well, you need to open up a program and wait for a few seconds before it is even possible to know what the content of that document could be. Now think about transferring one of those 20 sheet stacks into the electronic world and you will agree that getting an overview of a set of documents or picking the right one will not be easy at all. Similarly, in the context of e-mail, [2] argues that all users typically see of their e-mails is a long list of sender/subject/date lines in a table. If a user wants to read an e-mail which is contained in a folder with a large number of other messages, it will be difficult to pick the correct e-mail as there are only few visual cues on message content. Now, some people might counter that there already are file previews available and that my whole point is obsolete. Well, ever thought about what you currently see when your first page is blank? What if the most important page is in the middle of the document? Would research be conducted even in 2005 if this problem didn't exist? With that being said, what would all of this mean for KDE (4)? In my opinion, it is absolutely essential that users are able to instantly see file previews. And this does not only apply to the classic case of text documents or images: Previews should be available for all types of files. Have OGG files in your music collection? Why not show the album cover instead of a loudspeaker symbol! What about more exotic files like a UML diagram? It is certainly important to someone in a software project. Ergo it needs a preview. You like watching short films downloaded off the net? Was "final_med_snd.ogm" that funny clip with the dancing bear or was it "20050524.talktalk.shapes.ogm"? You get the point. Looking at it from a more technical side, I assume that KDE currently relies on external libraries to create previews, e.g. for images (comments please!). If a large number of filetypes are to be supported, this would most likely become a massive dependency problem and therefore does not seem to make much sense. Well, this is where I think Tenor would come in handy. Instead of having KDE create a preview for files, why not offload this task to applications, which in turn register their previews in Tenor? In other words, who would know better how to represent important aspects of a file than the application which created it?! Think about it. For example, if Amarok already downloads cover art for music, it could as well store it in Tenor which would make it available to all of KDE. If you edit a document in KOffice or use Umbrella for UML, why not register a preview? It would not even be necessary to change the file format in order to support previews. To summarize, I hope that it became apparent that ubiquitous file previews should enable users to better group and manage their documents and therefore improve their workflow. Now even if this was rather long, hopefully some of you can comment on the above points. Cheers. [1] Documents at Hand: Learning from Paper to Improve Digital Technologies http://doi.acm.org/10.1145/1054972.1054990 [2] Designing remail: reinventing the email client through innovation and integration http://doi.acm.org/10.1145/985921.985944 [3] How do people organize their desks?: Implications for the design of office information systems http://doi.acm.org/10.1145/357423.357430 -- Markus Weiland [EMAIL PROTECTED] http://www.3danim.de _______________________________________________ Appeal mailing list [email protected] https://mail.kde.org/mailman/listinfo/appeal
