Slashdot Mirror
KDE Frameworks 5.3 and Plasma 2.1 – First Impressions
jones_supa writes Ken Vermette has done a write-up on his experience with the new KDE desktop encompassing Frameworks 5.3 and Plasma 2.1. For starters, some patience is still needed for apps to be ported to KF5, and most of them will be KF4-based for now. Many of the widgets you may have used don't exist yet either, but the good news is that the Plasma goodies which do make an appearance are universally improved. The new search widget is shockingly fast and the notifications tray has been reworked. Visual outlook of desktop has been simplified and things don't feel so tightly packed together anymore. The system settings application has been completely regrouped more by goal than underlying mechanics. Unfortunately the desktop stability leaves a lot to desire: there was several crashes and Plasma had at one point managed to forget colour and wallpaper settings. However the developers seem to be knowing what they are doing, and there's a real feeling that this software will reach rock-solid stability very quickly given the state of it as it stands.
Ehhhhhh...... Gnome has always had that "pretty but vacuous" look to it, kinda like one of my ex.
...Steve
Did Ken try this on a box that had X or one that had Wayland? What's the state of KDE 5.x on Wayland?
The tree widgets on the left are mismatched: some solid lines, some spaces with alphanumeric characters; the alpha characters are black, yet the lines are gray visual noise that creates visual processing and cognitive load for no reason, adding nothing.
The parenthetical text at the top has a title whose margin (left whitespace to other widgets) is significantly different from the text below it; there are spaces between the parentheses and the text, which no text or print style guide in the world endorses because it separates the parenthetical indicators from the parenthetical text, when they should be tightly bound for clarity.
The window title preserves the absurd convention of using both the binary name and a descriptive title together, and separates them with a typographical element (an em-dash) which is inappropriate in a label or design element because it is asynchronous—it indicates a delay in interpretation and pronunciation (as the em-dash just a few words ago in this paragraph does) and thus suggests long-form reading, which is not the intent for at-a-glance window titles (unless you don't want them to be very usable).
The title of the list widget, "Information Modules" is superfluous and redundant; the user starting an "About" dialogue expects to see "information" from the start, and they do not need to know about implementation ("modules").
The resize handle contrasts significantly with the window background, drawing undue attention to this particular area of the window above others (why is it "louder" than the window title, for example? Window controls should be secondary to window content and all at the same visual "volume" for usability).
In short—they still don't get it; they are signaling, in conventional ways that most users process subconsciously, thought habits and forms of attention that are not contributing to efficiency and use, but rather detracting/distracting from it. This is the same old KDE with poor, unprofessional design that leads to cognitive clutter. It's not that KDE has "too much going on" but rather that KDE has "too much going on that isn't actually functional and adds nothing to users ability to get things done).
Yuck.
STOP . AMERICA . NOW
Eric Raymond wrote a horrifically amusing screed about why open source interfaces suck so bad, back in 2004. It was called "The Luxury of Ignorance", it laid out fairly good guidelines for how to do an interface *well*, and Gnome has ignored *everey single one* of the guidelines. I'm asking about this KDE, did they follow *any* of these guidelines?
= So, if you are out there writing GUI apps for Linux or BSD or whatever, here are some questions you need to be asking yourself:
* What does my software look like to a non-technical user who has never seen it before?
* Is there any screen in my GUI that is a dead end, without giving guidance further into the system?
* The requirement that end-users read documentation is a sign of UI design failure. Is my UI design a failure?
* For technical tasks that do require documentation, do they fail to mention critical defaults?
* Does my project welcome and respond to usability feedback from non-expert users?
* And, most importantly of all...do I allow my users the precious luxury of ignorance?
= Postscript, 26 Feb 2004: I added the new fifth question based on an excellent suggestion in LWN's comments on the story.
= And here are some more design rules, from Nico Kadel-Garcia:
** Can you gracefully and easily duplicate your tools and configuration for a similar installation? Is it documented? (RedHat and CUPS is no help with this, either, most of the print-drivers wend their way from the foomatic and other tools into the CUPS setups without a lot of hint of how it works.) [For cups, the answer is "you can duplicate it easily, but it's a *secret*"! Every configuration should be built and recompiled from the source tarball! What are you, a n00b?]
** Is installing this toolset likely to replace or break something already in place (such as LPD based printing packages)? If so, explain how to gracefully do the transition.
** Are there settings you can do from the command line or hand-editing config files that cannot be done from the GUI? Are they documented anywhere? Does using the GUI erase these settings? (The answer for CUPS is "Yes, you can flush all sorts of hand-edited things this way!". This was an incredible problem for NeXT stations and remains a big freeware GUI problem, although most try harder to address this. Webmin is an excellent example of how to do it right in most cases!)
** Are all your important features mentioned? The automatic flat text->Postscript conversion is one such feature, and despite its presence in the tarball tools and default use the CUPS claim it's not theirs and not their problem.