Death via Design by Committee

I’ve always noted this in the past: those designs that are designed by a committee seem to be, more often than not, to be a conglomeration of ideas rather than something revolutionary. Smashing Magazine has an article about design by committee which seems very apt and on-target.

Examples of both design by committee and its contrast abound in the software industry, present and past. Revolutionary items written by one person include:

  • The Apple II. Designed by Steve Wozniak.
  • The Merlin Assembler. Written by Glen Bredon, and became the pre-eminent 6502 assembler.
  • BDS C. A one-man project by Leor Zolman which broke all the rules for compilers and bested them because of it.
  • Puppet. Written by Luke Kanies.
  • Linux. Written (then coordinated and directed) by one man: Linus Torvalds.
  • OpenBSD. Certainly not written by only one person – not even from the beginning – but OpenBSD has always been one man’s dream (and direction): Theo deRaadt.

Likewise, ideas that were designed by committe abound also. I love the quote from Michael Arrington of TechCrunch, from an article he wrote:

And when too many people have product input, you’ve got lots of features but no soul.

Consider these products by committee:

  • COBOL.
  • PL/I.
  • Ada.
  • CORBA.

Rod Johnson, the founder of the Spring Framework for Java, refered to this as the Complexity Industry. He spoke about the development of Java at QCon in December of 2009. Note that the Spring Framework is known for its simplicity.

If you are a Java developer, listen to Rod’s talk in its entirety; it’s wonderful. The talk about design by committee starts at about 27:00.

True revolution is done through the individual, not the committee.

For a more light-hearted look at design by committee, see this video about designing a stop sign…

Error Messages: Who Needs ‘Em?

There was a very interesting post over at Slashdot where a reader asked the gathered populace how to get users to read error messages.

The question, to some, might sound trite or like the standard complaining from technical support staff – and yet, this is a real problem and is wrestled with by technical staff and by usability engineers as well.

There were a number of interesting responses (and thoughts) to this question:

  • Force users to read it. In one case, the support staff put a code within the text of the error message, and required entry of the code to continue. Users who called saying they were stuck were told to read the error message to the support staff – at which time, the user typically said “Oh, never mind…” Alternately, another story told of a site that stopped people cold at an error message, requiring them to call technical support. If they tried to bypass the message with a reboot, the offending application would not work for 15 minutes.
  • Start using error messages appropriately. This requires more work by developers, but the idea is that users are so used to error messages that are meaningless that they ignore them entirely.
  • People will filter out things that are unexpected or don’t fit the model. This is backed up by research (apparently) of fighter pilots who, during a simulation, overwhelmingly blotted out the fact that there were huge items in their path on the runway. In another famous case, people were given something to watch (a conversation I think it was) and no one reported the huge gorilla (yes!) that wandered through the picture.
  • Pictures are more easily noted and remembered. Some suggested using pictures – one or two said they had done this with excellent results.

What do you think about error messages? How do you get users to read them?

Else Mobile Phone: Usability First!

I’ve spoken about usability in the past – and will continue to point out that our phones should not require “getting used to” as many people try to maintain.

I recently exchanged my LG Glimmer for a Samsung Caliber and have been startled at the positive difference in usability. The LG required a lot of memorizing where items were kept and a lot of trial and error to figure out. Taps on the touch screen were also not accurate and icons were commonly mystifying.

Using the Samsung Caliber was a different experience: I understood it after five minutes usage, and the touch pad was accurate from the start. Items worked as expected, and there weren’t any misspelled words either.

Now along comes the First Else from Else Mobile, an Israeli company. This phone has a form factor and style similar to the Caliber but was designed from scratch with a singular focus on the “user experience” – which is usability. The primary interface is basically half of a pie menu, combining this with immediate response. This means that one can select an action with a single thumb stroke.

The First Else is supposed to be out in second quarter of 2010, but we will see. According to Engadget’s article, the phone will only support EDGE and HSDPA. It is also running a Linux platform known as Access Linux Platform (or ALP).

5 Ways to Increase Desktop Usability (and Productivity)

Usability is the study of how you interact with your computer – and how to make the computer work easily and simply, the way you want it to. You can increase the usability of your own desktop yourself, even without modifying code or otherwise feeling “stuck” with what the software designers give you.

Here are some simple ways to increase usability (and thus productivity!):

  1. Color terminal windows. This was mentioned yesterday, but it bears repeating for a general reason: with different color backgrounds, you can see at an instant which window you are on and where the window is that you want.
  2. Cascade windows that go together. For example, when using multiple screen sessions, if you cascade them – that is, overlap them so that the top and left sides are visible – then it becomes easy to pick one at random. The windows can then be large as possible but still reachable at an instant. For best usability, make sure that there is a good amount of window visible when it is fully covered by other windows (I figure about 1 inch – 2.54 cm). This makes it possible to hit the window with the mouse very easily, and acknowledges Fitts’s Law.
  3. Maximize windows when possible. This helps you focus on the current topic, and allows you to make use of the “infinitely large” window edges. If you are using Synergy, make sure to turn on the “lock to current screen” capability to make best use of this.
  4. Use full screen viewing when possible. This is most often relevant to browsers (use F11) but is also true for PDF readers and terminal sessions. Unfortunately, most readers will default to “full page” viewing in full screen mode; some won’t let you change it. As far as terminal sessions go, if you are using only one, it will be most useful in full screen mode.
  5. Use multiple desktops. This will allow you to move irrelevant windows outside your focus, and will permit you to switch to them with ease. For Windows, I use Dexpot; Linux comes with pagers built into KDE and Gnome and probably everything else. Dexpot has a very interesting feature that you can use to further increase usability: you can hide windows you almost never use to the system tray.

If you do these things, you’ll find that your productivity will go up and errors will go down – and your time with the computer will be much more stress-free.

Multiple Screens: A Usability Nightmare?

I’m surprised I haven’t seen anything about this anywhere else. When multiple screens are connected together, you lose one (or two) of the most important features of a single window: the right and left edges. As Bruce Tognazzini mentions in his timeless article on Fitts’ Law, the edges are very fast for user access. This is one reason that Apple’s menu bar (across the top) is so much better than the way Sun and Microsoft and others have done it: see point 5 in Tog’s article.

There is also an absolutely wonderful writeup of Fitt’s Law by Kevin Hale titled Visualizing Fitts’ Law – with a presentation with excellent visualizations and examples. Jensen Harris also wrote an article on Fitts’ Law: of particular note are the examples of how Fitts’ Law affected the design of Microsoft Windows and Microsoft Office.

In Tog’s article on Fitts’ Law, he describes how he experimented with “multiple desktops” (though at the time, it may have seemed more arbitrary than that). With a second monitor on top of the first, and a menu that users could “bypass” into the top monitor, it actually slowed the user down quite considerably: at first, the menu was missed quite often until the user slowed way down to get at the menu.

When using multiple monitors in a horizontal direction (a typical layout) the right edge of the left screen and the left edge of the right screen become very hard to hit. This especially becomes a problem with programs that are maximized. Consider the example of a typical scrollbar (normally on the right hand side) on a maximized application on one of the two monitors. On the left-side monitor, it becomes a hard target as the user has to directly aim and slow down to hit it. If on the right-side monitor, the scroll bar essentially becomes infinitely large and can be hit without any trouble at all.

Using multiple monitors also completely eradicates two of the five easiest locations to reach: two corners are no longer easily “reachable” – or perhaps reachable at all. This easy reachability of the corner is perhaps one reason that programs put the window control buttons in the top right corner; with another monitor on the right the corner becomes that much harder to hit. If there is a monitor above, then it becomes just that much harder.

When using multiple monitors on on system tied together, the possibilities of rectifying this usability problem is only available to the extent that the operating system allows it. However, if you use synergy to tie multiple computer displays together, there is at least, several ways to regain the “infinitely large” target of a screen edge.

One is to use the “lockCursorToScreen” capability of Synergy. Synergy uses the ScrollLock key to do this by default. You can also use a hot key – this display is from the Synergy+ server for Windows:

Hot Key Configuration Window
Hot Key Configuration Window

Hot Keys are set at startup, accessable via the Hot Keys button. With a mouse and window “locked” with this option, you get back your right and left edges, and they once again behave the way operating system designers expected. With the toggle, you can go back and forth. There is, however, no way to discern whether the screen is locked or not, aside from the fact that the ScrollLock key setting is often visible on the keyboard: this is a usability failing in this feature.

Using the “double-tap” or “time delay” features of Synergy (with respect to switching displays) turns out to be extremely frustrating for the user, switching at times that are unexpected and not switching when desired.

Another possibility would be to not link the multiple displays together at all, and use key commands to switch between screens. This, however, may be more trouble than it is worth; I’ve not tried it and it does not seem possible to configure Synergy+ this way from the configuration screens.

User Interface Design: the Command Line

The command line is not immune from user interface design. Especially with the concept of language, one has to choose carefully the options and names and orders of the things in order to make things work just the way the user expects them to.

If the program is too different, people will be tripping over it all the time. The UNIX tar command comes to mind as one that failed here: options (or “actions”) specifically did not start with a dash. Likewise, UNIX find also failed: if you didn’t include the parameter -print at the end, you saw no output: your find command found nothing! (In reality, it just didn’t report it.) Both of these errors have been rectified in the last several decades: UNIX find has an implied -print, and tar often will make the dash optional – which makes it work both the way it always did and the way it should have.

As an example of what seems to be a colossal user interface failure – including poor writing – consider these articles from Scott Remnant which are absolutely a gem (albeit from way back in February 2009). He wrote an article titled Git Sucks – which was then followed by a second and then a third – followed by yet another titled Revision Control Systems Suck.

What Scott is railing about is how hard these systems are to learn (he targets not just git, but also GNU Arch and Bazaar). From his standpoint, he finds these systems to be complicated and hard to understand.

He also points out (rightly) that the most common actions should be the simplest, and finds that with git these common actions are rarely ever simple. He specifically mentions reviewing the changes that someone else has made compared to his own – and says that there’s not a revision control system that makes it easy.

An example of how user interface design can be incorporated into things like the command line and even programming is this quote from an interview with Yukihiro Matsumoto, the developer of the programming language Ruby about his guiding principle in developing Ruby:

[It’s] called the “principle of least surprise.” I believe people want to express themselves when they program. They don’t want to fight with the language. Programming languages must feel natural to programmers.

and later in the same interview:

In addition, Ruby is designed to be human-oriented. It reduces the burden of programming. It tries to push jobs back to machines. You can accomplish more tasks with less work, in smaller yet readable code.

Another example: I was just rereading my copy of The Humane Interface written by Jef Raskin. In it, he had a section titled Noun-Verb versus Verb-Noun Constructions (section 3-3, p. 59). This mirrors a problem I have experienced with some command line software in the past: the command wants an action as the first argument, and the object of the action second. I despised it enough that it was the genesis of my writing a wrapper for the command that reversed the order: object first, action second. Imagine my surprise to find my troubles validated right there in Raskin’s book.

There are many examples of command line programs doing wrong things, and of programs doing right things. One of the right things comes from HP-UX and its software management tools such as swinstall: if the program can use an X display for a graphical display, it will: but if not, it goes to a text display instead.

There are many such examples, of programs just doing what you need and leaving you to think about other things. I wonder what would happen if a company like Apple decided to tackle the command line – although, in a way, they did already. In MacOS X, consider the open command for instance… absolutely brilliant, which is in contrast to the open command sometimes found in other UNIXes (never standard).

One very important point to remember: “It’s only hard until you learn it” is not a valid excuse. The learning curve for a program should not be any steeper than it has to be.

Quality User Interfaces: Only for the Young and Very Old?

I was reading up on the Jitterbug – a phone that was designed to be easy to use. I thought that here, finally, was a product that took user interface design seriously – but imagine my surprise as I found myself getting angrier and angrier as I read more about this product.

What is there to get upset about? Just this: the product sales talk suggests that a quality user interface and ease of use is only for those who aren’t “able” to handle the more complex (and harder to use) interface of today’s typical mobile phone.

This plays to a common misconception among users and the public at large: if something is “hard to use” it is because you haven’t yet taken the time to learn how to use it. When I’ve complained about poor user interfaces in the past, I’ve been told it’s easy once you learn how.

The CMO Council (the CMO is the Chief Marketing Officer) and the Forum to Advance the Mobile Experience (FAME) teamed up in 2007 to survey mobile phone users around the world. The survey is the Global Mobile Mindset Audit and has some interesting bits of information. One particular tidbit was noted in the headline in the USA Today article Cellphone Users Complain about “Function Fatigue”: too many functions on the phone that will never get used. This was also noted in the article A Phone without Frills written December 7, 2007, for SignOnSanDeigo about the Jitterbug.

To quote from the Global Mobile Mindset Audit survey:

The industry’s preoccupation with one-upmanship on features and functions does little to improve the elegance and appeal of products. The number one problem voice by users in every region was “too many functions I did not use.”

Other problems included the fact that typical phones are difficult to use – quoting again:

[…] other reported problems [included] user manuals not being very good, devices being hard to configure or customize, and simple product requirements, like volume control, being deficit.

The article from the April 6, 2006, Fortune (discussing the introduction of the Jitterbug and other devices at the 2006 CTIA Wireless conference) by Peter Lewis titled Cellphones for Kids – and Seniors shows the previaling thoughts when he writes:

Jitterbug, also launching later this year, consists of a simplified mobile phone and service designed especially for baby boomers and their parents.

Peter later refers to the “technology-phobic baby boomers.” I wonder what Tom Peters would say about that?

One of my most favorite commercials is the Apple “Manual Ad” – in this collection of old Apple ads, it starts at 2:30. It presents an IBM PC – then its manuals. Then it presents an Apple Macintosh – and its manuals. The contrast is striking.

What is it about the mobile phone industry that it just will not listen to its users and give them something easy to use? That’s why the iPhone is so popular: it comes from a company that shows time and time again that it listens to its users and designs its user interface for usability. As soon as I can use an iPhone on my choice of carriers – a carrier known for customer service and for blanket mobile phone coverage in the Midwestern United States – I’ll look at the iPhone. Until then, I’ll stick with the iPod Touch – if ever I get one.