Three years ago, KDE was the innovative desktop, and GNOME the conservative one. Today, KDE is the conservative desktop, doing incremental releases, while GNOME is divided between GNOME 3 and Unity, each as innovative and as controversial as the other.
Next week’s release of KDE 4.7 does nothing to change the current relationships, being — at least from an end-user’s perspective — full of small changes while failing to address some of KDE’s ongoing usability issues.
Currently available as a second release candidate, KDE 4.7 can be compiled from source. Alternatively, Fedora, openSUSE, and Ubuntu all have packages available for those who want to experiment. An even simpler way to explore the release is to download the Live CD image provided by the Chakra project.
From a developer’s perspective, KDE 4.7 is full of news. In particular, KWin, the KDE window manager now supports OpenGL-ES 2.0, an API for embedded graphics hardware. Although this change is supposed to immediately improve the performance for effects on all KDE installations, its importance is largely long-term, as KDE attempts to expand into mobile devices.
Another behind-the-scenes change in KDE includes support for the GRUB2 boot manager in the KDM login manager. This is a logic modernization, as GRUB2 starts to replace Legacy GRUB, but for end-users, the main benefit is the ability to choose as you logout the kernel or operating system to use the next time your machine starts. For most users, this change will likely seem nothing more than a parlor trick, although for developers or system administrators, it can be handy if they suddenly need a specialized kernel in their work, or want to reboot without overseeing the process.
In fact, the closer you read the release notes, the more you realize that the KDE team is trying to anticipate future developments and to prepare for them. However, while KDE prepares for changes that are some years out — assuming they happen at all — on the visual level that most users operate, KDE appears to be struggling or ignoring long term issues about just how the desktop should be organized.
Specifically, while System Settings and Marble struggle to settle on an interface, KDE continues to experiment with ways to make Activities more accessible to users. Meanwhile, the Dolphin file manager in 4.7 has opted for a menu-less default interface. While the project prepares for possible future developments, the more basic interface issues are starting to pile up.
Legacy Issues and an Attempt at Breakout
These problems did not begin with the 4.7 release. However, it does seem indicative of an ongoing problem that, after so many releases in the KDE 4 series, 4.7 shows little, if any movement toward solutions.
One of the first interface issues that you are likely to notice after installation is in System Settings. By default, the KDE 4 series presents administration and customization tools as icons organized into a handful of categories within a single window. You can still use the tree view of the old KDE Control Centre, but you have to specifically enable it.
This change is generally an improvement over the formidably long tree view, and has the advantage of being more in keeping with the practice of other operating systems and desktops. The only trouble is, the names, the arrangement of features, and the order of icons changes with each release. As a result, finding a feature can be difficult after upgrading.
In 4.7, System Settings has changed less than in previous releases. For one thing, the category names and icons are largely the same as in the previous release. Moreover, unlike some of its predecessors, it does not include a so-called Advanced tab which is actually a dumping ground for miscellaneous functionality.
However, the 4.7 incarnation of System Settings is only relatively more stable than its predecessors. I could be wrong, since I am comparing across distributions, and evaluating an unfinished product as well, but it appears to have gained Bluetooth and Firewall configuration tools while dropping Printer, Sharing, Permissions and Digital Camera tools.
In other words, not only are additions being made, but the basic organization of tools is still extremely fluid. At times, you could wish for more consistency across releases — even if the design wasn’t always as rational as it might be, as in the case of separating Workspace Appearance and Behavior into separate functions.
Much the same problem occurs in Marble, KDE’s general geographical tool and desktop answer to Google Maps. Potentially, Marble should be a success story in the KDE pantheon of applications, yet somehow it has never received the recognition it deserves.
Part of the reason, I suspect, for Marble’s obscurity is that its interface continues to change. In 4.7, its map Legend — the list of indicators for features such as roads and town and cities — continues to change. So, too, does its handling of bookmarks, with a Firefox-like manager being new to 4.7.
Such ongoing changes are especially confusing in Marble because its appearance changes drastically with your selection of map views. Not only can you choose a globe, a flat map or a Mercator’s projection, but you can also choose a view of Earth or the Moon, or a theme such as a plain map, or one showing precipitation, temperature, or an Open Street map.
Add an interface whose basics are still changing after several years of development, and it is no wonder that Marble fails to get the recognition it deserves. In concentrating on features, its developers appear to have overlooked the simple truth that usability is even more important in Marble than in most apps.
Yet another legacy interface problem centers around KDE’s Activities — the workspaces that are supposed to allow users to divide their desktops according to tasks or location. Introduced with KDE 4.0, Activities seem a logical extension of desktop functionality, yet somehow they have never caught on with users any more than Marble has.
Early in the KDE 4 series, Activities were displayed in an overview similar to the one in GNOME 3. But the overview puzzled readers, and many seemed to miss its function. So a few releases ago, KDE switched to presenting them in a horizontal scroll similar to the one used for selecting widgets to display on the desktop.
Yet that change appears to have done little to encourage adoption of Activities, so in the 4.7 release (at least as presented by Chakra), the scroll bar for selecting them now includes several samples to illustrate the possibilities, and a widget for the scroll bar appears by default on the panel.
In addition, users can now search for Activities by name in KRunner, but whether that will help users appreciate Activities seems doubtful, since KRunner is a tool more likely to be favored by advanced users than beginners.
By contrast to System Settings, Marble, and Activities, the main developer of the 4.7 incarnation of the file manager Dolphin seem to have decided to take usability into their own hands. Although the developer blogs that he “did no scientific research,” he has decided that Dolphin’s default interface will replace the menu structure with a single menu button that dumps all items into a single menu, and eliminates the information panel on the right, all in the name of reducing clutter.
Admittedly, these changes reduce clutter — but they also reduce default functionality. If anything, the default view in Dolphin would benefit from enabling the editable location and filter fields. As it is, in 4.7, Dolphin’s defaults imitate recent GNOME releases by reducing the functionality for experienced users in favor of a mythical new user who is apparently easily distracted and probably shouldn’t be let loose on a computer unsupervised.
But, no matter what you think of the changes to Dolphin in 4.7, they place Dolphin at odds with most of the other applications in KDE. With luck, they will be an anomaly, but, considering the importance of a file manager, a chance exists that these decisions will spread to other KDE apps in the absence of more detailed interface guidelines.
Looking for Balanced Guidelines
Of course, such interface issues are not the only things happening in KDE 4.7. From full-screen modes for games and support for QR and Datamatrix codes in the Klipper clipboard to a plug-in for the Kate text editor that allows pattern-searching within files, 4.7 teems with small enhancements that many will quietly appreciate.
Yet if any overall pattern emerges from the 4.7 release, it is that too loose a set of common interface principles is preventing KDE from improving its users’ experience in quick and effective ways.
In the past, one of the benefits of KDE has always been that it lacks the over-simplification enforced by GNOME’s Human Interface Guidelines. In contrast, KDE has managed to appeal to all level of users, and not just new ones.
Few KDE users, I suspect, would want to see that change. Personally, if forced to choose, I would prefer KDE’s looser interface policies to GNOME’s prescriptive ones.
But, at the same time, the choice is not either-or. KDE does not have to replicate the unnecessary rigor of GNOME to benefit from a few more common standards in its utilities and applications.
The fact that KDE apps are each going their own way in interface design is wasteful and needlessly confusing. But, even more importantly, the fact that after eight major releases in the KDE 4 series, the project is still struggling to present Activities in a way that users can appreciate them suggest that some key interface issues are being ignored.
KDE 4.7 provides no answers. But the fact that it inherits problems that earlier releases in the KDE 4 series also suffered from suggests that the project is overdue for some basic re-thinking of interface issues.