Chad Perrin: SOB

7 January 2010

There are 10 Types of End Users . . .

Filed under: Geek — apotheon @ 12:46

I love that old joke.

There are 10 types of people in the world: those who understand binary, and those who don’t.

In this case, the two types of people in the world I want to address are types of software end users. The type of software I’ll use as my example is audio media players.

Many many moons ago when the world was young and dinosaurs roamed they Earth — say, six or seven years ago — I started using a media player called mpd. Those letters stand for “music player daemon”, and it runs as a server process in the background managing the playing of music from its playlists for you. You would use it by connecting to the daemon process with a player client, which is an excellent idea for an audio media player architecture. My favorite client for mpd was mpc, the “music player client” and the generic client that went along with mpd.

I loved the concept behind the mpc interface; it was a true command line tool, with no captive interface, that served no purpose other than to be used to send commands to mpd to tell it to change what it is doing or to get information from it and dump it to STDOUT — i.e., the screen. It didn’t take over an entire terminal emulator or TTY console or SSH session or whatever with some ugly ncurses captive interface, it didn’t clutter up my X session with yet another ugly GUI collection of buttons, it was fast and responsive, and once I got used to it the thing was very quick and easy to use. That is to say that mpc was easy to use. I’m not talking about mpd here.

The downside was mpd itself, which primarily had two problems:

  1. The mpd back end required management. One couldn’t just point it at a directory and tell it “Okay, run now,” or something equally simple. Instead, one had to play silly buggers making it do what it needed to do. Databases had to be rebuilt every time I changed something. Baroque sequences of actions had to be taken to make it do what needed doing, because doing things in a different order or forgetting a step in what should only be a one-step task would result in things not working out.

  2. The mpd back end was a little brittle. The database broke a couple of times, kinda like Subversion’s database back when it was using bdb by default and bdb was brittle.

The first part might not have been a problem in the long run if I was running a heavily used music server for a household of half a dozen people and spent a lot of time working with it. I would have combined oft-used sequences of actions into scripts or aliases, I would have automated database rebuilds, and I would have better remembered what to do to get certain things done if I did them all the time. I didn’t, though. Sometimes, I wouldn’t touch my mpd+mpc setup for a while, and I would forget half of what I knew about how to use it. Before long, I was tired of it, and sought out other alternatives. I still do not use an audio media player application often and regularly enough to bother with that sort of thing.

There’s just no excuse for the second problem. Luckily, Subversion corrected its problem rather quickly, and bdb subsequently corrected its own problem, so that both Subversion and bdb are now solid as a rock. I suppose mpd might have similarly changed for greater stability, and if so, great — but I’m unlikely to go back to it, both because of the first problem I mentioned and because it uses copyleft licensing (which may or may not matter at all to you, but does matter to me).

Ultimately, I ended up going with herrie instead. I don’t actually like the herrie interface quite as much as mpc’s, at least in concept, but it’s still a good one in practice. It is really a combination of factors that appeal to me:

  1. It isn’t an X application with a clicky-button GUI.

  2. It is a lightweight program.

  3. It’s copyfree licensed.

  4. It uses vi-like keyboard controls.

  5. It’s simple and stable, with no “management”, rebuilding, or recovery needed if you don’t want to deal with it.

There are some bad points about it, too:

  1. It uses a captive interface (ncurses).

  2. Its media file type support is pretty limited.

Thinking about this earlier today, I came to the conclusion that when designing interfaces for software that you hope will be widely used, there are really at least two broad classes of users you need to address. You should make the following two assumptions about who might use your software when designing the interface, unless you have some truly compelling reason to do otherwise (and no example of such a thing comes to mind):

  1. There are people who only occasionally use the software.

    For these people, your interface needs to be simple enough that people can rediscover its capabilities quickly and easily. Documentation can help with this — very simple, clear documentation, preferably with examples if there is any complexity to the interface to speak of at all. Documentation alone is not the answer, however, because the actual interface itself has to have enough simplicity that a general understanding of common conventions for similar pieces of software should make the general case for usage incredibly obvious.

    For software that requires some complexity in the interface, such a philosophy of design simplicity should rely on a conventional assumption of the simplest use case, and only impose complexity when the task itself gets more complex. In general, a command line interface should not get any more complex for the most common and simple task than to take the form program_name command target. It would be preferable to take the even simpler form program_name target, and best of all would be for the thing to do something useful with just program_name. If that last option is not really a reasonable way to make your program do something useful, having it print out very simple usage information, with an extremely clear indication of how to get more help information without resorting to a manpage (such as a --help option) included.

    That reminds me of another thing — help information. Provide it. Do so in the simplest and most conventional way you reasonably can. For a typical Unix command line program, that means offering help information for both -h and --help options fed to it as arguments. If either of these help arguments is given to your command line tool, it damned well should give me some help information. In addition, by the time you call any Unix program a 1.0 release, it should have a manpage that at minimum provides more information about each specific option than your --help option output.

    The key need behind this requirement for good help information and a “discoverable interface” is to ensure that people who only use the program occasionally don’t get frustrated with the fact they can never remember how to do anything and choose some other piece of software instead — perhaps something that, in principle, does not suit their needs as well, but in practice is actually usable for them without a lot of annoyance and frustration.

    I’m an occasional user, because long periods pass during which I do not actually have any particular use for an audio media player on any of my computers. I still use my CD player at home when I want to listen to use, and the CD player or radio in the car. I don’t really do anything that prompts me to carry around an iPod or other digital music player device of that ilk, for that matter. When I need an audio media player on a computer, it’s because I’m in some coffee shop working with my laptop and I want to shut out the noise around me (sometimes including the terrible music some coffee shops play). This does not actually happen that often.

    The herrie application serves my needs as an occasional user because it is reasonably simple. It also has a fairly well-organized manpage. It does not conform to the requirement that it provide useful --help or -h output, except that because it does not recognize the command line argument it will at least print out some bare-bones usage information. The biggest win for me, though, is that it uses vi-like commands. If you cannot get discoverability by being extremely simple, you can at least get it by appealing to a specific subset of potential users who also typically use another, more popular piece of software, and make sure it behaves like that other piece of software. A lot of applications do this, emulating either vi or emacs, some of them more successfully than others. Luckily for me, herrie does a decent job for my purposes of acting like vi. Coupled with the manpage, it’s enough, at least for me.

  2. There are power users.

    Power users are the people who will use and abuse the software regularly, even constantly. They will push the software to its limits, and they will demand a piece of software whose efficiency of use they can improve over time for purposes of their own workflows. For these purposes, capabilities like macros, command line filter behavior (so it can be chained to other operations with pipes and redirects), and other ways to automate, simplify, abstract, combine, and generally do interesting and powerful things with the program’s functionality are important.

    An interface that requires too many actions to complete common tasks — such as going three menus deep to open a dialog within which one must switch tabs and click a button to get the configuration dialog one needs — can become something of an obstacle to the smooth and comfortable use of the application for a power user. For such users, one should provide either a quick and easy way to simplify and automate the process of completing pretty much any task or an efficient enough default interface that simplification and automation of tasks is not particularly needed. By preference, both would be nice, as long as some other important characteristic of the software is not sacrificed to get them both.

    A command line tool that can be used like a standard Unix filter utility, or feed data to such a filter utility, is a great way to provide the kind of flexibility and scriptability that makes “power users” happy. Even without filterable output and/or filter-style operation, command line tools can at least be aliased and potentially included in simple shell scripts to abstract away the details of complex tasks.

    When I’m not going for long stretches without using an audio media player, I tend to verge on being one of those power user types. This is pretty much true of every single application I use, though not always because I use the heck out of the application’s capabilities. Rather, I leverage the power of my Unix operating environment in general to improve my efficiency and productivity so that I can multitask pretty effectively and get a heck of a lot done in a fairly short period of time when I need to. For that reason alone, if for no other, I feel a need for tools that allow me to very quickly and easily accomplish whatever task I want to accomplish, with a minimum of fuss, thus giving me a need for “power user” features.

    Unfortunately herrie, as a captive interface media player, does not offer the ideal CLI filter utility capabilities to which I referred above, nor even the basic, non-captive interface CLI operation of mpc. It does, however, provide an efficient enough interface for me that almost any functionality of the application is only a couple of keystrokes away. Since I’m only sorta a power user when it comes to my audio media player, only needing it to give me efficiency within the larger context of the whole Unix operating environment, that’s good enough for me. That does not (of course) address the needs of an actual media player “power user”, so herrie actually falls short of being entirely well designed in this regard.

The upshot is that these two types of end users should be foremost in the mind of any application interface designer. Even for me, herrie falls just slightly shy of “good enough” on the combination of “discoverable” and “powerful” scores — though since I do not make enough use of an audio media player to care that much, it is acceptable for now. Given that it is for my purposes still better than anything else I have tried out, it’ll have to do, even though it doesn’t play FLAC files.

I wonder if I can change a compile option to get FLAC support. . . .

(edit: Nope.)

4 Comments

  1. No FLAC support makes it an automatic loser for me since my entire music collection is in FLAC currently. Also, I found mplayer to be decent enough for my purposes, as well as XMMS when it was still being developed.

    The most “power use” I’ve ever gotten out of any media player is two crontab entries to start and stop my music (ala alarm clock).

    Comment by Joseph A Nagy Jr — 7 January 2010 @ 02:46

  2. While I am no such power user for the audio matters I can understand you. Maybe now is a good time to take a look at xmms2. Even that, simple things like rhythmbox may do the trick if your needs are so simple.

    Comment by paurullan — 7 January 2010 @ 03:07

  3. For something more complicated than a music player there will likely be some users in between “power” and “occasional”. The problem of how to make the interface relatively discoverable without overwhelming the occasional user with options is a tough one.

    Comment by Luke — 9 January 2010 @ 02:05

  4. I tend to agree, for occasional use, a GUI is a sin I can live with. Though I do like the power of the command line interface (if a program takes advantage of it properly).

    Comment by Joseph A Nagy Jr — 9 January 2010 @ 03:11

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License