6 Feb 2007
Beginners and Experts
“You make something more powerful for the experts at the cost of making it harder-to-learn for the novices, or else you make it easy to learn for the novices at the cost of making it less powerful for the experts.”
True or False?
Sure we’ve seen lots of examples of this trade-off; sure lots of people think it’s an obvious truism; but is it a law of nature, or is it just an excuse for lazy interface design?
My six-year-old sister loves Google Sketchup. Even if she doesn’t understand the nuances of it, she mastered the basics of it quickly enough to begin making little villages full of blocky buildings and clip-art people and trees.
Meanwhile, my stepdad tells me that his architecture firm has quickly adopted Google Sketchup as well. He says Sketchup has rapidly displaced AutoCAD for all but the most formal and specialized uses at his company.
If both six-year-old girls and professional architects are using and loving the same program, then it must be doing something to meet the needs of both beginners (need for learnability) and experts (need for power).
Another example, close to my heart, is the Python language. It makes an excellent first language for teaching programming to beginners. It’s also favored by professional developers (like us, for instance, and also Google) for rapid prototyping and sheer productivity.
Why? It’s a good language for beginners because it doesn’t have any of the distracting, extraneous, illogical stuff that plagues lots of other languages. You don’t need to write a lot of boilerplate code just to make a “Hello, World!” program. You don’t need to match up your curly braces, or declare variables. In Python, every single line of code you write is doing something productive, so you can get started on the interesting stuff right away. Furthermore, Python is easy to learn and remember: you don’t need to learn a lot of special cases or exceptions or rules for special circumstances because Python is quite consistent. At the same time, it’s flexible about paradigms: procedural, object-oriented, and functional programming styles can be mixed and matched in the same Python program. Finally, it’s easy to learn how to expand Python’s capabilities: finding and importing modules for specialized tasks is easy, and introspection makes it easy to figure out how unfamiliar modules work.
On the other hand, Python is favored by professional developers for… exactly the same reasons.
This is an important point, I think. I’m not just saying that it’s possible to strike a balance between beginners and experts. I want to make a stronger statement: the qualities that make an interface good for beginners can be exactly the same as the qualities that make it good for experts.
The assumptions behind the “beginner - expert” divide are bogus. Think about it. Everybody approaching a new piece of software has to start from zero. Even within a single piece of software, there can be functionality which is intimately familiar and functionality which is totally mysterious. On the Linux command line, I consider myself an expert user of the ‘grep’ and ‘find’ and ‘ps’ commands and so on, but I can’t use the network-configuration commands without consulting a manual. And I’m sure there are plenty of useful commands which I don’t even know exist. My point is, everybody is an expert with respect to some software functions and a beginner with respect to others. Are you one of those guys with suspenders and a beard who’s been hacking Unix since before I was born? You’re an expert by any definition, yet still your computer has functionality which you’ve never touched, and with respect to that functionality, you are still a beginner.
Therefore, I say, all software should be designed for beginners!
And once you’ve been using a piece of software long enough to be considered an “expert” at it, do you want to suddenly switch over to using a new “expert” interface? Quite often, just as I am getting nicely habituated to the interface of my “beginner” program, I find that it lacks so me vital features, and so I am forced to make an unpleasant switch to an “expert” program — something with lots of features, but a horrible broken interface. (I’m not going to name any names here, but there are certain “advanced” graphics programs and plenty of IDEs that come to mind.) In each case, wish I could have stuck with the simple program, but its lack of needed features mean that all the time I spent learning it was ultimately time wasted.
Therefore, I say, all software should be designed for experts!
The designers of the world can do better! We can aim to make applications that have all the features that “power-users” need but an interface that makes them easy and pleasant to use for power-users and beginners alike.
Specifically, the idea behind Enso is that opening your stuff by name is a better interface than opening your stuff by hunting through a folder hierarchy for it. It’s better for beginners who don’t necessarily know where to find things yet, and it’s better for experts who know exactly where to go but want to get there without extraneous clicking. Of course we don’t claim to have invented this idea. It’s as old as the command line. But Unix and DOS command lines are the archetypal example of environments that provide power for experts but have a terrible interface for beginners. We hope that Enso will show people that the difficult and arcane nature of Unix and DOS command lines was a design flaw in those specific systems, not an inherent property of language-based interfaces.
All the elements of the Humanized design philosophy — Modelessness, information-theoretic efficiency, habit formation, non-disruption of the user’s train of thought, sacredness of the user’s data, and so on — are not aimed at beginners or experts, they are aimed at all users.
by Jono DiCarlo