Linked by Julian Fietkau on Fri 11th Mar 2011 09:55 UTC
Graphics, User Interfaces Over the past few decades, the software that enables us to be productive with our computers has become increasingly sophisticated and complex. Today's UI designers are faced with the challenge of devising graphical user interfaces that are easy to grasp and use, yet still provide access to a wide range of features. Here are some ideas about the nature of GUI complexity, followed by a couple of thoughts on simplicity that might just surprise you.
Thread beginning with comment 465791
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

Some of those are pretty fundamental questions and I don't know if I would be able to answer them with a featured article, but I'll just try it right here:

With Don Norman's definition of complexity in mind, I'd say that the mouse has a rather low intrinsic complexity compared to the keyboard. It allows us to move something (a cursor, most of the time) around on the 2D plane, and to "click" to induce an action, and that's pretty much it. In contrast, the keyboard offers dozens of discrete possibilities for input, hundreds if you count every possible key combination using Ctrl, Shift or Alt.

Assuming that geeks are people who use their computers often, it seems obvious that they'd be looking for ways to speed up repetitive tasks. The keyboard is a great way to speed things up, because you have the aforementioned hundreds of ways to instantly tell the computer to do something. Every geek realizes at some point in their life that it is much faster to press Ctrl+X than to navigate the mouse to "Edit", click, navigate down to "Cut" and click again.

If it's faster, why doesn't everyone do it this way? Because keyboard combinations, just like the commands in any CLI, need to be memorized to be used, and that's not a priority for non-geeks. They use the mouse because that way the feature is discoverable. The mouse has, by virtue of its limitied possibilities for interaction, broken down the complex task of hitting exactly the right two keys on your keaboard to a sequence of simpler steps: moving the mouse, clicking, and then moving and clicking some more. What's noteworthy about this, is that precisely because it consists of several steps and takes longer to do, the user can get feedback along the way (visual or otherwise) and thus can check if the procedure is going as planned. For people who don't use their computers as often or don't feel as confident using them, the speed loss is an acceptable tradeoff.

Does that answer some of your questions? ;) I have a feeling you've had quite a few own thoughts on this, and I also think you're overestimating me. ;)

Reply Parent Score: 2

wannabe geek Member since:

Thanks for your quick reply. It's a great starting point. I just wanted to point out some paradoxes in those common observations, and how I think they might be solved, and how it could help to get some perspective in UI design.

Regarding the mouse vs the keyboard, the first surprising thing is that the mouse is actually a much more powerful piece of IO hardware, in terms of bits per second. Its true power is shown in graphical applications, such as the ones for drawing and modelling. Notice that, in principle, you could use the mouse for hitting keys in a virtual keyboard, therefore the difference is not in the mouse per se, it's in the hierarchical menu interface; that's why Ncurses UIs are about as newbie-friendly as GUIs once you learn the basics. They are also about as slow. Then we have, hierarchical menus are discoverable and easy on your memory, but slower. So, many graphical applications add keyboard shortcuts, and they add the shortcuts in their menu entries, which is great. But why should keyboard shortcuts require so much memorization? They should give you the available options as you go, just like menus do. I've seen some of this in Emacs and ION3, but maybe there's still some room for improvement. Emacs lets you cancel the whole command (C-g), but I haven't seen a prominent option to withdraw one key stroke and pick another one in a long key chord, as you would go back and forth in a menu. I guess you can do it with recursive edition of the minibuffer. Also, not just short descriptions, but longer explanations should be available as you type.

My take is that the main advantage of the keyboard over the mouse is the multitouch interaction. The human nervous system is better adapted to position ten points with low precision than one point with extreme precision, and thus the superior bit rate of the mouse is not helpful in most cases. That's also one reason why multitouch screens are so interesting, because they combine the best features of keyboard and mouse.

By the way, the CLI becomes much less daunting once you learn some little tricks such as the up-arrow, tab completion, man, --help, apropos and the like. It also is great when you ask in forum how to do something, and then you can just copy-paste the answer. You can't do that with a GUI! Why not? I think you should be able to. Just like your past CLI commands are available to copy and paste, so should be your past chosen menu options.Also, GUI scripting should be as easy as CLI scripting.

Thanks for your appreciation. Yes, I have a few ideas, but they sometimes contradict each other and the overall picture is still a bit messy ;)

Reply Parent Score: 2