Speed and learnability do not directly fight each other, but it seems easy enough to design such a GUI that lacks either (or both) of them. GUI designers seem to prefer ‘easy to learn’ most of the time even when ‘fast to apply’ would be wiser.
There’s only few UI concepts or programs that are weighted towards maximizing the peak efficiency of whatever you are doing with the program. Most of them haven’t gotten common.
Normal people prefer gedit instead of vim. For normal people there are already good-enough GUIs because there was tons of research on them two decades ago.
I’d like to get some advices on doing UIs that do the tradeoffs from ‘easy to learn’ rather than from ‘fast to apply’.
We have a product in our lineup that has won numerous awards based largely on its ability to provide more power with an easier interface than any of our competitors. I designed the interface a few years after holding a position in one of Bell Labs’ human interface research groups so I had a pretty clear idea of what constituted ‘success’ when I approached it. I have four pieces of design advice for creating easy but powerful interfaces.
First, select a metaphor that makes sense in their environment and do your best to stick to it. This doesn’t have to be a physical metaphor although that can help if working with people who are not tech savvy. This was popular in the early days of Windows but its value remains. We used a ‘folder and page’ metaphor that permitted us to organize a wide range of tasks while not crimping power users’ style.
Second, offer a consistent layout relationship between data display and tasks. In our interface, each ‘page’ displays a set of action buttons in the exact same position and, wherever possible, uses the same actual buttons. Thus, once one page is learned, the user has a head start on learning the rest. One of these buttons, always placed in a distinctive position, is a ‘Help’ button…which brings me to point #3. The more general rule is: find ways of leveraging learning in one area to assist in learning others.
Third, offer context-sensitive help and make sure that it addresses the user’s primary question (which is usually ‘what do I do now’?) How often have you seen technical help that simply shows you the Inheritance tree, constructor syntax and an alphabetical list of methods? That isn’t help, it is abuse. We focused all of our help on walking people through sample tasks. In particularly tough areas, we also offered multimedia tutorials.
Fourth, offer users the ability to customize the interface. Our users often had no use for specific ‘pages’ (analysis types) in their work. Thus, we made it very simple to turn them off so that the user would see an interface that was no more complicated than it had to be. Our app was usually installed by a power user and then used by multiple staff members so this was more of a win for us because we could usually count on the power user to understand what to shut off. However, I think it is good advice in general.
Good luck!