Yes! I get a free beer thanks to Kévin. I will be talking about the Past, Present, and Future of the KDE Usability Project at Akademy this year. (This reminds me to ping Ellen about the unfinished workshop proposal..)
seele :: Jun.27.2008 :: General, KDE/Kubuntu, Usability :: No Comments »
A new UK Podcast is out with more interviews from UDS Prague. Alan and Tony talk with me a bit about open source usability and the KDE4 HIG.
seele :: Jun.26.2008 :: Design, General, Open Source :: No Comments »
Interesting! I just noticed that the KDE (2.1, circa 2000) start screen is in Jenifer Tidwell´s Designing Interfaces (OReilly 2005, ISBN: 0-596-00803-1) as a good example of a progress indicator. *high fives*
This startup screen uses icons to show what KDE does while it starts — each icon becomes sharply defined when that step is reached. No timing numbers are used, but they aren’t really necessary (the user is a captive audience until KDE finishes starting), and they may not be accurate anyway. (From Designing Interfaces: Progress Indicator)
seele :: Jun.26.2008 :: Asides, Design, KDE/Kubuntu :: Comments Off
More examples for why we shouldn´t be looking towards Windows for examples of ¨good usability¨. It seems like on his way out of Microsoft, Bill Gates had a few things to say on Windows usability.
This is a pretty frequent scenario on how usability gets done in a company. Someone high up can´t find something, gets frustrated, and approves a huge pile of usability funding to fix his problem. Several of my recent clients have come to me because of a similar ¨event¨. I can´t really complain since they pay my bills, but it makes me feel good when there are open source projects out there actively trying to improve usability before users complain.
seele :: Jun.25.2008 :: General, Humor, Open Source, Usability :: 14 Comments »
KGRUBEditor will be a configuration UI and System Setting module for managing GRUB in KDE. It is beginning to turn into a very nice configuration tool, thanks to the skills and patience of Konstantinos Smanis (Artemis_Fowl). There are still some minor style-guide related UI issues to fix, such as aligning the labels to the right along a center line and wording in screens and warning messages. Also, the assisted workflows (Add/Edit Entry, Create Password) could use some tweaking, but they’re in decent enough shape to release now/fix later.
However, we still haven’t solve the problem of AutoMagic managing kernel entries. AutoMagic is what delayed development of a KDE GRUB configuration tool over a year ago and only now do we have a developer brave enough to work on it (actually, I don’t think he was aware of AutoMagic until after he began coding :). Managed kernels (packaged kernels installed and updated through the Debian grub-update tool) are wrapped inside AutoMagic headers in menu.lst. AutoMagic is good because it makes installing and updating kernels really easy. Disabling it for users who are using AutoMagic doesn’t make sense. However, moving entries outside or inside the headers would make a managed kernel suddenly unmanaged at best and possibly break things in a Very Bad Way at worst. So we’ve got to do something about it.
(BTW If you aren’t using AutoMagic, none of the following will not effect you)
We can’t expect users to know what AutoMagic is, but at the same time we can’t abstract the back-end logic in the UI. Users may reorder managed kernels (marked as [AutoMagic] in the UI) within the AutoMagic headers, and they may reorder unmanaged kernels anywhere but inside the AutoMagic headers. We are not allowing users the option to break AutoMagic in the UI; if they are advanced enough to know they don’t want to use AutoMagic then they can edit the GRUB config file by hand.
We’ve come up with two possible design solutions (not in any particular order):
Design Option 1: Preemptive disabling
Move up/down arrows are provided to allow users to reorder entries. When an up or down move could potentially break AutoMagic, the button is disabled. When the user mouses over the disabled button, a tooltip provides them with some information on why it is unavailable (e.g. “You are using AutoMagic so moving this entry will break things in a Very Bad Way”). (The tool tip isn’t yet implemented and mocked up in the screenshot.)
Pros: Prevents the user from attempting an action they will always fail.
Cons: Why the move button is disabled may not be obvious, especially if the user has no idea what AutoMagic is.
Design Option 2: Post-action notification
An alternative to disabling the move buttons is to provide a warning message when the user tries to move an AutoMagic entry out of the AutoMagic list or an unmanaged kernel in to the AutoMagic list.
Pros: More obvious than the disabled move buttons.
Cons: We’re allowing users to attempt an action they will always fail. It would be better for users to know not to click the button and to not get a warning message than to be rudely surprised.
The few people I’ve interviewed (short interface walkthrough of both UIs) had a preference of one design option over the other, but overall there wasn’t a clear winner of either option. I don’t really have a preference myself, there are pros and cons to each design option. It just may be a matter of releasing one version and see how it does.
As a side discussion, is there an easy way to add a separator line in the list? Initially I thought of separating the lists in to two, AutoMagic and Other, but two lists don’t really make too much sense since we’re dealing with the concept of a single menu list. There were some good ideas that came out of the interviews including a line between the AutoMagic entries and other unmanaged entries. I think a separator (not just a border, it needs to look like it is part of the list widget, not a list item border) combined with one of the methods described above could be a strong enough message that says “Hey, you’re at the bottom of the editable part of the list” without being too distracting or too hard to figure out.
seele :: Jun.24.2008 :: Design, General, KDE/Kubuntu :: 21 Comments »