SmoothSpan Blog

I was reminded again of something I’ve known for a long time and seen great examples of over a long period by something Reginald Braithwaite wrote in his Raganwald blog.  He muses that, “A programming language cannot be better without being unintuitive.”  Or, as he quotes David MacIver as saying of Scala:

Optimising your notation to not confuse people in the first 10 minutes of seeing it but to hinder readability ever after is a really bad mistake.

Reg never quite gets around to saying it, but the issue being discussed is that Ease of Use and Ease of Learning are two, not neccessarily orthogonal, but distinct dimensions when we talk about what it means for software to be “easy”.  This applies to all software and indeed most things humans interact with.  Perhaps the first vivid example of it I remember is a case from the “old days” of word processing.  A program called Word Perfect was absolutely killing a program called Wordstar.  The reason?  Word Perfect was much easier to learn, while Wordstar was much easier to use (i.e. more productive) once you had learned it.  Word Perfect introduced the notion of templates that went on the keyboard and a logical layout of keys that was easy to make sense of when you were hunting and pecking for your next command.  Wordstar focused on the idea that a good typist never wants their fingers to leave the home position.  Both programs were highly successful, but Word Perfect ultimately triumphed, and during the pre-Windows era, it was the most popular Word Processor in existence.

We see this conflict continue today between the keyboard and the mouse.  If you are a good typist and you’ve used a program that lets your fingers sing, you’ll know what I’m talking about.  The mouse is wonderfully efficient at a lot of things, and easy to learn, but for hard core powering in of text, having to reach for a mouse slows you down.

The web applications are still in their infancy when it comes to this sort of nuance.  It gets Ease of Use right a lot of the time.  If nothing else, pushing everything through the browser and its limited set of UI paradigms helps that out.  However, making web apps truly productive seems to be a dark art.   Such productivity is precisely what Rich Internet Application (RIA) ought to be about, but too often it is more about eye candy.

The next time you’re designing or evaluating a use interface, try to separate Ease of Use from Ease of Learning.  Think about whether there are ways to have both.  When a trade off must be made, be conscious of it:  “We are going to sacrifice some ease of use here in the interests of much better ease of learning.”  Think about your users and use cases:

–  Do your users treat the application as their primary tool, and use it for hours on end?  If so, you may want to make sure Ease of Use is well taken care of, preferably without making the application impossible to learn (remember Wordstar).

–  Is your application one that is used infrequently?  Do users tend to relearn it each time they use it?  If so, you should focuse strongly on Ease of Learning.

Don’t forget that the Learning barrier has to be crossed before any effective Use can take place.