Moving Away From WIMP Interfaces One Step at a Time

While the capabilities of operating systems have improved over the last years, the improvements have largely focused on under the hood changes. New functionality is reaching the user via additional applications which allow her to write a DVD, connect to her mp3 player, download streaming video locally and other tasks which were not present before. But the graphical interface of the computer itself is keeping the same concepts introduced with its appearance. One could argue that the graphical environment of computers is exactly the same for the last 10 years and only cosmetic changes take place in newer versions of operating systems. Moving away from the desktop metaphor is harder than it seems. Even alternative operating systems have embraced the concept instead of exploring new ideas. This article describes a solution which attempts to free the user from the files/folder concept.

Current situation

Microsoft and Apple have a huge customer base. Making radical changes to the user interface (UI) is almost impossible. As I explained in my previous article, I disagree with the fact that everyone is excited with 3D candy coming on the desktop and nobody attempts to correct its existing shortcomings. I also argued that even in the open source world most prominent projects assume that the desktop metaphor is the one true solution. There are exceptions to this but a truly alternative idea has failed to catch on.

While GNU/Linux might be considered an alternative operating system, its graphical interfaces are not alternative at all. In order to reach mainstream acceptance, KDE, GNOME (and XFCE) developers have followed the tried and true approach of imitating the interface of the dominant operating system(s). They have done an excellent job and by all means, office workers can easily migrate to KDE or GNOME. I congratulate them for their efforts since what they have achieved is truly amazing work. So now that we can accommodate for users that like the desktop metaphor, it is time to explore other ideas too.

The desktop approach has a lot of flows. It presents too much information to the user. A huge selection of menus, and icons is present at any given time on the screen. Users have trouble navigating the menus to accomplish what they want. Task based interfaces are only successful in certain areas. The desktop root window is cluttered with documents, folders and applications. Searching for a specific document can be a nightmare. Overlapping windows require micro-management. Direct manipulation can be a curse under certain circumstances. Many people have written before me and better than me the problems of the desktop metaphor. If you are happy with your desktop and think that there is nothing wrong with it, you should not read this article in the first place.

Too much data

Rather than attempting to throw everything away, we should gradually identify what is wrong and correct it, keeping backwards compatibility where possible. I will only focus on the idea of having files and folders which plays a central role in the desktop metaphor. Organizing files under folders was indeed efficient for many years. Users did not have a large number of information on their computers. And since office users were already accustomed with physical files and folders, they had no trouble navigating the virtual ones. Of course things have changed since.

Today too much data is present on a single computer. A human user cannot simply remember where everything is placed. The files and folders are directly mapped on file-system structures. Users are provided with a file manager application which gives them direct access to the file-system hierarchy present on the hard disk of the computer. Manual file management can quickly become overwhelming.

People realized this management problem and several new solutions appeared which combined the file-system with some sort of database. We now have google desktop and Beagle. There provide essentially indexing services to the user. Instead of having to remember the exact location of a file, she can simply query the indexing service using properties of the files and hopefully get a result back.

All these are great solutions on their own. But they cure the symptoms and not the cause of the problem. Users should not have to use a smart indexing service which helps them find what they want in the chaos hierarchy of their files. There should never be a chaos in the file hierarchy in the first place. In fact, users should not even care if there is a hierarchy or not.

Delegate file management to the computer

Taking this idea further, I propose the complete removal of the file manager application. Power users will be able to access the file system via the command line if they want, but normal users should never want to do that or even know that it is possible. Removing the file manager might scare several users, so it may not sound as a realistic thing to do. We should explore the implications of this removal.

A user opens the file manager for three main reasons.
1)Copy data to/from external media such as CDs,flash drivers, mp3 players e.t.c.
2)Find a file and click it in order to edit it.
3)Move around files and better organize them.

The first operation is a valid use of the file manager. But it could also
be handled by an external application built for this purpose. For brevity reasons, I will not talk about this application in this article.

The second operation was a valid use of the file manager. Users have a large number of files so they open them by searching for the name of the file, or using the “recent” list of the operating system or the editing application responsible for this file type. Lately indexing services have appeared as described already. Users search for a document with the file manager as a last resort only. It means that all other methods have failed, which is something that we should avoid.

The third operation is time consuming and should be avoided. We should free the users from micro-management. While power users get a warm feeling that their file hierarchy is exactly as they want it, casual users rarely spend time organizing files. Most of them do not even bother at all and just dump everything on the desktop root window.

So if we provide users with an external media application and some kind of indexing service can we finally remove the file manager? Some users might be surprised that they cannot access files directly. They might see this as losing power. The truth is that they do not lose this power. They rather delegate file management operations to the computer where they belong. Management via complete control is only possible at small scales. After a certain amount of data is reached, good management means delegating responsibility to assistants who will perform the needed operations. In our case the assistant will be the computer itself.

Tagging content

This means that instead of constructing a simple indexing service, we also entrust the computer with the underlying file-system hierarchy. The user is shielded behind the abstraction layer of the query service. The query service acts as a search engine on the local files. Files are marked with tags that describe their contents. The user can enter tags on a text field and retrieve all files that match them. The interesting idea here is that the file-system hierarchy is built dynamically according to the tags of the files.

Current indexing services suffer from the fact that they can only extract metadata from indexed files, while they do not understand their contents. Getting the size or dimensions from an image file is easy, but the indexing service cannot know what is actually depicted on the picture. In the future we may have clever pattern recognition applications which would understand the content of every file that enters a computer. Until this semantic content utopia is a fact we need to resort to the best pattern-recognition method we already have: the user herself.

Every time a new file or folder enters the computer (via physical media or via the network), we ask from the user to tag it with a set of keywords that describe it. This might seem a daunting task at first sight. It is not, since the users already have to think where to place a new file on their computers and decide a target directory depending on the incoming document. In fact our solution is even better since it does not restrict the user on a single directory. While previously the user would have to select whether the “Sales” folder or the “2006” folder was the proper place for a document which described sales of 2006, now she can tag it with “2006” and “Sales” keywords and let the computer decided on the actual place insider the filesystem. Of course some users would place the document in the “sales” folder located inside a “2006” folder. This creates instantly a 1-level deep hierarchy which after some time will result in the chaotic filesystem found on modern workstations. This is exactly what we want to avoid.

Of course since we care for compatibility we keep the old filesystem around. If the user wants, she can put manually the file wherever she wants outside the control of our abstraction layer. Power users and programmers can still have their carefully monitored tree structure on their home directory and only let some (or none) of their files under the control of the abstraction layer.

Building a prototype

A lot of people have expressed their opinion on how an idea should be implemented, but few have actually created an implementation. This time I have already implemented a prototype of this abstraction layer. And rather than presenting a command line tool with a thousand of command line options, or a daemon process with yet another interface/protocol/API and a full-Howto on the installation process, I have followed the exact opposite direction. Start from the user interface first!

The prototype is actually a graphical application (X11) with cheesy graphics full of animation and custom widgets which will only entice casual users. But these are actually the target audience. Other than than it is a single C application with an embedded SQLITE database. No external databases or running daemons are needed. The application is named simply “The vault” (I am open to name suggestions).

Its functions can be easily summerized. Anything that is copied to .vault/incoming is up for inclusion in the abstraction layer. Once the application is launched users can either assign tags to files/folders or search the existing (already tagged) files/folders. A third option to see recently searched tags is also offered. No special toolbars or menus or anything more complicated is present. The actual files are stored under .vault/storage. The idea is that casual users should never access this directly, but they should always use the tag-based graphical interface.

The vault is located at its own sourceforge page. To build it you need the sqlite development headers and libraries and also the Enlightenment Foundation Libraries (EFL). The EFL are the libraries behind the next version (17) of the Enlightenment Windowmanager. They are not officially released yet so you are expected to download the snapshots from the freedesktop site.

If you actually visit the sourceforge site you will realise that the vault is essentially one component (around 30%) of a bigger project that attempts to explore some alternative ideas on how the modern desktop should look and act. You are free to help the development of any component. The vault is just the first one published to the open source community.

As a final note I should also mention glscube. Glscube was released after I had started development on the vault, and they share many similarities. Glscube also creates a virtual filesystem based on the tags assigned by the user on individual files. It even includes an indexing service on its own. Another impressive capability is the POSIX-compatibility layer offered for non-glscube-aware applications. The problem with glscube is a high number of system-intrusive dependencies including a fuse module, a PostgreSQL database, and a console daemon. While the idea is interesting I find the implementation a bit heavy on resources and certainly an overkill on low-end systems. I wanted something simpler and more lightweight. Even its authors are mentioning a future change from PostgreSQL to sqlite (which I already use).

About the author
Kapelonis Kostis is a computer science graduate. He believes that the desktop metaphor is obsolete. After spending a lot of time thinking of the perfect User Interface, he has started implementing it. If you share his vision or have suggestions on your own, do not hesitate to offer advice, or even help with the coding process.


If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.

64 Comments

  1. makc 2006-11-02 10:49 am EST
  2. Terracotta 2006-11-02 10:56 am EST
    • xfranky 2006-11-02 1:31 pm EST
      • Terracotta 2006-11-02 9:45 pm EST
  3. gdiaz 2006-11-02 10:59 am EST
  4. Alleister 2006-11-02 11:22 am EST
    • sandorfal 2006-11-02 12:57 pm EST
      • twenex 2006-11-02 4:25 pm EST
    • Doc Pain 2006-11-02 5:31 pm EST
  5. miro 2006-11-02 11:44 am EST
    • siki_miki 2006-11-02 12:11 pm EST
      • stooovie 2006-11-02 1:40 pm EST
    • pandronic 2006-11-02 4:45 pm EST
  6. Haicube 2006-11-02 12:12 pm EST
  7. inetman 2006-11-02 12:16 pm EST
  8. Earl Colby pottinger 2006-11-02 12:17 pm EST
  9. Nycran 2006-11-02 12:30 pm EST
    • dylansmrjones 2006-11-02 1:23 pm EST
    • falemagn 2006-11-02 1:34 pm EST
      • l3v1 2006-11-02 3:37 pm EST
        • falemagn 2006-11-02 3:50 pm EST
    • schala 2006-11-02 3:59 pm EST
  10. ronaldst 2006-11-02 12:50 pm EST
    • dylansmrjones 2006-11-02 1:11 pm EST
      • kiddo 2006-11-03 3:36 am EST
        • dylansmrjones 2006-11-03 4:00 pm EST
    • CowMan 2006-11-02 6:07 pm EST
  11. dylansmrjones 2006-11-02 1:09 pm EST
    • twenex 2006-11-02 4:33 pm EST
      • dylansmrjones 2006-11-02 4:48 pm EST
        • twenex 2006-11-02 6:01 pm EST
  12. Constantine XVI 2006-11-02 1:18 pm EST
  13. IanSVT 2006-11-02 1:29 pm EST
  14. arj03 2006-11-02 1:55 pm EST
  15. Sphinx 2006-11-02 3:04 pm EST
  16. mebarg 2006-11-02 3:26 pm EST
    • falemagn 2006-11-02 3:39 pm EST
  17. cptnapalm 2006-11-02 3:47 pm EST
  18. w-ber 2006-11-02 4:22 pm EST
    • Moochman 2006-11-02 9:14 pm EST
    • makc 2006-11-03 9:52 am EST
  19. aseigo 2006-11-02 4:25 pm EST
    • dylansmrjones 2006-11-02 4:55 pm EST
      • CowMan 2006-11-02 6:25 pm EST
        • dylansmrjones 2006-11-02 6:39 pm EST
  20. bibe 2006-11-02 6:19 pm EST
  21. Dmitry K 2006-11-02 6:48 pm EST
    • falemagn 2006-11-02 7:54 pm EST
  22. alcibiades 2006-11-02 6:49 pm EST
    • Doc Pain 2006-11-02 6:58 pm EST
    • Moochman 2006-11-02 8:46 pm EST
  23. pwjazz 2006-11-02 7:01 pm EST
  24. Toad 2006-11-02 8:43 pm EST
  25. zeroth404 2006-11-02 9:02 pm EST
  26. Moochman 2006-11-02 9:03 pm EST
  27. zeroth404 2006-11-02 9:19 pm EST
  28. Manik 2006-11-02 10:33 pm EST
  29. Ronald Vos 2006-11-02 10:39 pm EST
  30. n1xt3r 2006-11-03 12:04 am EST
  31. cerbie 2006-11-03 12:38 am EST
  32. Angel Blue01 2006-11-03 1:08 am EST
  33. John Nilsson 2006-11-03 1:59 am EST
  34. steveftoth 2006-11-03 2:41 am EST
  35. amilcarodonte 2006-11-03 5:36 am EST