Why the Linux Desktop Should Be Organized By Tasks

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

This is not the time for innovation in desktop environments. The memory of the user revolts against KDE, GNOME, and Unity are still too fresh for developers to attempt major changes. Instead, the preference is for tweaks and minor improvements in functionality that nobody is apt to get too upset about. All the same, I think the desktop is long overdue to switch to task-based design.

Historically, desktops have been organized by applications. This approach was adequate in the early days of personal computing, when the number of applications was small. However, today, it is hopelessly outdated in at least two ways.

First, as often as not, application names rarely reflect the function. Amarok, K3B (even when written in full as Burn Baby, Burn), and Shotwell are all first-rate applications, but no one would ever guess what they do from their names. Even Libreoffice’s name only vaguely indicates its purpose. Application names like Pysol (Python Solitaire) or digiKam (digital camera) are no more than a third of applications in a typical menu, and even they are obscure.

This obscurity is typically aided by task-based top level menus — but only in a small way. When, for example, both Scribus and Xsane are listed under Graphics, the guidance is only minimal.

Second — and more importantly — the average modern computer has so many applications that displaying them by name has become increasingly impractical.

The classical menu is now either too long for the screen or else its sub-menus spill awkwardly across the screen until they can hardly be used. Nor have the alternatives been particularly successful. Showing only a limited set of applications risks cutting off users from the full array of installed programs, even when a search field is included.

Similarly, while a separate menu screen may be acceptable on a mobile device because of lack of space, on a workstation, it is a distraction. The ideal that has eluded replacements for the classical menu is a design that minimizes the number of mouse clicks and allows users to return to their work as soon as possible.

The Task-Based Alternative

The quickest solution to this design problem may well be task-based design. The problem is, task-based design only occasionally figures in desktop environments. Besides in top-level menus, it can be implemented to a limited extent with virtual workspaces if a user chooses, with one workspace reserved — for example — for web-browsing, and another for reading email.

Otherwise, the one major effort to implement task-based desktops is KDE Activities — and they appear to have been too radical and too little explained to catch on.

However, when you setup Activities, one of the first points that becomes obvious is how few desktop icons each Activity needs compared to any sort of menu. Even with documents and URLs on the workspace, a KDE Activity rarely requires more than a dozen icons, and often five or six will do. As a result, all necessary resources are a single-click away, and can be found with an absolute minimum of searching.

In other words, while you are using a specific task, you are temporarily returned to a situation much like the early days of personal computing, when the number of applications was small enough not to be overwhelming. Or, to put things another way, you are using a more targeted version of a Favorites menu.

Personally, I live by Activities, and their lack feels crippling when I use any desktop except KDE. Yet I wonder if they couldn’t be taken one step further.

Specifically, why not make tasks the organizing principle all the way through the menu? There is already a tendency to this kind of organization in GNOME menus, with “Document Viewer” replacing “Evince” and “Movie Player” replacing “Totem.” All things considered, it would not be that big a change to replace “LibreOffice Calc” with “Spreadsheets” or “Firefox” with “Web Browser.” Many users of desktop icons already make such changes, and a few minor distributions have, as well.

Such a solution would eliminate the problem of application names having nothing to do with function. Make the menu items editable, and they would also reduce the length of menus, allowing them to display in full on a single page.

A name organized view might remain for a complete reference, but in ordinary circumstances, the menu would show only the tasks, perhaps with a sub-menu for alternatives. Some applications would install with a task already assigned to them, while additional tasks could be added by users.

The result would be immediately comprehensible, efficient, and personalized — all the things that Linux desktop users prefer.

The Will to Change

I realize, of course, that, under present circumstances, this change is unlikely to be implemented. In the words of science fiction writer Harlan Ellison, I am not only building castles in the air but planning to move in the first of the month.

Still, the change would not be that large, nor acclimatization to it that difficult. Most desktop environments already allow the selection of default common applications for opening files. Making the entire menu task-based would only require more of the same choices, and the resulting efficiency would quickly justify the effort.

Most of all, building the desktop around tasks would eliminate all the elaborate but often annoying replacements of the basic menu, and allow users to navigate more quickly. All that is really needed is the willingness to implement it, but that is unlikely to happen for several years, assuming it happens at all.

Photo courtesy of Shutterstock.