User interfaces should teach, not hide

User interfaces should teach, not hide


Today, I finally decided that my gVim editor needed a smaller font, and the process of getting it to work right has made me notice a fundamental flaw in the way we think about user interfaces. It’s not an innovation that you’ll get on the proprietary side of the line, because it’s an innovation required for the digital middle class of ‘user-developers’ that I mentioned last week.

Essentially it’s just this: GUIs should teach, not obfuscate or hide the underlying mechanism.

What I did, of course, was go straight to gVim’s snazzy GUI Edit menu and select Select Font.... This leads to a GUI menu which allows me to choose any one of my installed fonts, and I really do have a lot of them! Furthermore, I get a nice preview of the font I’m going to choose, and I can easily try it out. Clicky, clicky,... GUIs are fantastically efficient ways to work!

If you pay attention to the status bar in gVim when doing this, you’ll notice it says :set guifont=*. Now that’s kind of cool, because it tells me what I’d have to type to change the font using the command interface in gVim, which is basically a CLI and scripting interface. That’s important, because later on, I’m going to want to stick these commands in my startup file for gVim so that I can do this everytime.

However, this is unnecessarily hard to do, and I want to explore why that is.

Behind the curtain

Something that did not happen, which would’ve been really nice, is that when I did pick a font, the status bar did not show me what I would’ve needed to type to get the same effect from the command line (or from a script).

What a waste of an opportunity!

But it made me think about why this opportunity gets missed, and it has to do with the unfortunate myth of class division promulgated upon us by the same professional programmer mystique that I mentioned last week. The myth says there are two classes of people: “users” and “developers”.

“Users”, are a much maligned class of people. Developers have little respect for them, and regard pleasing them as an unfortunate consequence of getting your software used. They’re just so demanding. What’s more, they can’t be bothered to learn obvious CLI command names and hotkeys. They just won’t read the manual.

“Developers”, on the other hand are smart people like me, who know how to do things the “right” way by relying on commands and the manuals that define them. They don’t mind taking the time, and they know their way around.

I hope it’s pretty clear that this division is entirely off base when it comes to users of a programmer’s editor like Vim! But the truth is, it’s pretty much true everywhere—or at least it should be. Because we in the free software world don’t want a division between users and developers. We need that middle class, because free software is driven more than anything else by people fixing their own problems.

Yet, we’re still thinking like professional proprietary programmers, trying to defend our turf from the riff-raff.

The conventional wisdom is that GUIs should hide as much information as possible, to keep from confusing the user. But that process makes switching from “user” to “developer” mode harder, and that works against our community goals just as much as hiding your source code. Because, essentially, that’s what the GUI is doing: hiding the source code.

That downright discourages tinkering and customization.

Most free software GUI applications are actually front-ends for CLI applications. GVim’s GUI is (I imagine) just passing commands through the standard Vim CLI to get its work done. Something just like that happens when you use KDE’s ‘Control Center’ or run an X-based CD-R burner application.

The developers of these front ends see their jobs as “making things easier for end users”, but they are not helping the “end users” to become anything more than ”end users”.

Ironically, many old time GNU/Linux users feel threatened by all these GUI-based users and cling to CLI interfaces. A peculiar idea of CLI use as a critical rite of passage emerges, and a rift grows between the “new” GUI users, and the “old” CLI users. In the name of modernizing and simplifying our systems to make them “more usable”, we’re making them “less hackable”. Essentially we’re copying the proprietary models of Windows and Apple too closely.

This isn’t so obvious to the old guard, because they still have their familiar, hackable, CLI and scripting interfaces to play with. But they may by now have noticed the absence of new blood to their communities. What’s missing is the open bridge that invites “users” to become “developers”, by simply allowing them to see behind the curtain.

Teaching, not hiding

The key concept here is that we should view GUIs not as an opaque layer to separate the digital classes, but as a convenience to make learning easier.

In my gVim example, this doesn’t work so well because neither the status line nor the GUI font selector tells me what the correct name for the font I’ve chosen is. The command that is displayed, :set guifont=*, is a useful hint (it tells me what command to look up, but it doesn’t tell me the right arguments to use, the * only brings up the GUI menu (not something I’d want to do from my start-up script!).

Browsing the manual, I do, of course find documentation. However, it’s short on examples, and the font names are different, depending on whether the program is running in Windows, GTK, or Motif window managers. I do happen to know that I’m running in GTK—but is that really knowledge that should be assumed? The program itself obviously ‘knows’ which version it is running under, so it would make more sense for it to figure this stuff out and then tell me what font names it means. The mapping from the names in the menu I get is not necessarily intuitive.

For example, suppose I selected “Sazanami Mincho”, the style “Mincho-Regular” (there’s only one to choose from on my system), and fontsize “8” points. That all makes sense, of course, but how am I supposed to know that this should appear on the command line as:

:set guifont=SazanamiMincho\ 8

and not, say, like this:

:set guifont=Sazanami\ Mincho\ 8

or even

:set guifont=-shinonome-mincho-medium-i-normal--0-0-75-75-c-0-jisx0208.1990-0

?

The last one may seem a little odd, but not when you consider that the Vim manual suggests using xlsfonts to find font names, and this is the nearest “mincho” font I can figure out to the one I chose.

You might note that this is an unusual font, but frankly, getting “Bitstream Vera Sans Mono, 8pt” to work is even harder (is that “BitstreamVera”, “Bitstream Vera”, “bitstream-vera”, or just “Bitstream”; is “Vera” a ‘fontname’ or an ‘option’?).

This sort of confusion is exactly what makes GUIs so useful, because it sorts all that out for you, and lets you visually choose which font makes sense instead of forcing you to play guessing games with a long feedback loop.

However, the time gVim saved me in picking my favorite font, it then proceeded to steal back from me, by not providing any way for me to extract that internal information so that I can use it in my start-up script. I’ve experienced “User Ghetto Lock-In”!

It’s not gVim’s fault

Somebody’s going to complain that I’m picking on gVim—but I’m not. I ran into this problem with gVim precisely because it’s my favorite editor, and I’m not planning on switching anytime soon. Also, gVim is just following the norm here. I could’ve run into this problem in any of a dozen different applications.

In particular, I realize that this conflict is the one thing I really don’t like about KDE, compared to my old favorite window manager, which was FVWM. FVWM was a pain to customize, because everything had to be done in scripts. You had to find obscure documentation to figure out how to design on-screen launcher bars and stuff that we take for granted in KDE and Gnome. In order to see the results of your changes, you had to log out and log back in again.

But because there was no other way to do the job, and because you had to know where the scripts were to create them, you obviously wound up knowing where your customizations were when you were done with them. You could easily back them up with your other user files, and it was easy to reload them onto a new computer, or recover them from backup after a hard drive crash. They were yours, not something the program hid away from your prying eyes.

With KDE, of course, all these customization are massively easier, and I routinely set things up, that would’ve been a nightmare with FVWM. But at the same time, I’ve lost control. I don’t know where KDE is storing all that information. The GUI itself certainly doesn’t show me, and while I don’t doubt that the answer is buried somewhere in the KDE documentation, it certainly is not easy to find. And if I have to dig through KDE documentation just as I had to dig through FVWM’s documentation, then what has the GUI really gained me?

Some old-timers are quick to shout “Nothing! That’s why you shouldn’t use those new-fangled point-and-grunt interfaces!” Well, that’s silly, actually, because there’s nothing about the GUI concept itself that insists on this kind of secrecy. It’s just a habit that free software GUI designers have inadvertently copied from proprietary designers.

Show me the magic!

Obviously, I’ve ranted for a bit here, but the insight is simple: GUIs for free software, in order to appeal to the same ideals that make free software possible, should provide some kind of transparency. It should be possible for the end user to capture the messages going from GUI front-end to CLI back-end, or to see the configuration files that that fancy GUI configurator is writing. At least tell us where you’re writing all that mysterious information, so we can go diving for it afterwards.

If you do this, then you’ll be inviting end-users to become more involved, and healing the gap between “user” and “developer”. You’ll be providing a much needed incentive and educational help. You’ll also be giving end-users that feeling of greater control over their system which is one of the main draws to free software operating systems.

We can learn what’s good from proprietary GUIs without copying all the bad habits or turning our backs on the ideals inherent in good, open design.

License

Copyright (C)2006 Terry Hancock / CC-By-SA 2.5+. Originally published at www.FreeSoftwareMagazine.com..

Category: 

Comments

Scott Carpenter's picture

In my tentative experiments with GNU/Linux over the years, I've always felt like I needed to master the CLI first, and I think this is one of the reasons I've been slow in making progress. It seems overwhelming and easier to put off for tomorrow. The way I learned Windows was to have this GUI that does most of the work for me and then gradually learn what goes on underneath. I think people want to be able to do things right away. Today. I want my MTV and my instant gratification. I do software development for my job both in Windows and on Unix/Linux servers and I muddle around with command line programs, but it's more natural for me to start from the ease and safety of a GUI.

But even though I like the GUI, I do want that command line interface underneath. And what you suggest sounds like a good idea -- that the GUI should be better designed to help me learn the underlying complexities.

However, while that might work for me, a kind of user-developer hybrid, and while I don't want to keep people in the ghetto, I just can't imagine most people wanting to learn this stuff. So it becomes a question of how do you make a useable program without overwhelming the person who just doesn't have an inclination to understand the nuts and bolts?

(As a vague side note slash tangent, I also think we should reject the often-made comparison with the car, that computers are like cars in that people used to know more about them and now they don't and they don't need to. I believe that is mostly true for cars. I don't need to know the details of how my car works. It's a specialized device that really only does one thing: move stuff from one place to another. Computers of course are so much more, and knowing more about them will enable people do a lot more, to their great benefit. When you start closing down options to make things easier for the user, you're preventing them from doing as many things, where if I don't understand how my internal combustion engine works, I can still get from point A to B.)

----
Scott C.
http://www.movingtofreedom.org/

Terry Hancock's picture

"However, while that might work for me, a kind of user-developer hybrid, and while I don't want to keep people in the ghetto, I just can't imagine most people wanting to learn this stuff. So it becomes a question of how do you make a useable program without overwhelming the person who just doesn't have an inclination to understand the nuts and bolts?"

Here's an example I just thought of: what about the "Javascript Console" in Mozilla? You can launch this little window, and it will display the output from the Javascript in a webpage as you load it.

Why not have a GUI console that shows the messages as they go by for a front-end program? Or why not include the locations of key configuration files in the documentation accessible from the "Help" menu available in most GUI applications?

I think there are a lot of different ways to make this information accessible without having to break stuff or make it difficult to use for pure GUI users. Most of these things would probably make the programs easier to debug and test, too.

Scott Carpenter's picture

Absolutely. Consoles and accessible logs are good things. Anything that lets you dig when you're ready and interested.

(That's one of the frustrating things to me about Windows -- that you often have a hard time finding out what is going on. The contrast between Windows and Unix is striking to me. It seems like Windows and most Windows applications are stuck in binary. You can't grep through and examine flat files. It all has to be in some incomprehensible undocumented format, and when the tools provided fail you... good luck. I think this is why the prescription for a problem is so often to reinstall software on Windows. Whereas on the *nix servers, there are all kinds of tools you can use and most things are documented and accessible. Things are modular and you don't have the monstrosity of the Windows registry.)

It would be good to have these consoles or other helpers, but I think there's the old challenge -- what's the incentive for free software volunteers to provide this functionality when it takes additional time and doesn't especially benefit them personally?

----
Scott C.
http://www.movingtofreedom.org/

Terry Hancock's picture

"That's one of the frustrating things to me about Windows -- that you often have a
hard time finding out what is going on."

I mostly quit using Windows about when Win 3.1 was going out of style (that'd be 2000, for me ;-) ), and I knew my way around the WIN.INI and SYSTEM.INI files. But then they got sneaky and started doing everything through this new "registry" thing. One of many reasons I bailed out at that point.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

DOS works, but you can't expect all people to learn DOS commands. I can work in DOS, but would also like to have the opportunity to learn *nix commands---even if I have a prompter to assist my learning curve.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I remember that on HP-UX, the configuration application (a GUI) did it like this: each command that was applied was logged and if you were curious about which modification was made under the hood, you could just read the log (from the application itself, no need to search for the log file).

I remember being pissed at Mandrake whose GUI application to update the rpm was just a shell over a command, but this wasn't written in the 'About' section so I didn't know this and lost quite a lot of time over this crashing GUI whereas the command line conterpart was more useful.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

All you have to do is set the font you want on a blank page, then save the session using the icon and a memorable name. When you start gvim load the session and voila. This way you can change settings to suit different documents, codings, etc. And all through the GUI.

I imagine that having access to the source, you could add your other needed features even using something as rudimentary as an xdialog window listening to your application output. You could add a command line option to switch it on.

If you need a fully featured fast prototyping IDE, try Runtime Revolution for Linux for an easy scripting based method which also allows one to access shell commands. Once you have the runtime prototype tested and approved you can use an Open Source IDE to finalise the project.

I like Linux because you can put your ideas into practice and then share them with the rest of the community.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

if one looks in `kde-config --prefix`/share/config.kcfg you'll find a bunch of xml files that describe various settings. the names of the files are generally the name of the apps. you can find all sorts of cute things in there.

that said, it is quite true that most cli frontends hide everything about those backends. which is unfortunate for power users. and of course it's not just cli frontends, it's network apps as well. i absolutely how kontact and the various kde pim apps have a little arrow in the status bar which, when clicked, pops up a nice widget saying what it is doing on the network, one entry per activity.

amarok does similar things as well... for those who couldn't care less these notifications are simply "not there" but for those who want or need (think: troubleshooting) to get to that info it's pretty darn useful.

Terry Hancock's picture

Yeah, I know where KDE puts its config files, but have you looked under .kde?

It's "a maze of twisty passages, all alike", as they say.

I'm sure it's possible to find your way around after a great deal of searching, but it shouldn't be that hard. Obviously every component in KDE knows where it needs to look to find its config files. The person writing the GUI must have access to that knowledge all during the process of designing the GUI.

So the idea is simply to share that info with the end user. You shouldn't have to know it, to use the GUI, but there should be an easy way for a non-programmer end user to come across it. Why a "non-programmer"? Because the whole point is that this is how we get people to want to become programmers!

Anyway, that needs to be something in the GUI.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

It would be nice to have a printerfriendly option for those of us who have trouble reading large amounts from a screen.

Henry Keultjes

Tony Mobily's picture

Hello,

It's in the web site's todo list. We will add it as soon as we can!

Merc.
(Admin)

Robert Romberger's picture

Sometimes the information you seek is there, you just don't know where to look for it. In the case of gvim, you need to be able to go to command mode - press the esc key, then type :set and enter. You will then see the guifont setting with all of the proper modifiers. Once you have that info, just open up another gvim instance and edit your .vimrc (for MS Windows _vimrc) and then, on a blank line, type in "set guifont=..." (example: sets my guifont to DejaVu Sans Mono type with a size of 10 - "set guifont=DejaVu_Sans_Mono:h10:cANSI"). Save the file and exit all of the gvim windows, then restart gvim to show that you have set the guifont to what you wanted.

While you picked on gvim, as well as KDE, sort of, I don't think many users understand that most of the FOSS packages use plain text configuration files. For the most part, changes to the configuration are saved in the program's config file whether or not the change was made using a gui or the cli - gvim doesn't save the guifont setting automatically in MS Windows, you have to edit the config file to put it in for subsequent use. Because the configuration file is plain text, you can add, change, remove, etc. settings to make the program work exactly like you want it to. The secret "developer knowledge" is knowing where to look for the configuration file and what the syntax is to make proper changes. That is where good documentation and/or internal help is necessary.

Terry Hancock's picture

Thanks for the tip! I didn't think of trying that, though it makes sense (works the same way as environment variables in most shells).

"While you picked on gvim, as well as KDE, sort of,"

Please understand that I only "picked on" those because they were ready examples. I can think of few applications that work like I'm suggesting.

Even FVWM doesn't do it right, because it doesn't provide the GUI in the first place.

The point is that KDE eliminated the necessity of editing the config files directly, making it easier for an end user to change configuration without having to acquire expert knowledge. But since that eliminated the need for end users to understand the config files, it caused two distancing processes: one, the priority for documenting the config files was greatly reduced; and two, there was no longer any obligation to keep their design simple (since only 'experts' would have to mess with them).

It's better than just having scripts (otherwise, I'd still be using FVWM, wouldn't I?), but it's not as good as it could be, nor is it doing exactly what we want from free software, IMHO.

I think that free software GUI design is mostly derivative of proprietary GUI design. Everybody says "Windows is easy to use" so we copy it. But I think we copied a little too much -- the values, as well as the engineering.

It's just one idea, but it makes me think that we should re-examine some of our ideas about how GUIs should work. While people are currently thinking about things like "better 3D eye candy", I think maybe ideas like this should be in the mix, too.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

This "revelation" feature is a great idea but it will only be useful if it works consistently across applications. I would suggest a "Session Log..." entry under the "Help" menu, right before "About..." - of course, there may be a more intuitive name than "Session Log" :-)

Terry Hancock's picture

That makes sense. Maybe "Command Log" or just "Log" would be reasonable, but "Session Log" makes sense to me, too.

Of course, not every GUI app is a front-end with a CLI backend, so you can't always have that. Sometimes, there's just a configuration state stored in a file, and you have something more like a DOM, where it's easier to keep track of the state than of the changes.

Inkscape, for example, has a tool for editing the XML content of the SVG file you're working on, which is pretty impressive (of course that's the document, not Inkscape's config file).

An even lighter-weight solution is to just include the location of the config files in some item under "Help". Say "hacking" or "scripting" or just "config". Or it could be in the text on the Preferences menu (usually under "edit"), since that's where you change the configuration with the GUI.

Anyway, it'd have to be a GUI guideline, and it would take time for it to get around, no matter what approach was taken.

Author information

Terry Hancock's picture

Biography

Terry Hancock is co-owner and technical officer of Anansi Spaceworks. Currently he is working on a free-culture animated series project about space development, called Lunatics as well helping out with the Morevna Project.