3 ms·
My favourite part of this article (disclosure: I've made almost this exact comment before elsewhere): > The see-and-point principle states that users interact
by svat 6y ago
My favourite part of this article (disclosure: I've made almost this exact comment before elsewhere):
> The see-and-point principle states that users interact with the computer by pointing at the objects they can see on the screen. It's as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible (all files more than one week old), objects that don't exist yet (future messages from my boss), or unknown objects (any guides to restaurants in Boston).
Does this mean a commandline is always better, because it's more expressive? No, it's a trade-off between this and ease of learning:
> The GUIs of contemporary applications are generally well designed for ease of learning, but there often is a trade-off between ease of learning on one hand, and ease of use, power, and flexibility on the other hand. Although you could imagine a society where language was easy to learn because people communicated by pointing to words and icons on large menus they carried about, humans have instead chosen to invest many years in mastering a rich and complex language.
There's a neat coincidence that illustrates this tradeoff. While this article says:
> If we want to order food in a country where we don't know the language at all, we're forced to go into the kitchen and use a see-and-point interface. With a little understanding of the language, we can point at menus to select our dinner from the dining room. But language allows us to discuss exactly what we would like to eat with the waiter or chef.
Joel Spolsky's User Interface Design for Programmers (an excellent book, looks like it's available online in full on his blog: https://www.joelonsoftware.com/2001/10/24/user-interface-design-for-programmers/ https://www.joelonsoftware.com/2001/10/24/user-interface-des...) says:
> Using a command-line interface is like having to learn the complete Korean language just to order food in the Seoul branch of McDonalds. Using a menu-based interface is like being able to point to the food you want and grunt and nod your head: it conveys the same information with no learning curve.
I'm pretty sure it's a coincidence that the same example of a restaurant in a foreign country is used, but despite apparent contradiction, they make the same point: The text interface requires more time to learn, in return for being more expressive and powerful. Whether that's worth it to you depends on how long you intend to live in that environment, and how rich an experience you'd like to have.
- paulryanrogers 6y agoFor output graphics can express a lot of complexity quickly. Consider a text vs graphical adventure for example.
- thomastjeffery 6y ago> > Using a command-line interface is like having to learn the complete Korean language just to order food in the Seoul branch of McDonalds. Using a menu-based interface is like being able to point to the food you want and grunt and nod your head: it conveys the same information with no learning curve. That analogy makes one significant assumption: that you are trying to order food from McDonalds, which is a thing you are used to doing at place you are already familiar with. Of course it's more difficult to learn Korean when you just want to order some American food, but what happens when you try to order Korean food? What if you are trying to do something more complicated than order food? There are cases where learning Korean would be clearly beneficial. The limitations of GUIs stand out most in technical tools. When the thing a user is trying to do is already complicated, it doesn't really help to give them a simplified menu system: that just provides a frustrating amount of options. There has been a significant prejudice in UI/UX design to optimize for approachability, even when expressiveness is a better target. Ordering food is a great use case for "point and nod" UX. The pointing and nodding only needs to occur a small number of times. There is much more need for approachability than expressiveness. To contrast, editing text is a terrible use case. A point and nod system would involve a fatiguing amount of pointing and nodding. There are reasons that tools like Vim and Emacs are widely popular, even with their steep learning curves.
- noobermin 6y agoThere are ways to do this even with GUIs, the prime example being "expert" software like 3D graphics tools like Maya or Blender or things like CAD although CAD's origins were command oriented.
- thomastjeffery 6y agoBlender does it especially well. The only thing it's missing when compared to command-line utilities is composability with other tools like pipes. Blender has tons of features, and it has to because of its monolithic design. Then again, collaborative (open source) design is the workaround for monolithic software, and it's worked exceptionally well for Linux and Blender.