|This blogger has moved!|
I want to invite you to my new gig over at Light Thinking. We are devloping light gadgets for photographers.
You can't be a designer and not be into photography at some level. Maybe you know about the whole off-camera strobe movement that originated over at at strobist? Maybe you even know about the new HDSLR cameras and all the amazing stuff people are doing with them?
Visit Light Thinking
We were up in the mountains this weekend (v. nice!). My wife, who is a linguist, told me about some theories regarding learnability of languages.
You would think that it would be easier to learn to write, it the written language is very similar to the spoken language. Some languages strive to achieve this, while other languages don't. Swedish for example, is a very conservative language. Words that were added to the language hundreds of years ago is still written the same way today. They have about 30 ways to write the "sh" sound.
Apparently it seems that it is NOT easier to learn to write when the written language is similar to the spoken. It is easier to learn to write when the internal structure (the grammar) is clear and consistent. How the actual words are spelled is of lesser importance.
This made me think of how users learn to use a new software. Most people look at new stuff to get some kind of hint as to how it works. They try to fit it to something the know from before. They try to fit it to a mental image.
This is the reason for user interface metaphors. You use a software metaphor when you make the software look and behave analogous to a physical object the user already knows how to operate. Example: Make the "delete file" function look like a trash can. Since most people know how a trash can works, they should have little problem understanding how to delete files. Metaphors works well as long as they can replicate real life behavior fairly accurately. If you drag a file to the trash can, you expect the file to stay in the trash can until you "empty the trash" because thats the way real trash cans behave. The trash can metaphor works as long as it corresponds the users expectation of how a real life trash can works, and is internally consistent and predictable. If the trash disappears, moves around, if you can't look in the trash can and see the files you have put in there, the metaphor breaks and you get frustrated.
The limitation of software metaphors is that most of the time there is no good metaphor for the software you are building. Metaphors are normally based on physical objects and physical objects have properties you can not easily replicate in software. Or they have physical constraints or limitations you don't want to worry about in software.
Any user interface meant for repeated use needs to be learnable. So, if the natural response for someone is to look at your software and try to map it to something they know - and you can't use a metaphor, how do you make the user understand how to operate the software?
Forget "RTFM":-) Back to my wife's report from language research: When an infant learns to speak, it does not learn the language word by word. You might think that learning is like putting together a giant puzzle. You put it together piece by piece until one day you are finished. You place the last piece and voila! you can speak perfectly.
A little after the baby is a year old it starts to utter single-syllable "words". Half a year after that, it starts making small two-word sentences: "Milk allgone", "Mommy sock". It sounds like the baby does not know how to speak properly. This is wrong. Research shows that at this point the baby has an internally consistent grammar. However simple, it is a language with grammar rules, non-verbal clues and the whole symphony of elements that makes up a spoken language. There is not any "missing parts". The baby knows how to speak, it just speaks a much simpler version of our language. As the baby grows in mental capacity, it modifies and expands this language until it one day asks for your car keys.
Is this relevant to interaction design? If the brain learns software the same way as it learns language, then feedback and a simple and clear and internally consistent "interaction grammar" might be as effective or more effective than familiarity.