GNOME, free software, and user interfaces

Posted 20 Apr 2002 at 15:00 UTC by hp Share This

A web log entry from Matthew Thomas inspired me to write up some speculation about GNOME and the problem of creating a good user interface in a free software environment.

About Rhythmbox, posted 20 Apr 2002 at 16:54 UTC by hadess » (Master)

mpt took rhythmbox as an example of "Just copying Apple". I don't think that Rhythmbox should be picked on because of that. When people saw iTunes, it finally came to their minds that it was the "Right Way" to do it. If he was to come up with a better UI design, or if he pointed me to an MP3 player with a decent UI, I'd really take notice of it.

Meanwhile the UI in Rhythmbox, and in iTunes, kicks the crap out of every other mp3 player's UI. Now tell me if it wouldn't have been a better idea to take XMMS as an example. Copying a good UI from a commercial program is a good idea. Copying Winamp was a bad one. (BTW, if he wants a bad copy of iTunes, he should take a look at xtunes.)

Re: About Rhythmbox, posted 20 Apr 2002 at 17:06 UTC by hp » (Master)

I agree, in general people have ended up with better results copying well-tested well-thought-out prior art than trying to do their own thing. This is true in code as well as UI.

Doesn't mean innovation is impossible or never happens, just that innovation really shouldn't be the default mode of operation when dealing with something as complex as software. Other people have had tons of good ideas; use them. At minimum, understand the current wheel before you start in on reinvention.

Once we're really good at interfaces, we'll be in a better position to know when innovation makes sense and when it doesn't.

And Rhythmbox looks cool. ;-)

Gnome and usability, posted 20 Apr 2002 at 17:26 UTC by mslicker » (Journeyer)

Honestly, my biggest usability improvement came with the removal of Gnome and the instalation of twm.

First the loading time of twm is almost instantaneous, Gnome took about a minute if I remember correctly.

The menu, which can be accessed directly on the desktop, is much more responsive then the Gnome one. The only improvement I can think of is that it stays open when you click, instead of requiring you to drag the mouse.

twm is so simple, that user interface diappears after a while. By disappearing, I mean it ceases to get in the way and allows you to function in the windowing system without thinking. Minimization puts windows right on the desktop. This gives them a spatial relationship and allows you to access them much quicker than searching through the Gnome task bar.

I've also found an xterm shell much more usable than any file manager. I'm by far not a shell guru or any thing of the sort. I only use a few simple commands and a little piping.

My biggest gtk+ usability improvement came with the development of my own theme called "Flat". I found it also has the same quality as twm, in that doesn't get in your way, it empahsizes the semantically important parts of a user interface.

Overall, I have to say I'm pretty happy with my free software user interface.

If Gnome really wants to improve usability, I have the following advice:

  • Response is the most important.
  • Focus on simplicity, I notice you talk about the cost of preferences, try to eliminate preferences and options at all cost. These only complicate software, and complication is enemy of usability. As you remove features, eliminate complexity, you'll probably find the response will be faster as well. Usability is all about finding the simplest most productive way of doing something, remember this!
  • Embrace Unix, don't try to cover it up, you are a Unix gui! Address the problems with Unix directly. The fact that there are two worlds inside the computer only complicates the user's perpective of the software.
  • Learn from what others have done, Gnome could learn a lot from twm in particular.

Good Luck!

UIs are complex, so develop incrementally, and listen to users., posted 20 Apr 2002 at 17:51 UTC by murrayc » (Master)

The first step to UI development is to recognise that UI development is difficult. Anyone who has to provide UIs for a set of real people soon realises that even the simplest UI can generate a ton of change-requests and how-to questions. That's because people are complex, but in the end they do tend to have reproducible macro-level behaviour.

So, like any other complex system, the only way to get it right is to develop gradually, in phases. You can't assume that you understand users' needs until you've given them a chance to review your progress so far. It's only worthwhile to add features when you are sure that the existing features meet the needs. How can you choose the next fork in the road if you're not sure that you took the right fork last time?

To take nautilus as an example, it should have had a release which only implemented file browsing, with no fancy mp3/jpg/html viewing. Then it might have added the status bar. Then it might have implemented desktop drawing. Etcetera. It would have been easier to manage bug reports for these limited subsets, and to integrate any necessary changes. Each phase would have been a firm foundation for the next phase.

In summary, even now bugzilla is the best way to get good UIs. Because we don't know until people tell us.

Listen to the documentation, posted 20 Apr 2002 at 18:42 UTC by mbrubeck » (Journeyer)

Just today, the Audacity development list received a message from our documentation writer. He was working on a tutorial and wanted to instruct the user to perform a specific action. The instructions seemed too complicated, and he realized it was because the feature wasn't interacting well with the user. Rather than document the clumsy method that's currently possible, he had the good sense to make us implement a better method.

Writing documentation and answering user questions are good ways to discover interface improvements. If it takes too much explanation, maybe there's a better way to do it. After answering four or five user emails about the gain control in Audacity, I realized it would be in my best interest to give the damn thing a better interface. As Larry Wall points out, the lazy thing to do is change the code once rather than answer user questions for the rest of my life.

Re: Gnome and usability, posted 20 Apr 2002 at 18:43 UTC by hadess » (Master)

What exactly could GNOME learn from twm ? Gnome is 2 things: it's a set of libraries and guidelines ie. it's for creating applications (twm is not), and it's a desktop environment which twm really isn't. How can you compare twm, a window manager + a menu with a desktop environment that's accessible, contains control panels for all the usual preferences and settings one could want on an X11 workstation, that's i18n'ed, that contains a file manager, etc.

If you mean that GNOME takes longer to startup than twm, I agree, Window Maker takes under a second to start on my machine, all dockapps and other niceties included, but you gain so much by using the whole GNOME desktop environment that I don't feel that a window manager can stand the comparison. Stop comparing apples and oranges, we're on about applications and UI, it's not a GNOME wishlist.

And about the underlying Unix system, I agree that we shouldn't try to hide... It should be "integrated" into the Desktop. MacOS X is the best Unix GUI I've ever seen, and I'd want Linux to reach that level of simplicity, yet allowing the power users to reach down to use the power of the command-line. GNOME is on that track.

Re: Gnome and usability, posted 20 Apr 2002 at 19:25 UTC by mslicker » (Journeyer)

I don't think you read my post fully. I outlined things that Gnome could learn from twm. I also noted that I was happier with twm then Gnome, and some reasons why.

I'm not comparing apples to oranges. twm provides a desktop environment, Gnome does the same. In either you are not required to use Gnome applications. In fact I don't, so to me the only difference is what the desktop environment provides. The topic is partly focused on Gnome, so I feel my response was appropriate.

i18, perhaps. I'm an english speaker, so twm might be lacking in this area, I don't know.

X11 preferences? I had set this up by hand, I'm unware of a program that allows to modify these graphically.

File manager, many can be downloaded on a debain system. I don't use them, as I prefer the shell, and I see no usability improvement in using a file manager. BTW, I went from using a file manager to using the shell. I don't feel I'm biased in any way toward the shell.

copy..., posted 20 Apr 2002 at 21:48 UTC by Malx » (Journeyer)

hadess - I whould not call Winamp a bad GUI example. In our campus network it is the only player used for several reasons. Even FreeAMP, which is different and Free, is not so good. and WMxmms is just great for contoling xmms

hadess(but you gain so much by using the whole GNOME desktop)
I am not using any desktop env and I am not felling lost ;) Just WindowMaker and xterm+screen+pine/shell/mc/. I just do not need any of that ugly stuff you call "cool GUI software" ;) All I need works fine without GNOME or KDE (it may use gtk+, but no more). - gimp/mozilla/xmms etc.

mslicker - WindowManager is not a Desktop. You could use GNOME with many window managers - e.g WindowMaker, pehaps twm also.

i18n ? Just using "xrus" if I need it. In most cases X11 or Xterm (alt+shift) gives me ability to type anything I need on ru/uk languages.

Dialog buttons, posted 20 Apr 2002 at 22:05 UTC by ncm » (Master)

Is this a good place to complain about pervasive problems in Gnome?

Too bad, I'm going to do it anyway. Probably the single biggest improvement that could be made in the Gnome interface would be to eliminate all the "yes/no" default buttons in dialog boxes. Instead, the author should be obliged to choose appropriate verb phrases to put in the boxes: "discard message", "log out", "save for later", "send now".

An assertion in the code, to crash the program if any button label tries to display the string "Yes", "No, or "Cancel", would result in immeasurable immediate improvements to the entire Gnome corpus.

Dialog Buttons, posted 20 Apr 2002 at 22:49 UTC by murrayc » (Master)

The Yes|No buttons are already being removed.

Re: Dialog Buttons, posted 21 Apr 2002 at 00:24 UTC by hp » (Master)

That's already in the style guide and has already been changed for many apps.

To answer the question though, no this isn't the place. ;-) For a general point it should be discussed on and filed in bugzilla against the style guide. For specific violations of a point already in the guide, file a bugzilla report against the appropriate application.

What is a desktop?, posted 21 Apr 2002 at 00:49 UTC by mslicker » (Journeyer)

I'm curious why twm isn't considered a desktop. It uses the desktop metaphor anyway. Only with something you're actually likely to click on. It would be an interesting thing to know for desktops, how often their contents are actually used. Are all these objects really justified in staying on your screen permanently?

gnomic nivrana, posted 21 Apr 2002 at 00:53 UTC by garym » (Master)

I've been amazed by gnome/sawfish. In 25 years using these machines, this is so close to my ideal way of working the desktop that I no longer jump to upgrade for fear it may lose something. There's lots of stuff I wish I could strip out (like extra menu junk) but overall, it's the best I've had thus far in computing.

So far as I can tell, though,the single most effective improvement to the gnome desktop is completely encapsulated by this tupid form I am using now to type this post: All edit boxes in all applications are nothing more than multi-line browser-forms. No spell check, no "insert file here", no calculate and paste ... even less than I had in 1980's vintage DOS WordStar. To do anything beyond type, I have to go outside the current focus, and to do anything serious, I have to cut and paste from here to a real edit window, do the edit, then cut and paste back to the form window. I have to break my work flow just to get work done.

Then it hit me: What I really want is for all edit panes in all applications to be gnuclient processes hooked to a centralized emacs gnuserver process! "Egad!" I thought, "what a twisted, evil and cruel idea" ... but I want it nonetheless.

Don't strive for the One True UI, posted 21 Apr 2002 at 09:37 UTC by tk » (Observer)

I guess I should write something here before Ilan once more comes along and extols the virtues of the One True Mac Way...

People are different. Some people think it irksome to type rm foo, while others don't like moving the mouse to a file name and clicking on it to remove a file. The difference is probably due to many factors, including the user's typing speed, the first OS he used, the number of cats and dogs he has, etc. (By the way, I belong to the latter camp.)

So indeed, creating a `one size fits all' UI is difficult, perhaps even impossible.

However, one doesn't need to create the One True UI. Nowadays the Linux user has a choice of several window managers, from the spartan (Blackbox, FVWM, ...) to the feature-packed (GNOME, KDE, ...). In fact, one may also not use any WM at all, and do everything from the text console! There's therefore no reason to insist that all the qualities of good UIs must be included under the GNOME banner.

Thus instead of trying to cater to the hypothetical "average user", the GNOME project may do well to pick a specific target audience (e.g. Win9x bail-outs / Mac bail-outs / ...), and focus on that.

Re: Gnome and usability, posted 21 Apr 2002 at 13:34 UTC by bratsche » (Master)

mslicker: Clearly your definition of usability is completely different from every other person's definition when you consider a UNIX terminal to be good. =)

I disagree that we should embrace UNIX with respect to GUIs. Partly because I don't really understand what you mean by that, but partly because I'm pretty sure that if I did understand I would disagree. It just sounds wrong! What we are striving for is an interface where the average Joe's mom can sit down and basically figure out how to use the machine without being told what to do. UNIX is not striving for this, never has, and never will. If it wanted to be usable, it would have commands called "move", "copy", and "list". Instead it has "mv", "cp", and "ls". Pipes? Fucking no way is someone ever going to just figure it out! The point of a nice usable GUI is not to embrace our UNIX underpinnings, but to hide the fact that they suck ass.

Thoughts on hp's essay, posted 21 Apr 2002 at 14:51 UTC by gerv » (Master)

[Amusing anecdote: when compiling the first version of this reply, I went for Ctrl-W and hit Ctrl-Q by mistake, closing the browser window and losing the contents of the form. Is this the fault of: a) The person who defined the QWERTY keyboard, putting _W_indow and _Q_uit next to each other? b) Microsoft, who originally chose Ctrl-W and Ctrl-Q for Close Window and Quit c) The Mozilla Project, who decided to also use those keys d) Mozilla, for not either saving the data or asking for confirmation when you close an edited form e) Canada ?]

Disclaimer: I'm a member of staff, have an interest in UI issues, work as part of the Mozilla UI process which mpt quite rightly claims sucks, and work with mpt a lot.

hp: I was fascinated by your change of mpt's points to relate them to code instead of UI. But I think your conclusion - that UI is just another hard problem, and we solved hard code problems, so we can solve this - is flawed; or, at least, the techniques cannot be the same.

The key difference between code and UI is that, in general, code improves incrementally. Every new build works just a bit better - a new ability, a few fixed crashes. UI, on the other hand, can't work like that, because if one small part of your UI changes with each build, your testers and users will soon be completely uncertain as to where to find anything. There is a threshold of improvement, below which a small change is not worth making. So UI tends to change, if it changes at all, in big seismic shifts.

You also mis-convert "too many cooks" to "Too many cooks spoil the code's architecture". The "too many cooks" problem in UI is only partly that a lot of people design the UI, but it's also that a lot of people have views - and spend lots of time expressing those views, and dragging out argument and debate. These can include anyone who's ever used the product. This means the pool of arguers and debaters is far larger than that for code, and the level of noise is therefore much greater.

There is also the issue of UI consistency. If you have a large application broken up into a number of modules, you can have a lead architect for each module. They can implement it however they like, as long as they define and publish interfaces for everyone else. This makes the problem manageable.

The same is not true for UI - you cannot have five people doing the UI for five different parts of your application, all with the creative freedom to do as they think best. The result would be a nightmare.

The UI problem is not a restatement of the code problem. (That's part of what makes working on solving it so much fun. :-)

  • Designers can't submit code patches.

It's interesting that mpt makes this point, given that he works on a project whose UI is the easiest UI to hack on that I've ever seen. If you use <plug> Patch Maker </plug>, then you don't even need to compile the code, and can do real-time WYSIWYG UI editing.

One last point - mpt claims that commercial companies hurt UI; presumably this is from his experience on the Mozilla project, where Netscape's UI team has to balance the conflicting demands of their marketing department, their own views on UI, and the views of 1000 community members, inside a UI design process which is still unclear (and that's our fault; but they have shot down or throttled attempts to define one.)


Re: Gnome and usability, posted 21 Apr 2002 at 15:51 UTC by mslicker » (Journeyer)

bratsche I don't have any definitions of usability, I welcome a better way. My point was that file managers have not done that for me.

My assumtion going into this argument is that usability is an objective science, that there is a an objective right and wrong. I still try to mantain this, otherwise how is there any hope for improvement? Usability for instance tells us that he dvorak keyboard layout is more effiecient than the standard keyboard layout. Fitts law tells how fast one can click a target given the relative distance and target area. These basic things are largely ignored by usability "experts".

Additionaly, I think part of the problem in the given discussion, is that there are two parts to usability. The learning curve and long term productivity. Your measure of usability purely learning curve, where mine is purely long term productiviy. If someone is going to a use a computer very infrequently, for short periods of time then long term productivity is irrelevant. Similarly if someone is going to use a computer everyday, then learning curve become negligible.

I guess I don't really know what Gnome's target is. It is certainly not long term productivy. My guess is the target has little to do with usability, but what ever is currently popular in proprietary interfaces.

More comments, posted 21 Apr 2002 at 16:55 UTC by hadess » (Master)

mslicker: I don't think you really understand what I'm pointing. Let me ask, would you Mom or Pop or Granny be able to use your setup and feel comfortable without knowing it. Probably not, so it's not usable. I can certainly also setup my machine like that (I've been using Window Maker, and AfterStep back in the days wmaker didn't exist), I would hardly call that usable. Sure you can learn, but not as fast as you would in front of an integrated desktop system.

Malix: Winamp is one of the worst UIs ever, along with Apple's Quicktime. About WindowMaker and xterm+screen+pine/shell/mc/, would your Mom be able to use it ? GNOME is integrated, console applications are hardly integrated/sharing the same look and feel/etc. And xrus is a keyboard switcher, that's not i18n. i18n is me having his "Recycle Bin" on the Desktop be called a "Wastebasket", it's translations, it's the Mom and Pop from Sweden reading stuff on their screen that's in their language. Look at your WM dockapps and tell me how many of them have gettext() support.

You guys seem to be forgetting that we're not talking about what makes you productive. We're talking about what makes it usable, for a person seeing the desktop the first time, for a person seeing an application the first time. The fact that you're posting here discards you saying "I'm using something that's usable". Something that's usable is for example me replacing my "vfscat | madplay - " by a 100 lines GUI application that integrates with the GNOME desktop.

More comments, posted 21 Apr 2002 at 16:57 UTC by hadess » (Master)

mslicker: I don't think you really understand what I'm pointing. Let me ask, would you Mom or Pop or Granny be able to use your setup and feel comfortable without knowing it. Probably not, so it's not usable. I can certainly also setup my machine like that (I've been using Window Maker, and AfterStep back in the days wmaker didn't exist), I would hardly call that usable. Sure you can learn, but not as fast as you would in front of an integrated desktop system.

Malix: Winamp is one of the worst UIs ever, along with Apple's Quicktime. About WindowMaker and xterm+screen+pine/shell/mc/, would your Mom be able to use it ? GNOME is integrated, console applications are hardly integrated/sharing the same look and feel/etc. And xrus is a keyboard switcher, that's not i18n. i18n is me having his "Recycle Bin" on the Desktop be called a "Wastebasket", it's translations, it's the Mom and Pop from Sweden reading stuff on their screen that's in their language. Look at your WM dockapps and tell me how many of them have gettext() support.

You guys seem to be forgetting that we're not talking about what makes you productive. We're talking about what makes it usable, for a person seeing the desktop the first time, for a person seeing an application the first time. The fact that you're posting here discards you saying "I'm using something that's usable". Something that's usable is for example me replacing my "vfscat | madplay - " by a 100 lines GUI application that integrates with the GNOME desktop.

bike sheds and opinions, posted 21 Apr 2002 at 17:14 UTC by jimw » (Master)

the facet of the too many cooks problem that i think really plagues ui design is what the freebsd developers call a "bike shed discussion". everyone uses interfaces all the time, therefore they have an opinion about those interfaces, and are all too willing to share it. sometimes very loudly.

think it doesn't happen among coders? then you've probably had the good fortune to not have to watch endless cycles of coding standard discussions.

gerv: The same is not true for UI - you cannot have five people doing the UI for five different parts of your application, all with the creative freedom to do as they think best. The result would be a nightmare. if you ever feel the need to validate this opinion, take a look at lotus notes (circa version 4, i don't have any experience with later versions). i would swear that product had at least five different ui designers, all with competing, and bad, visions.

Oh please..., posted 21 Apr 2002 at 17:23 UTC by tk » (Observer)

mslicker, Malx and hadess seems to be engaged in a logomachy. Looks like the only way in which a meaningful discussion about UIs can be carried out is when people define the target audience.

Also, hadess may be interested to know that a person isn't going to use an application for "the first time" forever. Thus an application must be friendly to its intended user not only for the first time, but it musn't get in the way of the user once he's experienced enough. If this means creating different mechanisms for new-timers and old-timers, I say so be it.

Why coding UI is hard, posted 21 Apr 2002 at 17:56 UTC by jlbec » (Master)

Having spent the past two years coding the interface software for a consumer web appliance (the New Internet Computer), I've spent a lot of time thinking about -- and especially arguing about -- good UI. There is a fundamental reason, IMHO, Free Software coders have trouble creating good UI:

To create a good UI, a programmer must be willing to create an interface they may hate to use
This sounds harsh, but it is often true. I've spent many an hour beating my head against a particular UI bit only to finally be convinced by co-workers why it is the Right Thing.

The best example is the Macintosh. I hate using the Macintosh. I dislike click-to-focus, and I absolutely hate the top-of-screen menu bar. But after beating my head against it, I understand completely why these are the proper choices for the run-of-the-mill user. The principle of least suprise matters here.

Why is this Right? Why not just a preference for "click-to-focus" versus "focus-follows-mouse"? Because if you have a preference, the run-of-the-mill user will eventually find it. They might try it. Then they might find their computer unusable. There are many, many preferences that fit into this category. When deciding on UI for the web appliance, we ended up with a simple rule on preferences: "Do we have to ask the user about this?" If the answer was "No," we would pick a side and stick with it. The run-of-the-mill user does not want a preference. They want the machine to get out of the way of browsing and emailing.

Good examples of this were things like click-to-focus, fonts, and keybindings. On the other side were things like screen size (we ended up supporting two screen resolutions) and cookie behavior. Enough of the run-of-the-mill world understands and expects to be able to change cookie behavior, so the preference had to be included (It was one of our largest complaints about initial test versions).

Apple, like all commercial houses, has an advantage here. They can say "It will be this way, and you will like it." from on high. In free software, the developer is scratching their personal itch. Why would they write something they would not like to use? Of course they wouldn't. So if the "correct" way for the run-of-the-mill user is different then their own preference, they insert an application preference rather than doing what they would not like.

The attitude "I just need my shells" is the killer here. I know. I have that attitude. I still do. The biggest learning experience I've had recently was making an effort to use Nautilus to manage my files. Tigert convinced me that this was the way to go, and I finally tried it. He was right. It can be better for actual management. Cleaning up my home directory took 1/4 the time it takes in the shell. Try it some time with an open mind, it can be enlightening.

This isn't to say that I'm going all GUI. I have a .sig that reads "Nature abhors a GUI". It's Ha-Ha-Only-Serious. GUI can, in many ways, get in the way of what one is trying to do. I think that is the fault of bad GUI, not the fault of GUI itself.

IMHO, MacOS X is the best commercial OS ever created. Why? It does the absolute best job of getting out of the user's way. I think that is the ultimate test of UI. Real Users (not techies, Users) don't even want to know they are using q computer, they just want to get their task done. A UI that gets out of their way is the UI that is Right.

Incremental revisions, posted 21 Apr 2002 at 18:22 UTC by sits » (Journeyer)

Many well respect pieces of software only make incremental revisions to their user interface (things like Photoshop do not have overhauls from version to version) thus piecemeal changes are probably the only way of ushering improvement when your user base is large. Add to this that the sad fact that existing users can learn to like some bad behaviour in User Interfaces - links are better of being blue because that is what users expect despite the fact we have less receptors in our eyes for identifying blue thus making it a slighly more difficult colour to read). If what was/is bad becomes standard, you may be better off doing it anyway.

An idea for (parts of a) solution, posted 21 Apr 2002 at 23:08 UTC by piman » (Journeyer)

A lot of the problems described revolve around menu/button names - for example, I'm looking at Galeon right now, and one of my preference panels is "MIME Types". The average user would much rather see "File Types", or even "File Viewers", since that's what it really is. On the other hand, I like "MIME Types" because I know what MIME is, and to me it's more descriptive than "File Viewers".

Why not solve this the same way we've been solving text string problems for years now, with gettext()? The default "C" or "en" locale (in my case) would say "File Viewers", but I could set LANG to "en-JARGON" and get "MIME Types". "Work Offline" (which IMO is a good label for average users) would become "Use Cache Only". This lets both groups be happy, and doesn't require any changes to code at all, just new translation files.

This doesn't solve the problems of things like "Advanced" dialogs or too many preferences, but it covers most of the textual problems.

Re: Gnome and usability, posted 22 Apr 2002 at 02:13 UTC by bratsche » (Master)

mslicker: You make an interesting point. However, long-term usability is not nearly as difficult of a problem as short-term, because almost anyone can learn to use a non-intuitive interface if they're told how. If I teach my mother that "mv" can be used to rename a file, she then has the long-term knowledge of how to do this.

Making the interface easy to use immediately is the challenge that projects like GNOME and KDE face. At least, this is what they should be aiming for, in my opinion.

Why Usability is Hard for Most Programmers, posted 22 Apr 2002 at 06:40 UTC by mjs » (Master)

As a GNOME developer who currently works for Apple Computer, I have some thoughts on this subject.

The reason many programmers have a hard time with usability is not because they have fundamentally different UI needs, but that it involves a very different mode of thinking. Programmers like to think in terms of logic, and absolute principles. But a lot of UI design is about applying good taste, and making tradeoffs.

In terms of code design, there can be some disagreements, but a lot of issues can be resolved in fairly black and white terms. It's not too hard to determine what code works and what doesn't by trying it.

But with UI, it's rarely possible to make absolute judgement calls. To some extent, user testing is a good final arbiter of whether a UI works, but when two designs are both adequate, it won't tell you that much about which design is better. For that you need good judgement.

It's true that there are some broad principles in interface design, but all of them need to be violated sometimes, and indeed to some extent there is tension between them. For example, it's good to use existing visual elements, because users will be immediately familiar with them. But on the other hand, it's good to express possible actions in the way that is most appropriate to that specific situation. Just knowing about these two principles will not in itself help you find the right balance between them.

Some programmers who learn about usability latch onto these general guidelines as if they are the real substance of the field, rather than one of many tools. Sadly, I think Havoc's article exhibits some of this kind of thinking. It seems to presume that if you follow particular rules, then you will automatically get good UI.

All of this notwithstanding, I do think that GNOME is doing a lot better in terms of usability than most other free software projects. A lot of things have been streamlined. But there is still a long way to go to reach the elegant simplicity of Mac OS X. Try throwing a new user in front of Evolution and another in front of Mail and see the difference.

desktops, edits, One True UI, i18n/l18n, posted 22 Apr 2002 at 23:16 UTC by Malx » (Journeyer)

mslicker - it is. I am not using it, but have had an example on my win32 desktop.

I had 2 icons - uudecode.bat (which is bat file with line uudecode %1) and some file.uu. Then I DnD file.uu over uudecode.bat and after DOS window flashes I had new icon on desktop - it was image.jpg, extracted from UU archive ;-)

It is just great! But I know no porgrams which behaves same way (do something and close itself). Even WinZip stays open after DnD from desktop.

garym & all - please vote for bug:
Mozilla bug #103767 (RFE] Key to start $EDITOR for <textarea> (external text editor))

tk - ( one doesn't need to create the One True UI)
But If there whould be same UI conception it whould be the best thing in the world!

Just to illustrate - In Win32 user interface and API (programmers interface) to do same thing (say to "Save file in MS Word") - are quite different. Actually you need to read DOCs on VB to do second task.
If you whould look at Unix console utils you whould notice , that you need not special documentation to be SHELL programmer or just user - Output is the same, api i the same. You could type "ls -l" and make simple software tool "ls -l| grep ddd" - AND! there is magic! - "ls" program generates same output in both cases!
The problem with GUI - you can't (have any actualy try to?) make interface wich whould be same for user and programmer?

ImageShaker? Even Web-Pallications could be used that way (but somewhat dificult) - you could fill form, or you could ask brouwser to prefill it automatically, or even just call directly http://url/script?va=val&var=val. And all this comes true thanking to "Location" bar and "View Source". - You can't do easily "View Source" for any GNOME/gtk dialog box ;-)))))))

Actually the UI is HTML there - but It could be converted to TXT (lynx) or GUI (mozilla) or just console line in (perl script). There is NO SUCH user interface with GUI. There IS such interface with console apps (example - gdb is console app, but it is easy to add GUI - ddd).

So - I hate GUI, becouse it is for users ONLY. :) And love console and HTML - they are for both!
(btw - XML is for programmers only ;) so I also hate it).

gerv( The key difference between code and UI is that, in general, code improves incrementally.)
How about diff of XUL?

(* Designers can't submit code patches.)
That's why WebDesigner split HTML from Design and from Software - They implement templates. When templates whould be made ordinary software? ;-) XUL?

hadess - Sorry - You are right about all. (btw i18n != l18n :)
The only thing I could answer - There must be NO icon with name "Konqueror", there must be icon "Browse WWW", same - not "Nautilus", but "Read mail"

old/new timers, posted 22 Apr 2002 at 23:27 UTC by Malx » (Journeyer)

tk You have forgot that there is people, which are newtimer, but they are geting to be old-timers. :)
I have submited bug to GIMP with request "show default shortcut keys in tooltips" - So user, wich fist see Gimp could easily learn with of keys call which tool (button). You need to define process of learning. You shouln't just send him to manual. (IMHO).

(define the target audience)
Define target audience of WWW ? :)
It is not a joke - WWW could be used by new comers and programmer (to automatically fetch parts of site - Ex. to write script, which will check for new answers on Advogato :)

I would be glad to see same UI in Unix graphics :) (still HTML/web will not answer problem of step-by-step education of user from newcomer to software developer, but It is much easie than to become C programer looking at GNOME app UI ;)

LOCALES en-jargon etc, posted 22 Apr 2002 at 23:38 UTC by Malx » (Journeyer)

piman (but I could set LANG to "en-JARGON" and get "MIME Types")
Good point!!! I like it.

But it is only until you (as admin) will try to teach some user over phone line how to view his files ;)
This whould lead to something like babel chaos :)

Re: Locales, posted 23 Apr 2002 at 00:42 UTC by piman » (Journeyer)

Malx, I actually thought of that this morning. Basically, this means admins would be stuck using the normal locale. :) Or, they would have to give instructions like "The third item on the list". Still, ideally, this would end up reducing that kind of help.

..., posted 23 Apr 2002 at 03:03 UTC by tk » (Observer)

bratsche says, However, long-term usability is not nearly as difficult of a problem as short-term, because almost anyone can learn to use a non-intuitive interface if they're told how. This is a strange proposition. Doesn't it mean that a GUI should be designed with the expectation that it'll be abandoned later on?

I agree with mjs. It seems that even among `experts', the craft of UI design is still a black art.

Every day the bucket a-go a well..., posted 23 Apr 2002 at 06:17 UTC by Ilan » (Master)

Let me say that I read mpt's article. I thought that it was the most accurate depiction of the usability problems that currently exist in free software. Everything that has been really bothering me for the last two years, every stupidity I have come across, has been condensed down into a nice little list. Three cheers for the dude from Mozilla!

...One day the bottom a-go drop out

tk, I have been extraordinaly kind with you because I consider my diary entries to be just that and not forum posts. I therefore do not respond to your inane and ill-informed responses to my diary entries because that would be stepping outside of what I consider to be boundaries of the diary entry system. You have, with your reference to me in the "Articles" section, taken this outside the boundaries of the diary system. Since this *is* what I consider to be a valid forum, your pre-emptive response is officially fair game. I actually like it that way. From now on, if anyone has anything to say to me about my diary entries, we can go ahead and "take it outside" in the articles section.

'I agree with mjs. It seems that even among `experts', the craft of UI design is still a black art.'

People like you, tk, who refuse to acknowledge that UI design and research is a valid field of study, who refuse to believe that cognitive psychology can be applied to computer interfaces to make them more efficient and less confusing, and who generally express extreme hostility towards usability people have done more to effectively crush linux on the desktop than Bill Gates ever could (which is kind of ironic, considering how much you whine about Microsoft's dominance and why people choose Microsoft over free software). Bill Gates doesn't have to lift a finger because people like you do his job for him. I certainly hope that you don't represent most of the linux developer community, because if that is the case, the only thing that linux will ever be is an OS written by nerds for nerds. With people like you, and some kernel hackers who feel that strongly about those who "have made a living out of criticism of others work", it is really no wonder that there is such a dire shortage of designers in the free software movement. Congratulations; you've chased away the only people who could have helped you.

I'll also add that I really don't put much stock in anything you say; if someone as technically inclined as yourself reads some of "The Humane Interface", a book that goes out of it's way to try to explain to people of technical/scientific backgrounds using things such as math, science, and hard statistics, that good interface can be qualified and quantified, and you still didn't understand a damn thing or didn't consider it worthwhile or thought provoking, then any opinion about user interfaces you have is lacking in worth.

Rant finished, (it was soooo worth it, even if I get bumped down to observer for it. But it would be a shame for the Advogato community to lose the graphical XML-RPC client I'm working on), I'll say I do agree with Maciej, but not in the way that tk intended. The judgement issue is not so much a "black art" as it is a series of engineering tradeoffs. Every decision you make in designing a user interface has a consequence. As David K. Every says, "there is no such thing as a free feature". If I put the button all the way over here, there's less likely the chance the user will accidently hit it when going for the button right next to it. I put the button far away so it won't get hit accidently, then any relationship that exists between the buttons if they perform related actions becomes far more ambiguous than it would have been if the buttons were placed next to each other. Tradeoffs. Same as in computer science, except the computer is carbon-based, not silicon-based, and it speaks an entirely different protocol.

Enough responding to people's comments. My own material.

Well, I've got a lot of stuff to do, so I won't craft an entire essay. But I will repost a slashdot post of mine that expresses my basic opinion about why free software sucks.

"Newbies to GUI design making GUI's for newbies to linux" by Ilan Volow

Most linux programmers come from a developer community that up until recently hasn't been tasked with designing user friendly interfaces or has even considered UI design very important. For almost 30 years, the target audience for unix software has been either other unix geeks or servers, and human non-geeks never really figured into the picture. We keep hearing "Linux has already gotten so far on the server, it's only a matter of time till it gets as far on the desktop". It is incredibly naive for the linux development community to think that any of its attitudes, design values, and methodologies are going to carry over from the server to the desktop just because they met with success in a server closet. Linux got as far as it did on the server because linux programmers were the absolute best kind of people you could ever hope for to do server stuff. Unfortunately, they were the absolute worst kind of people you could have ever sent to do desktop stuff.

The reason why MacOS X is currently the most successful unix desktop (with people who aren't geeks) is that the mac development community has always been very committed to designing usable and consistent interfaces. They don't have 30 years of anti-newbie, RTFM baggage they've got to get rid of, and no one has a problem saying the word "folder" instead of "directory"*

To get to the point that the mac community is at, linux developers will have to undergo a radical attitude debugging. The problem the linux development community faces is not a technological problem like the kind they've had in the past, but a people problem. Unfortunately, fixing people problems is a hell of a lot harder than fixing technological ones.

*Note--this is a reference to a debate that happened approximately 1.5-2 years ago on the gnome-gui mailing list (may it RIP), where it was argued whether to use the "folder" (for purposes of consistency with the visual desktop metaphor) or the term "directory" (for purposes of religion). In a nod to Havoc's essay, before the issue was dropped altogether, some people suggested that use of the term "folder" or "directory" should be made a preference.

Re: Every day the bucket a-go a well..., posted 23 Apr 2002 at 06:57 UTC by tk » (Observer)

Ilan: If you didn't reply to a previous article earlier with similar assertions, I won't bother to do this. Yesterday I've already prepared a rejoinder to the statements you've made so far. Read it in its entirety several times over before you think you understand it. I decided not to paste it here, because a large part of it isn't really GNOME-related.

User interfaces, posted 23 Apr 2002 at 07:47 UTC by ingvar » (Master)

One thing that always amazes me in a debate on user interfaces is (as has been pointed out multiple times in replies to this article) that different people want different things from a user interface. Also, the same person wants different things from a user interface at different times.

What I want from a user interface (graphical or textual) is something that lets me do complex tasks in simple ways. And to do different different complex tasks in different ways. I also want to do simple tasks in simple ways, but I can live with infrequent simple tasks being difficult to do.

Now that you're actually listening, Ilan..., posted 23 Apr 2002 at 08:08 UTC by jdub » (Master)

Ilan, you're a nutball.

You've been pissing on about your brilliance, and everyone else's lack of talent in your diaries for ages now, without anything to show for it.

Meanwhile, there are plenty of people - coders and non-coders - contributing to user-oriented Free Software projects every day. Doing incredible things with existing software, not wanking on about pie-in-the-sky bullshit or denigrating other projects without making a contribution.

Even in this little rant, you've threatened to not release your graphical XML-RPC interface for Advogato if you were ostracised (or decertified). You know what? No one gives a fuck. Why?

I'm sure you don't like the phrase "code talks", because you'd find it horrendously offensive to your concept of the Free Software user and what Free Software should be about (ie. fulfulling your thankless, graciousless greed for free-as-in-beer software, and supporting your rude and obnoxious criticism of developers, despite the enormous amount of work that goes into it every day). Let's put it this way: "contributions talk".

I'm in awe of the achievements of Free Software, from the Linux kernel up to the great Free Software user environments we have today. I don't bitch and moan - our hackers are doing this for love, not money. I thank the people who work hard on the software I use. I shower praise on them. It's getting better every day - do you watch the cvs commits to KDE or GNOME? We're getting better twenty four hours of every day. I'm patient, positive, enthusiastic.

I don't think you have the passion, love or dedication to get what you want out of Free Software, let alone give back. So, one of my favourite quotes about Free Software, from mjs:

"Everyone says they like Free Software - not everyone is ready to make the tough choices to make it happen." - Maciej Stachowiak

Ilan, you're a nutball.

what a waste..., posted 23 Apr 2002 at 08:42 UTC by ishamael » (Journeyer)

Ilan: the words 'ass clown' come to mind. I've read The Humane Interface and it was mostly "umm, so?"

the problem with all this talk about interfaces and efficiency and whats better and whats not and blah blah blah is that it doesnt matter. i mean, its nice to prove that having a menu at the absolute edge of the screen is more efficient, since people can overshoot without having to reposition, but where does it get us? microsoft doesnt care it would seem, gnome & kde are going to talk and talk and talk about whats best until everyone's ears fall off, and apple is going to be in the corner, rolled up fetus-style murmering "we're right, we're right, we're right"

its never going to be right.

even your precious macosx is horribly flawed. i wish people would just get this and move on. lets just keep doing what seems to work at the time, please. lets just keep repeating flawed designs, please. and PLEASE: stop trying to design the perfect gui.

sigh, ill keep pushing what looks like the right button, and searching for such-and-such-a-function, thank you very much.

sum, posted 23 Apr 2002 at 13:00 UTC by Malx » (Journeyer)

First of all - what whould you think about creating UI mail-list (wich will not be bound to specific project like GNOME)?

Second - I thinks it is obvious, that you need to separate coding from UI design. And this must be done by different people, coordinated by 3d people.
(Same way is in our webdesign companies - 1.designer, 2.html coder, 3. software developer (server/client side))

Third - UI must be external to software. Software must define only features, not visual representation of them. (Same way CSS is split from HTML and HTML is actual result of some script program).

Forth - editing of T/GUI must be independent from coders and requires no code recompilation. It is skins actually but with free layout of elements (buttons, lists, etc). Also some means of dynamic selection of skin must be present. (You should add Localization (l18n) support on this stage - so you could dynamically switch inteface language without any disruption of programm (ex. FAR, TheBat, Mozilla). It will allow to use en-geek for your own use, but switch to en-default for user support. User must clearly see which l18n he using now (en-default or ru-geek etc.)

misc - all other is details:

For example you could intergrate some sniffer tool, wich will proxy all interface queries from app to display engine. This will allow to get statistics about user mistakes (Ex. if hi hit "Cancel" too often after hiting some button).

There should be tools to study(View Source) and change on the fly T/GUI bits. (Ex. This tool already exists and called "editres". It is works well with _good_ _Xwindow_ _toolkit_. The only Good Xwindow Toolkit I know is Motif/Open motif ;)

There must be some language to descripbe look-and-feel. And some WISIWYG editor to edit it (same as in Mozilla - skin editor). You could easily make diffs and patches to this language files (XUL).

There must be standart guidelines to some fisiological aspects of human-computer interaction (Ex. noted aspects of "blue" color). And tools to automatically check this (some design quality calculator, with is check keyboard layout + shortcuts of APP, buttons layout + their basic functions(action, submit, cancel) etc.)

This separation UI from software product will help to make automated tests. There whould be some Test-UI-Engine instead of Graphics-UI-Engine. and that is all. If you need both - you just install some pipe spliter, which sends 2 streams from app to both engines - and you see how test is going.

Any comments? (am I talking to much? :)

Bang these two rocks together..., posted 23 Apr 2002 at 13:24 UTC by jdub » (Master)

Malx: That's an interesting technology solution to a non-technology problem. :-)

Squeak, posted 23 Apr 2002 at 23:45 UTC by timcw » (Apprentice)

I think everyone interested in UI should check out Squeak and how they blend Morphic w/ MVC. It was an eye-opener for me anyhow, coming from a mostly "window-oriented" (WindowMaker, KDE, GNOME, Windows9x, etc.) background.

Re: Squeak, posted 24 Apr 2002 at 07:51 UTC by tk » (Observer)


Squeak, posted 25 Apr 2002 at 13:57 UTC by Malx » (Journeyer)

timcw - "Bandwidth Limit Exceeded". Even Google says so ;) But also points to: - understanding - mouse/key ref - Screen UI


jdub - thx! ;-)

tk Have you tried to _click_ on URL you have posted? :)
BTW - what is xwd?
About load/save - you can't get rid of them until OS will fully manage "no disk space/quota limits" nicely itself. Until then user must be aware about disk space and manage his files manually.

Re: Squeak, posted 25 Apr 2002 at 14:34 UTC by tk » (Observer)

Malx: Sorry, the link stands corrected. Cheese! Unpack and pipe to xwud.

Some thoughts, posted 26 Apr 2002 at 06:20 UTC by raph » (Master)

First, thanks to hp for posting such a thought-provoking essay. It's exactly the blend of advocacy, insight, and good writing that I have in mind for the ideal Advogato article.

Some of the responses were interesting too, but many are primarily useful for shedding more light on why we, as a community, have been able to produce GUI's that suck so hard.

hp is absolutely right about one thing: usability bugs are bugs, and need to be treated as such. Historically, the free software community's approach to usability bugs has been quite similar to Microsoft's to security bugs: deny they're real or important, ignore them, continue to make the same stupid mistakes. Hopefully, that will change.

One of the biggest, least controversial, yet seemingly most intractable classes of usability bugs is inconsistency. It's easy to see how it comes about; a modern desktop consists of many, many components, by many, many authors, each with his own ideas about how things should work. Nobody needs a user study to tell them that inconsistency is bad for usability. But getting rid of it is hard. I'm fond of marveling at how long it's taken us to make the backspace key work reliably. But I think we've more or less accomplished this, within the world of free software anyway (try to interoperate with proprietary Unix systems and all bets are off). Hey, one down, 100-103 left to go!

Configurability is a powerful tool that could be used to improve consistency, but historically has been used to make it worse. For this reason, I'm very hopeful that Richard Stallman has called for a common theme configuration standard between Gnome and Kde.

A similar argument goes for X's philosophy of separating mechanism and policy. The mechanisms specified by X are still going strong, many years later. However, if the X consortium had tried to nail down policy in the '80s, it would have probably been something horrible (cough, CDE, cough), and not stood the test of time. At the same, time, because nobody credible has specified policy, each application has implemented its own. That's obviously bad for usability.

But now we have the possibility of turning the separation of mechanism and policy around: to use multiple different mechanisms (the Gtk+ and Qt toolkits, in particular) to implement one coherent policy. That would be cool.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page