Consider this user interface for a car:
The goal of these interfaces is to make you operate something, and operate it efficiently and safely. The grooves and clicks and limits constrain the range of motion and the number of choices. The visual look heavily hints at how to actively use it. They are usually not hard to learn. More importantly, the learning curve plateaus. Once you learn how to drive a car, there’s not much progression after that. Boundedness is an important property of these interfaces, by design.
Now look at this “user interface†for playing music:
Or this one for, among other things, manipulating words:
The goal of these interfaces is to express and create. Note the almost total lack of constraints. There are no hints in the interface as to how to “correctly†use these. To a newbie, a first look offers no hints for how to operate them. You have to go through a steep learning process to even begin to use these. More importantly, the learning curve never flattens. You could be playing a guitar for decades and still learn new things.Unboundedness is an important property of these interfaces, by design.
What makes one type of interface bounded and the other one unbounded? It’s the ability to combine. Physical interfaces (and by extension, GUIs) cannot combine at will to create new behavior. You can’t make changes to the way your odometer behaves, without ripping it out and putting in a new one. You can’t “pipe†the reading from it to an alarm that beeps when you go over a certain limit.
GUIs are modeled on physical metaphors and ultimately are grounded in the same motivations. They are intended to make you operate something, to get the job done. They want to narrow your set of choices at each juncture, towards the “right†choice.
The “right†choices are baked into the design, through a deliberate thought process. How will this be used? What are its users trying to accomplish? Which actions are more common than others? Which actions have the potential for confusion? Which actions are likely to be mistakes and should be discouraged? All these decisions are made by the designers and encoded in the user interface.
CLIs, on the other hand, are modeled on more abstract, non-physical models. GUIs continuously offer cues to the user about what to do. They strive for an externalization of knowledge. CLIs are for users with internalized knowledge. This fundamental cognitive difference is important. Internalization is critical for power use.
This explains why programmers of tool-heavy languages like Java often complain about IDEs being a necessary evil. Yes, they help you get the job done faster, but IDEs tilt the mode of thinking from expression towards operation. That’s why they feel stifling. How often have you felt like an IDE-operator rather than a programmer?
There is a time for operation, and a time for expression. Most interface debates are misinformed because they are about creators complaining about operation interfaces, or operators complaining about creation interfaces. We need both. But we also need to understand when.
Source:http://blog.vivekhaldar.com/post/8950163616/gui-vs-cli-operation-vs-expression
