obso1337.org

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 »

Oy vey, this was not a personal stab at you, Aaron. You just happened to the developer the emailer mentioned. Next time I’ll be careful and anonymize.

Some general points:

• This is not my comment, these are comments I heard from the user community.
• Distros are making it easier for regular users to get development previews
• More than just developers and early adopters are reading Planet, but they might not understand how deep in the development process they are following
• We have regular users with access to development software who are getting frustrated with KDE because they can’t do what they see on TV
• This has nothing to do with usability; it is before usability is an issue so don’t put words in my mouth

It was a simple research question: “what effect [does] reading about and seeing developer screenshots has on our user base; especially after they try the latest beta release and realize they can’t do what they see”. This is more of a community issue than a technical issue. You guys are already working on a lot of this missing content, it just hasn’t been committed or released. The problem is, these regular users don’t know that, so they get frustrated and confused. Not because of bug crashes — they are aware and accept bug crashes as part of the “under development” experience. It is because content such as UI configuration options, plasmoids, etc. are no where to be found when they have seen them in screenshots/casts and talked about in blogs.

I won’t repeat the concerns I have on the effect of uninitiated users trying beta software and following development blogs might have overall. These are not users who have an already established a brand loyalty to KDE, but users who are new to Linux and KDE. We did a good job of reeling them in, but now we need to be careful about inadvertently driving them away with content for a different audience because they might be overzealous about previewing unreleased software.

A lot of new-to-Linux users don’t realize how volatile “under development” software can be. They think you have to download and compile from SVN to get really unfinished and unreleased software. There is a naive trust that if it is released and nicely packaged from their distro, it must be OK. This is probably because they come from a world where no sane company would risk their brand by releasing buggy software to the public. They have no deep-rooted loyalty to KDE yet, they just want a Linux system that works. We don’t want to lose these users because they have a bad experience trying a development Live CD or packages published by their distro.

(Keep in mind, I don’t think the fact that distros are packaging this software is a bad thing. It makes development software available to a lot of people who can help with testing and debugging. The problem is that the users who are testing and debugging are a different class of users than these “regular” users I talk about here.)

I didn’t realize opening up a topic for discussion in the community would get me labelled as a hand waver. Heavens forbid I try to be a team player and solve a problem with the team. But some good suggestions have come out of the sane discussions I’ve had about this issue.

Some people have mentioned that simply annotating screenshots and screencasts with SVN versions or dates could help these regular users understand they can’t do this yet with their packaged preview. Perhaps also try to be more clear about UI options versus what can only be done in configuration files and what isn’t even available yet. This would help users distinguish what should be in the environment versus what is under development and preempt a lot of their questions and concerns. If users had a better idea of what probably isn’t working, then they wont feel obligated to get upset about it.

seele :: Jun.24.2008 :: General, KDE/Kubuntu :: 21 Comments »

I received an interesting comment from a KDE4 user the other day:

When I read blog entries and see screenshots of KDE4 on people’s blogs like Aarons’, I find myself thinking “Wow, KDE4 looks pretty cool”.  But when I try to make my desktop look like that, I can’t.  There is nowhere in the UI to do what he’s done to his desktop, at least from what I could find.  The average user can’t get what he’s got.

To the Marketing Team: What is this doing to KDE4’s image? It can’t be helping, but is it hurting? How do users feel when they see these beautiful screenshots of KDE4, but can’t recreate them at home? The more mature KDE4 becomes, the more users are going to try it. Is it still too soon?

KDE4 started out targeted at developers and early adopters — those who like to run bleeding edge technology. But when will KDE4 be ready for the rest of the world? Doing something as simple as configuring your desktop is still a major project, with costs in both time and frustration. Kubuntu Intrepid Ibex is planning on shipping 4.1.3 this fall, which makes me a little nervous. How many Kubuntu users will be afraid to upgrade and leave their safe KDE 3.5 behind? How many Kubuntu users are we going to lose because they can’t make the KDE4 transition?

[Edit June 23 2008 18:55 EST]

OK, so I probably shouldn’t have marked this post under usability (bad habit since 90% of my posts are about design/usability). It’s really about product marketing and business.

The post was written because I was curious to know what effect reading about and seeing developer screenshots has on our user base; expecially after they try the latest beta release and realize they can’t do what they see. When 4.0 was released, I didn’t have this concern because 4.0 was marketed as a developer release and not recommended for production use. But 4.1 is supposed to be The Big One. This is where everyone switches to KDE4 and the world is a better place. I know a lot of what are featured in dev screenshots will be done eventually, the question is when? 4.1? 4.1.1? 4.1.3? We’ve got a month to go, will what we see now in blog posts be there at the end of July? Or is this future-Future they are talking about? What effect is the future-Future going to have on a release that hasn’t yet been released? What will stop users from thinking we haven’t delivered on our promises?

More and more users are trying KDE4, but they’re still finding it unready 6 months after release. Yes, there have been great improvements since 4.0 and people who have been using it consistently tell me how much it is shaping up. These are the developers and early adopters saying this, not current 3.5 users who don’t fit that category and are the majority of Kubuntu’s user base. The problem is that KDE4 still doesn’t compete with the stability and features 3.5. I don’t care about the evolved experience from 4.0 to 4.1. I care about the changed experience from 3.5 to 4.1 (particularly 4.1.3). That changed experience is what we’re selling in October, and I want to know if I should begin worrying early if we’re risking the Kubuntu brand.

The 4.1 beta preview will obviously have bug crashes, but there still seems to be a lot of content/configuration missing. Are there really going to be that many content changes between now and the July RC candidate that will address all of these issues? If so, then I’m too early to worry about anything. But what vital pieces are still going to be missing?

seele :: Jun.23.2008 :: General, KDE/Kubuntu :: 44 Comments »

Edited (for chat and channel noise) logs of my talk on Usability: Is it just about removing options? for yesterday’s Kubuntu Tutorials Day are available. As usual, I had much more information I wanted to cover than I actually did (I should learn how to type faster), but my audience seemed pleased with the content. If anyone who attended or reads the logs has questions about the material I covered, design methods, contributing, or open source usability in general, feel free to contact me (seele) in #kubuntu-devel (freenode.net).

seele :: Jun.16.2008 :: Asides, Design, KDE/Kubuntu :: Comments Off

I will be giving a talk about Usability and Kubuntu during the Kubuntu Tutorials Day on Sunday June 15, 2008 at 20:00UTC (16:00EST). I have to admit all the credit for the catchy talk title (Usability — is it just about removing options) goes to Jonathan.

seele :: Jun.13.2008 :: Asides, KDE/Kubuntu, Usability :: Comments Off