Eitan Suez's Blog

Humane Interfaces: Setting the Record Straight

Every so often I go and read the wisdom of elharo over at cafeaulait.org.

So today I came across this specific entry discussing "humane" interfaces:

http://www.cafeaulait.org/oldnews/news2005December7.html

Here is a snippet from elharo's blog entry:

"More buttons/methods does not make an object more powerful or more humane, quite the opposite in fact. Simplicity is a virtue. Smaller is better."

Hearing stuff like this makes my blood boil. I am a disciple of Jef Raskin (z"l), the person who designed the first Macintosh, the author of the book "The Humane Interface" (THI).

My goal in this entry is very simple: to prevent the perversion of the meaning of the word "Humane", to set the record straight.

I read Raskin's THI a number of years ago, and don't have it in front of me at the moment.

The claim made by elharo is simple:

that an apple iPod user interface, or the imac's new remote control, with its 4-5 buttons is better or superior to the 100-button remotes from hp and gateway.

That's absolute nonsense.

The 100-button remotes are infinitely better. The ipod has serious usability issues. The problem was easily illustrated to me one day when I tried to teach my poor daughter to use the ipod's interface a year or two ago (she was 4 or 5 years old).

The poor girl was getting so frustrated that pushing the sequence of buttons I instructed her to push did not have the desired outcome. Instead of scrolling a song list, the volume would go up!

Why?? The ipod only has three or four buttons. That's not enough to express 100 different operations. So the buttons must be overloaded; they must be made modal. That is, the same button does different things in different contexts. This is precisely what you want to _avoid_ when designing a _humane_ interface. With the 100-button remote, there's no ambiguity, no context, no modality.

With the 100-button remote, you don't have to remember to press a sequence of buttons in a specific order, with specific time intervals between the button presses. With the 100-button remote, the operation boils down to pressing a single button.

Even better: once you've performed an operation once or twice, you've formed the habit. Doing the same operation again later would take you no time, because you now know that the second button from the left on the top row is the one you want.

I have nothing against the apple ipod. it just has an in-humane interface, that's all.

Why am I talking about iPods on a Java weblog? Because the same principle behind designing the interface for a remote control applies to designing humane interfaces in our software applications. elharo brought up remotes as an analogy in the context of designing interfaces for List or Array objects, stating that such a class should have a minimum of methods, and that its design was consequently better.

We're all in one way or another responsible for designing interfaces. Let's make sure they're humane. If you haven't already read THI, I highly recommend you do. Here's the link:

http://www.amazon.com/gp/product/0201379376/104-7232126-4081541

Comments

• I suspect the truth is somewhere in-between.

  I know a lot of people with iPods and not one says it's difficult to use - usually the exact opposite.

  But then I know some people that can't understand that you're suppose to let go of a mouse button once it's been pressed and not keep it down for minutes at a time.

  My grandmother would have no problem with the iPod interface, so long as the buttons were 3 times the size and labelled white or yellow on black - she's visually impaired.

  Honestly, this is not something to get religious about, or bandy terms like "nonsense" or "infinitely better."
  

  Posted by: goron on December 14, 2005 at 12:42 PM

• 
  I hope that you are being a little tough-in-cheek with this. A remote with 100 buttons is no better than one with four--unles you're a geek like moi. ;-)

  
  The real answer is that the right number depends on the items being controlled, the user performing the actions, and the expected needs. I can accept a more complicated remote than my wife, not because of intellegence but because I'm willing to and she is not (those Mac people are soooo hard to please ;-).

  I have a Tivo and I think that their remote is the best one I have ever used. It has around 20 buttons, but they are of different sizes, shapes, and colors. Plus they have a "natural" arrangement (at least to me). The pause button (their raison d'etre) is the largest button, in the center of the remote, and it has an orange color. When holding the remote my thumb "naturally" rests on it). Contrast that to the remote that came with a JVC VCR. It had nearly 40 buttons arranged in a grid with all of the buttons the same size, shape, and color. The only way to use it was to be able to read the words above the buttons (very hard to do while wathing a movie in the dark). A terrible design that caused the VCR to not be used

  
  I do agree with you about the iPod controls. It is neat and cool but not really usable. Except for certain youths who can text message from their phones without looking, it requires one to watch the screen for even the simplest operations and even those are hard to remember and control.

  
  I haven't read the book in questions but I do have to say that Apple usually does "get it right" or at least closer than anyone else with their computer interfaces. I have never had a problem stepping up to a Mac and using it and getting it to do what I want (though I do want at least two mouse buttons ;-). I'm still trying to get my Windows box to do what I need let alone what I want.
  

  Posted by: jkeesey on December 14, 2005 at 01:02 PM

• in hindsight, maybe such statements as "That's absolute nonsense." do sound a little harsh. what can i say, thus was my initial reaction.

  i don't so much have a problem with folks who prefer inhumane interfaces. my issue is that they've usurped the term humane. maybe they should stick to "minimalist" interfaces or some such term.

  you've hit on a great point: color-codes, button sizes, or relative arrangements of buttons are all terrific examples of enhancing a remote to improve its interface. what you're effectively doing is providing ways to reinforce habit forming. making all buttons look
  the same does not help. i suppose in that respect the ipod doesn't score as low. nevertheless, the point is made that one cannot operate an ipod without staring at it; one must be aware of the state of the machine in before performing any operations (or otherwise, they'll be performing the wrong operations).
  

  Posted by: eitan on December 14, 2005 at 01:18 PM

• Let's bring it back to Java.

  The argument against classes with many, but useful, methods, is that it is hard for programmers to find what they want to do. Now in the analog we're saying that 100-button remotes really are awful, unless they're intentionally designed to make the most important parts stick out using size, shape and colour.

  So the question now is, how do we do this for Java?
  If we want to create classes with 100 useful methods, how will we make the most important ones easier to find?

  Graham

  Posted by: grlea on December 14, 2005 at 02:39 PM

• 
  What has worked well for us is to put the most important/useful operations on the class and to create a helper class with static methods to perform the occationally useful operations that would otherwise clutter up the class. This also works for classes (like java.lang.String) that we cannot change. We have adopted a convention of naming the helper classes XXXHelper where XXX is the class name that is being augmented (for example StringHelper).

  
  This doesn't change the color or size but at least it keeps the interface from containing 100 methods.
  

  Posted by: jkeesey on December 14, 2005 at 02:50 PM

• Check out my earlier blog on this: Humane interfaces, simplisticity, and domain languages.

  Next, Eitan, you're falling into exactly the same hole as so many other folks in this discussion... The belief that there's one true, right answer for everybody, all the time. That's just plain false. Context matters. The "right" remote for a techno-geek like me is quite different from what's "right" for an 80 year old grandmother with arthritis, a bad back, and who only ever watches a couple of different channels. The very point of "humaneness" is that we must take the wondrous variety of reality into account and deal with that gracefully.

  Posted by: johnm on December 14, 2005 at 05:36 PM

• Graham, dealing with 100 methods isn't anything new. We already have a boatload of mental tools to deal with them. One well articulated area are "code smells" ala Fowler's "Refactoring". There's also categorization that we've all been taught in terms of OO hierachies as well as the new buzz of "tagging". Anyways, if you look at those 100 methods you'll fine that they are groupable in some ways (modal, behavioral, creational, domain, infrastructure, etc.).

  I read a ridiculous amount of code and I've certainly never found any actual need for any class written by humans to have anywhere near that many methods -- it's always been the case that that class was trying to be too many things to too many people and it wasn't doing anything really well for any of them, was buggy, harder to maintain, etc. Heck, the very example under discussion (Lists) shows this quite clearly: Ruby's list class is overloaded ("overused" :-) to be a random list, a set, a queue, a stack, etc. whereas Java has separate classes for each of those notions.

  Posted by: johnm on December 14, 2005 at 05:47 PM

• Helper classes are awesome, especially Java's Collections helper class.
  Since List is an interface, methods like Collections.min() work on both ArrayList and LinkedList. There's less to learn! Otherwise it would be necessary to write methods like min() for every each collection implementation.

  Posted by: jessewilson on December 14, 2005 at 06:07 PM

• I think it's important to make the distinction here between humane user interface and humane API's/code. The two seem to be mingling pretty fluidly throughout these discussions and I think it makes sense to separate them.

  Granted I think that API and code design is important. But the users and uses are in a completely, completely different context. One is someone who uses computers and one is someone who builds them.

  The term "humane interface" was really coined to discuss user interfaces. Code is just as important, but maybe we should coin another term for that discussion.

  -jonathan

  Posted by: jonathansimon on December 15, 2005 at 06:13 AM

• The term "humane interface" was really coined to discuss user interfaces. Code is just as important, but maybe we should coin another term for that discussion.
  I think your own Humane API suits quite well. If you like, we can even reduce that to HAPI, and pronounce it "happy" =)

  Posted by: aidan_walsh on December 15, 2005 at 06:27 AM

• Actually, I think we should allow CSS annotations on Java methods and classes. Make 'em stand out the way they oughta stand out.

  Posted by: pdoubleya on December 15, 2005 at 07:10 AM

• what a terrific discussion. i agree with pretty much all that's been said. my solution to finding the method i need in the haystack of the java apis was ashkelon. but i think we can go further. the first idea that jumps in my head is to use java 5 annotations on methods to distinguish a core method (such as list.add) from a utility method (such as list.last). the annotation could be translated into a css annotation (class="atname") in the generation of the javadoc page in a web app.

  Posted by: eitan on December 15, 2005 at 07:37 AM

This work is licensed under a Creative Commons License.