APR
13
2005

Reflections on usability...

Submitted by Ian Reinhart Geiser

this was a comment to [Usability, Usability, Usability] but it grew too big and figured it would best be in a blog.

Note I am not a usability expert, as I only took two courses in "Human factors in engineering". These where geared more towards industrial automation, where the users usually had minimal education, and the repercussions of "hitting a wrong button" usually resulted in death, dismemberment, or a very nasty mess to clean up. Computer usability is a bit different, but I feel some elements tie over.

It thus far has been my experience that developers who are forced to follow the tomes that MS and Apple have churned out for years usually won't. they tend to get creative, and usually don't want to sit with a pixel ruler trying to line crap up.

this is how most of the nuggets at the interface all of shame got there. not because the developer said "i wish to make the crappiest interface known to man" but because they didn't have the time or energy to read through the lengthy and complex style guide rules of their platform.

now there are two parts to usability, content and layout. now layout is something that we can and should enforce in code. there is no reason that we cannot define "standard layouts" that can be applied to a UI to provide things like center justification, balance, and just general alignment. having "standard buttons" to enforce a standard sizes and spacing. having "standard button groups" to enforce placement, order and size. we already have a great start with this in the area of kde:KStdGuiItem, and the kde:KDialogBase.

if as a developer i have a choice of using a class vs reading some thick book, i will use the class and be done with it. most normal humans can tell when something looks "off" but not all of them can figure out how to make it "look good".

for content imho this would best be served by using a process similar to i18n. developers give the controls their names, and a comment on what stuff should do. then we can have our usability engineers "translate" the UI into something usable. i am not sure how well this will work, but the usability people have to get more involved with the development as a start. we have enough armchair oss developers at osnews, we don't need any more :P

that said, I am pleased that usability is moving off of some silly flame infested list, and moving more into the forefront of kde development.

Comments

Hi Ian;

I'm basically already very excited about the amount of buzz around usability that has been growing loader and loader over a very long period of time. The willingness of the developers to work on this is needed first and foremost.

On the subject of automating layout; I don't know if alignment and sizing etc is all so very easy to fix in 'a class'.
Let me run by you a simple example I stumbled upon yesterday. The KWord config dialog has a panel to configure the KSpell component. The design uses code from kdelibs (the configure widget) and embeds that as one page in the KWord config.
Sounds great so far!

Unfortunately the solution had 2 margins applied; this leaves the KSpell2 dialog having a lot more room around it then the other ones. Well, "a lot" more is overdone; its just 11 pixels total. Most developers don't even notice this.

Now; if you can find a way to iterate over all widgets (and their children) in a widget you can quickly find out if margin has been added twice, and maybe even show the file/line where both widgets have been programmed.

Without such a solution the reaction from most developers will most likely be to let it be; its not a big enough problem to spent time on, more important bugs/features to add. (I spend 45 minutes trying to find out where the margin was added; and gave up).

By Thomas Zander at Wed, 04/13/2005 - 14:11

actually you can find out what a widgets current layout is. i had to solve this a few weeks ago for another project. basicly i was adding widgets to a container, and if there was no current layout applied in the container i made up my own.

the one horrible thing about the current Qt layouts is that they only have the concept of a margin and spacing. they lack the notion of margin.left spacing.right etc... i have a few hacks around this, but they are not pretty, and it would be nice if the trolls would update qt:QLayout to supply such things.

that said layouts are not the magic bullet, but they are a handy tool to help solve the problem. the "fantasy" solution i see in my mind is a place where you can throw a few widgets in a frame with general positions, and the layout takes it the rest of the way with respects to alignment, spacing and margins... now there is probably a fair bit of code between me and my fantasy, but it would be a nice place to aspire too.

By Ian Reinhart Geiser at Wed, 04/13/2005 - 14:41

You can addSpacing( int px ) to a QBoxLayout, which I've used a few times to create extra margin on one side. You can do this with QVBox/QHBox, but you need to cast the layout(), which is safe for Qt 3.x at least. Myabe for 4.x too, but I've yet to investigate.

By mxcl at Wed, 04/13/2005 - 18:31

this can be done for a single side? my big thing was to be able to have 3px spacing on the left and right sides, and then none on the top and bottom. if you have some example code that would rock.

By Ian Reinhart Geiser at Wed, 04/13/2005 - 22:17

I usually just add a new column (or 2) and set that to a specific size.

By Thomas Zander at Thu, 04/14/2005 - 15:01

... it makes things a bit overly complex to get them to be correct sizes and behaviors. Also inserting 4 extra qframes per cell is annoying.... or did you have another idea in mind?

By Ian Reinhart Geiser at Thu, 04/14/2005 - 19:07

My suggestion is not the spacing adjustment you wanted; but a more old fasioned way when we did not have spacing in the layouter yet.

Its basically 1 QFrame with 3 columns and 1 row. Your widget goes in the middle cell and the other two columns are set to a specific size. You probably want to set spacing and margin for that QFrame both to 0.

If the parent widget is not to complex you can do without the QFrame between your parent frame and your widget and simply make the parent frame have a lot of rows. This you can do in Designer using some fixed-width spacers.

If you still have no idea what I am on about; let me know I'll sent you a QtDesigner file with what I mean.

By Thomas Zander at Fri, 04/15/2005 - 17:13

Sorry to burst yours and Cornelius' bubble about usability, but if you think you're going to get four or five usability people involved at the core of KDE, have a HIG formulated and there won't be any long e-mail threads or discussions with users trying to work out what is actually happening, then I'm sorry. That's not what usability is about at all. If that's what you want then honestly, don't bother because it's a waste of time. You're thinking of usability as a pain-free, hard and fast coding process and it simply isn't.

Gnome does this today, and although their guidelines are nice and they have decent looking interfaces (which they really need, because of their technology base) the place that they really fall down is in looking at the processes users go through in how they actually use the desktop and applications, and what they're actually doing. Gnome is by no means a centre of usability wonderfullness, whatever anyone says.

Unfortunately, that flame infested list is where many people go to talk about what their problems are with KDE, and how they and others actually use KDE and its applicatons. It creates a lot of traffic, and most if it can be ignored, but sorry, that's all part of the process and it actually provides more valuable information than a HIG or code enforcement ever could by themselves. It's what Apple and Microsoft are able to do more successfully than any open source project at the moment. Read this:

http://blogs.msdn.com/rick_schaut/archive/2005/03/12/394480.aspx

and the bottom paragraph:

The difference between OSS and what we do isn't in the extent to which we listen to what customers have to say. Rather, the really significant difference is the effort we put into understanding users' high-level problems. That's a very costly, and time-consuming effort. It's not a job that hobbyist programmers, no matter how dedicated, can reasonably hope to accomplish.

I'm inclined to agree wholeheartedly on this one. This process involves a lot of long conversations, a lot of e-mail traffic and a lot of people just misunderstanding what they're actually trying to do to start off with (which is what most traffic is on the usability list, not flaming).

If the new usability drive within KDE doesn't take this into account then it's going to be a waste of time. There's no class called Usability you can inherit from I'm afraid, and you're missing the whole point.

By segedunum at Thu, 04/14/2005 - 13:03

We are well aware of the fact that adding a few usability people to KDE won't solve the problem. We are also well aware that a real solution takes time and long discussions.

The point is that we work on processes to actually make it possible to do all this in a constructive way, to get actual results and to get the results as well as the process accepted by developers. That's where KDE has made significant progress and that's where we will finally get a really usable desktop from.

What Rick says about hobbyist programmers is hardly relevant. It isn't the first time that a Microsoft guy is fundamentally wrong about open source development.

By Cornelius Schumacher at Thu, 04/14/2005 - 14:10

Pages