Plain and Heard Before

Celeste is doing historical research on KDE’s usability. To her request for my comment on things, I modestly replied:

I think my effective contributions are modest, although one could say I’ve tried. But I can of course always express my view.

Her response, which made me think, was:

Your view is what matters to me, not some generalized or idealistic view from the usability contributors themselves. I have certainly learned some interesting things from the developers.

One could of course take that as a negative comments towards “the usability contributors” but I think it was to address a certain problem.

Aaron wrote in a recent blog entry:

[...] It punishes developers like Tim for speaking openly about the challenges we face. the free software community relies on our ability to speak openly and honestly to each other; if we start to get punished for it then we have a real problem.

Although the blog entry is in general about a certain article, Aaron is in that paragraph simply pointing out that being able to talk and address issues is dead important.

As reply to one of Celeste’s questions on KDE’s usability, I wrote:

One thing I admire the GNOME project much of, is their ability to change. They manage to get ideas /implemented/ in their main
line, without getting shot down at the proposal-stage. Those ideas might one disagree with or they are perhaps even downright wrong, but the ability to
change, to test new ideas, is a prerequisite for reaching the right ideas. Progress isn’t a linear progression of constantly correct changes, and the
working process must be adapted for that.

I can’t name a particular achievement, but each time a usability idea advances from being a proposal to being tried on the practical level, progress
is happening.

which as well merely says “don’t shoot down ideas just because they’re different or sound bad.” I’m of course only speculating from my view on things, but it wouldn’t surprise me if many nods to that it can be difficult to not have an idea stalled as early as when it is a suggestion.

Open Source and Free Software, at least if we go back in time, was a liberator for sick things in the IT industry, and will continue to be so, as long as those values are withheld. But perhaps the community is too consumed with its achievements on the democratic side, to see the sides of itself that fights its own mindset.

Belief fucks up mankind in spectacular ways. “We just need a revolution from system X to system Y and we will have no more corruption”, “It is ok to reduce the democratic rights for Them because They are not Us”, “We don’t have to listen because we are right”, and other countless examples that demonstrates people thinking there is a difference between people as long as they have a different skin color, operating system, religion, political system, desktop environment, and so on.

My point is simple and well repeated: openess is important. This time, it’s being emphasized for the open source community. Things will stall if ideas from GNOME are on mailing lists tuted as evilness, if less technically minded users are What’s Wrong, if KDE is considered to always be perfect, or if new ideas are shot down for not being what we have. And blogs isn’t the only way ideas are expressed, what ideas that are implemented in software, is another way as well.

KDE’s URIs

Significant for KDE’s IO-handling is its use of proprietary URI schemes. As recently mentioned on the kde-usability list, there’s for example the home:/ scheme that when entered into Konqueror displays the content of the /home folder, more or less.

If “proprietary URI schemes” sounds all evil and wrong, it does so because it is. Registered schemes have an agreed meaning in a wide community. Proprietary URI schemes is like any other kind of interoperability breaking — like when Microsoft decides to add its own modifications and extensions to Javascript and CSS. Any piece of software understands file:///home while its only KDE applications using KIO that capiche home:/. That’s the best case scenario. Perhaps someone decides to behave and standardize a scheme by name home:/, which happens to have different semantics to KDE’s.

This is not a theoretical problem, see report #126847 for an example of where these homemade schemes cause trouble.

While I think I am correct in my bashing so far, one surely can add nuance to it. Many would probably say that KDE’s proprietary schemes is a necessary evil for making the usability of URIs reasonable. For example, they would claim that man:/cmake is better than tag:kde.org,2006:man:cmake(a use of the tag scheme to produce an interoperable URI).

I think arguing about URIs’ usability is in the wrong ball court, because URIs have bad usability no matter what. As soon URIs are advertised in commerials on TV, it’s never http://www.tv2.dk, they elegantly let it read tv2 dk.

KDE’s widespread belief in URIs perhaps stems from that developers fail to abstract from themselves and see it from the user’s perspective. That one can enter “gg: wikipedia” in Konqueror to automatically google for the term “wikipedia” is touted like the invention next to sliced bread. But how should users — except for the geeks — know how to use gg:, let alone know it exists?

The same could be seen in discussion on the kde-usability list: some didn’t know the home:/ scheme exists, which to me is fully understandable. I don’t see how users should be able to learn the pesky syntax details of using home:/, let alone a reason why.

Therefore, I don’t believe the right way to solve URIs’ poor usability is to use proprietary schemes. For example, googling quickly should be done with one of the well known approaches browsers take, and navigating man pages should not be enabled by having memorized the man:/ scheme, anyone should be enabled to it via a friendly interface.

Dropping down to the command line for interfacing the user is about a two-decades step backwards in usability.

PS. If you don’t want to use a proprietary URI scheme for your app, check out the KDE URI Guidelines.

Improving Mail Reading

I read a lot of email. Most of us do. Most of us have also, in one way or another, learnt how to correctly snip mails, who to actually reply, how to properly ask questions, and other matters of email etiquette. Those who haven’t, create work for those who have to read their mails.

I spend too much effort on non-snipped mails. How many times doesn’t one start with scrolling a large mail in order to find what the author actually has written, or scrolled down to the end of a mail only to find out it was merely the remnants of what the author replied? I think one can extend email clients, such as KMail, to make the absence of snipping unnoticeble to the user.

The solution consists of a mechanism I’ve dubbed paragraph folding.

Minimum Display Size in KDE

A topic that periodically pops up in KDE is what screen sizes that should be acceptable. Usually someone thinks no one runs at the resolution 800×600 and therefore decides to think the minimum requirement should be 1024×768. Typically, people explains why that is not a very good idea and the suggestion is dropped, as seen in this recent thread.

Why is it then a bad idea to disallow the use of 800×600? Because the idea rests on this principle:

If someone breaks a normal chair because of having an over-weight, the solution is to build a bigger chair.

It is not. The solution is to not have an over-weight, such that a normal chair can be used.

The same applies to the screen size debate. That windows are huge is a symptom. It shouldn’t be work-arounded by accepting it.

Here is a list on why large windows are bad:

• Disabled people might use a low resolution despite having a large screen. Also, font-related settings can make a window large. That is, this is an accessibility aspect.
• No matter if a large or small display is used, one doesn’t want a large dialog in either case. Dialogs are supposed to be small, neat windows floating on the main document, giving the user a clear understanding of that the dialog affects and belongs to the main window. It’s not supposed to fill the whole screen. How practical is that?
• When talking about “small” screen sizes, it’s not just about those old monitors. The diversity of hardware is only increasing(tablets, cell-phones, and so on) and as this continues, it will be more and more interesting to run KDE-software on those too.
• That for example a configuration dialog is large to the extent it doesn’t fit on a 800×600 display reveals severe usability issues beyond it not fitting on a display.
• Not all desktop users have dropped those old CRT-monitors in favour of large, flat TFT-displays. There is a large world out there which doesn’t live a life that some of us are used to, consisting of the latest hardware, IPods, and what not. Reaching and helping those users is something I personally finds interesting and gladly see KDE achieving.
• Some languages are verbose compared to English and therefore the interface can require more space when being used in another language. That is, if a window is already large it will become even larger in some languages.
• Many users are in fact using 800×600. A page by Jacob Nielsen dated 2006 claims 17% is using 800×600(the background of these statistics are on page 226 of his new book Prioritizing Web Usability, I was told). Browser News also claims 17%. A page at W3 Schools claims that in 2006 20% were using 800×600 on the web.

As can be seen, there is a wide range of different reasons to ensure windows work on “small” resolutions. Phrased differently, this topic is too complex for concluding that 1024×768 is sufficient, by watching what ones co-workers and family members are using.

An important thing to remember is that it’s not the windows themselves that should be 800×600 large. That’s the screen resolution that the windows must fit on. Therefore, windows should rather be designed for being of size 640×480 in order to ensure they fit and fit comfortably, when taking for example the kicker(start menu) into account.

State of the Art

That Clarence Dang writes “800×600 [...] doesn’t reflect the reality of some of our dialogs” it is a comment that unfortunately is true. If I recall correctly, there is plenty of KControl modules that are broken on 800×600 and one can find prime examples such as KMail:

Yes, this is one of the most used KDE applications, with a configuration dialog that doesn’t fit even on 1024×768.

The question is of course: what can be done to change this situation?

A year or two ago I made KCModuleProxy, the class that displays configuration modules in dialogs and KControl, wrap the contained module in a scroll area if it was too large. Scroll bars aren’t very practical but it did make dialogs at least usable, and it acted as a protection until the dialogs were fixed properly. But this mechanism got removed by a developer for whose dialog scroll bars appeared.

Another approach is to detect and report broken dialogs. If I recall correctly, Benjamin Meyer did this with DCOP magic in the now obsolete(I believe!) kdetestscripts. Perhaps the same can be added to EBN or similar.

Once KDE more rigidly has integrated its Human Interface Guidelines into development, it will perhaps be possible to pursue this with a successful result.

Move, cursor. Please.

What I often find myself doing, such as when writing this very text, is that I need to edit or write in the middle of a paragraph and therefore grabs the mouse to position the cursor there in the middle.

What happens? The mouse pointer is hovering just above the letter of my interest, giving me trouble finding out what it reads.

I think this can be fixed with an elegant detail. When the cursor has been changed with the mouse and the mouse pointer is within the text edit, a swift animation slides the mouse pointer to the outside.

If any signals are received during this mouse pointer move, the automated move is interrupted.

I think implementing this would be both controversial and tricky to get right, since it is — at least in my book — tabboo to do things the user isn’t engaged in or in some other way understands why it happens. The same could be done in the case of Konsole’s terminal window, instead of hiding the mouse pointer.

Of course, this is merely speculation until it is implemented, and most notably, properly tested. I wrote the wishlist.

OS News’ KDE Criticism

OS News recently ran an in my opinion poorly edited editorial on KDE as a desktop environment, but nevertheless it has valid criticism.

About one year ago I worked on KControl-related code, and I remember the massive friction the idea of hiding the command label, “command: kdesu or whatever -t213c –more-cryptic-messages”, encountered. The main point was that hiding the label compromised security. Stating that, is to iron the developer-centric and geek-centric view to the ground, often found in the KDE community.

Even though the details in itself aren’t that simple(showing the command isn’t necessarily safe due to spoofing mechanisms,to name one), it boils down to that such a message isn’t understood by the majority of users. There’s a world of people in addition to us geeks who doesn’t sit deep down in consoles and database backends to music players and what not.

The “command: …”-label is a nice example of where a KDE interface looks geeky, scary and confusing for the majority of users, while KDE-praising continue living in its bubble where KDE’s interface design makes KDE better than GNOME, OS X, and so on. It is an example of where KDE’s usability diminishes because of the usual power-user influence.

Nevertheless, I remember I patched kdesu with the `-d’ option which makes the command-label go away. If not specified in the current KControl, it surely is in one of the KControl-4 prototypes. And it can of course also be specified in other cases where kdesu is used, as people see fit.

Another fair comment, raised in one of the Dot comments I believe, is the inconsistent wording. What should what technically is referred to as the root-password, be called in interfaces? Administrator’s password? Root-password? Password for God-mode?

I don’t think the question can be answered. KDE hasn’t the infrastructure for it. GNOME and Apple have wording guidelines in order to ensure texts are consistent. KDE does not. That’s one reason to why I refrain from attempting to improve usability in a particular application, because I don’t think it would be very effective. Improving usability in one application, would require working on KDE’s framework, KDE’s available means for working on usability.

As one might imagine, even though I’ve been a KDE developer for years, I don’t engage in euphoric praising on how KDE is the best thing in the universe. Because I don’t think it is. It do has fine things, but it needs work on the usability front. Lots of work. Along with MS Windows, it is the desktop environment that needs the most work. I’m glad GNOME and Apple exists so KDE has something to borrow great ideas from and compete with.