Conceptual Models II

From Cs160-sp08

Jump to: navigation, search

Lecture on Feb 12, 2008

Slides

Lecture Video: Windows Media Stream Downloadable .zip

Contents

Readings

Max Preston - Feb 07, 2008 02:37:23 pm

I think one very important fact to note is that this article was published in 1985. Many ideas that were considered to be amazing breakthroughs in 1985 are considered standard now. For example, the basic desktop system in Windows can be thought of as a type of Direct Manipulation Interface, in the concreteness of moving files and folders around, even if it seems completely ordinary to the average user. Touchscreens and wii-motes are also great examples of Direct Manipulation Interfaces. I think the abstract way in which the article is written makes it more difficult to make these sorts of connections, when in fact many applications use aspects of direct manipulation to make their interfaces more intuitive.

Benjamin Lau - Feb 07, 2008 11:48:34 pm

Yeah I have to agree with Preston, the article is not really interesting from a more modern perspective and it takes a bit too long to convey some relatively simple ideas, eg that you should make visual representations of an object behave like the object. I think most people get this metaphor pretty naturally and it's rare for it to be abused (one example though is the transfer effect with sending a disc to the "trash" in Macs-- something you wouldn't do in real life.) The idea of using visual computational components is neat but it doesn't seem like the article was the first one to suggest it and despite its claim that experts would love the extra afforded power, we still see things like Verilog being preferred to Logisim in industry so it doesn't seem all the predictions held up after all these years. I guess the paper was probably a landmark when it came out and formalized all the vague notions that people have about HCI, defining explicit terms for UI properties like semantic and articulatory distance. But while this was important and necessary for advancing the field by creating some kind of framework I don't see it being particularly relevant anymore other than for historical purposes.

Gary Miguel - Feb 08, 2008 01:03:48 pm

This reading introduced a lot of jargon for talking about human-computer interaction. The term that most caught my attention was "directness". According to the paper, a direct interface is one where there is a short "distance" (another term of jargon) between how the user thinks about a task and how the user interacts with the computer. While reading this, I thought a lot about cs61c. In that class, we started programming in C, which was much less direct, in the language of the authors, than Scheme. Soon I was programming in MIPS assembly language, which was incredibly indirect. To write an even mildly complex program in MIPS assembly, I would usually start with a description in English of the process, then write an outline in C, and then finally translate this to assembly. According to the authors, this is exactly the sort of process that should be shifted to the designers of a system, and I completely agree. The fewer steps between knowing what one wants to do and figuring out how to make the computer do it the better.

The reading is old, but I think it's still extremely relevant.

Hsiu-Fan Wang - Feb 08, 2008 02:15:04 pm

Sidenote: Am I the only one who thinks that the example of a direct manipulation interface (as shown in Figure 1) is terrible? I imagine anything non-trivial is write-once, once it works, you have this mass of lines and modules that do something but is very difficult to summarize.

Reading through the description of directness, I had a thought that works quite well in contrast to Gary Miguel's comment on Scheme being more "direct" than MIPS. For a given problem, the framework that a user considers the problem can vary widely; I would argue that MIPS is the most direct of the three languages he suggests, as you are truly programming a hardware computer. There is a very tight mapping between instructions and a particular action undertaken by the device. At the same time, Scheme is more direct for the task of implementing an algorithm or performing a computation. And yet these two tasks are not so far apart that I think it is difficult to use directness to meaningfully evaluate interfaces for a general purpose.

EricChung - Feb 08, 2008 07:11:54 pm

On an unrelated note, I thought this was the hardest one to read so far. I thought the language of the paper was INDIRECT. HAHAHAHAHAHAHAHAHA.

... Anyway, I thought the topic of discussion was interesting, not only because it talked about my future livelyhood (in 80s terms) but also because I had never thought about interfaces in terms of "gulfs of directness", which is a nice way of thinking about interfaces a person has to interact with; it certainly enlarges the design vocabulary. The fact that you can bridge the gap from both sides is useful and I think the paper spent a lot of time on the machine aspect. Although he did mention stuff about the user learning the system to bridge the gap, he stopped when it involved memorizing different "functions" and so forth (in the programming language example he was constantly talking about). Really, though, this, I think, is much better than bit pushing every single thing you want to do. If you DO want to do something different and an obscure function exists for it, it's a matter of looking it up in the documentation or asking someone in the know, which coupled with the fact that normal tasks are much easier, is a lot better than bit pushing everything (although the paper said something along the lines of "experts will feel normal tasks in a low-level language are very direct", although then a learning curve exists, not to mention a lot of unnecessary typing). At first I thought a graphical programing language would be sort of bad because then anyone could program, but then stuff like visual basic (6.0, not .net) is already out and then I realized programming is probably more of a mindset type of thing. And I think the paper is right in pointing out these direct manipulation languages may be at the wrong level of difficulty, since if the user gets closer and bridges the gap naturally, any design bridging will appear clumsy. As far as user interface is concerned, though, most people aren't programmers so that would naturally lend to more of a bridging on the deisgner side, not the user.
The last section seems to suggest that direct manipulation is simply just another language with its own use, which explains why it hasn't taken the world by storm, even after 20 years. I think that's pretty accurate.

Eric Cheung - Feb 09, 2008 12:29:37 am

I would have appreciated some more concrete examples, though I guess in 1985, there wasn't much out there to reference. Most notably, the abundance of diagrams weren't particularly helpful. I found it interesting that it mentions economic reasons to as why users are still restricted to the keyboard, yet 23 years later, everybody's still using keyboards, even though they're relatively cheap. Granted, there is some limited use of touchscreens and wii-like motion sensitive controllers as input, but there really hasn't been much change on that front on the personal computer. In particular, the chapter says "Increasing the articulatory directness of actions and displays requires much richer set of input/output devices than most systems currently have.", yet we are still stuck with the same mouse and keyboard the authors list as limitations, suggesting that we still haven't bridged the articulatory distance quite yet.

Brian Taylor - Feb 09, 2008 10:08:38 am

Many lols to Eric Chung's joke...Alright, on a more serious note, as I was reading this paper, three things popped into my head: Matlab/Simulink, Labview, and Logisim. I know one might interpret that as four things, but Simulink is as I believe some portion of the larger Matlab program. Anyway, all three of those programs have a form of visual manipulation similar to that described early in the reading. It is interesting to note, however, that despite the uses of a 'direct' interface, I personally felt that while Logisim achieves the feeling of directness rather effectively, Simulink and Labview appear to have had much less success in popularity. As classes such as EE20 are being forced to use Labview's visual programming flow (essentially connecting blocks in some sort of flow chart), numerous students, I've heard, have complained about how difficult, annoying, and counter-intuitive it is to program in such an interface. It would seem that either people are so entrenched in their writing of text code that they cannot recognize a potentially superior interface, or, as Hutchins, Hollan, and Norman bring up, such an interface for this task may actually just be a bad idea. They argue that although direct manipulation interfaces will continue to grow and thrive, programming languages at large will probably not disappear because, as many students have notice, writing a program can sometimes be incredibly tedious and frustrating in an environment that uses visual components. One reason I feel that Logisim seems to be more popular is because we are constructing a virtual model or representation that fairly closely mimics the physical truth. When one is writing a program, there typically is no physical representation of blocks or tools or machines that one can shove some input into and get the desired output. I personally do not think of a physical representation when I code, and although I could be wrong, I feel that most others don't as well. In using Logisim from cs61c, however, we actually modeled a CPU with the same components that would physically be on the chip (ignoring a bit scaling, tidiness, etc.). For the most part, our CPUs were just virtual maps of what physically exists, and since I knew this and could physically imagine my computer's CPU with the same components, I feel that using the direct manipulation interface was not only much easier than using Verilog, but also much more fun.

Khoa Phung - Feb 09, 2008 12:13:51 pm

This article shows how important the directiveness between user interface input and output is. The water level rate was a great example to show how the computer can translate numerical data into visual data to ease the interpretation of the user. However, the author also notes that as the language approaches the user's intention it becomes more complicated and specialized; therefore loosing its generality and ease of use of the language. The comparison of the piano and the violin make it very clear. However, I am also surprised that it is mentioned that some tasks will be impossible. Current technologies such as Virtual Reality and "Mind reading" gadgets seem to become a very popular approach that may have the power to break the barrier. That research is still very young, but I have heard of research where people could control a robot just by thinking it. Of course, the user had to learn to "think" the correct thing, but it can be improved over time.

Glen Wong - Feb 09, 2008 03:33:06 pm

On a reading about creating interfaces which are direct and easily used by the user, the wording of this article is surprisingly indirect and inaccessible. That aside, the points which came across seemed valid. I agree on a good interface providing the user a feeling of direct interaction where the user can feel like they are interacting directly with the solution rather than going through an interface where they are forced to morph their thinking to match that of the program. One point that I disagree on is the one where high-level languages, while providing better accessibility to the user, also presents an increased vocabulary and imposes limitations on what tasks can be accomplished. I think today we see a lot of high level languages, like python, which provide both better accessibility to the user, as well as, flexibility in what can be done with such languages. Though perhaps one could argue that python offers higher level constructs which are a form of "increased vocabulary." In this way of thinking the author is correct, but I think I would consider python and similar high level languages to be more accessible than low level languages like assembly.

Bo Niu - Feb 09, 2008 03:31:18 pm

There were many important attributes of a good user interface were listed in the article, and we can see the implementations of these ideas everywhere today's application user interfaces. The a great example of the world model interface today is the 3d video games. Instead of looking at a ordinary interface, users are interacting with a visual world. It was very interesting to see the ideas behind all the modern user interface that we take as granted everyday, and how much thinking was put into these designs so that the users can think less while using them.

Ilya Landa - Feb 10, 2008 03:05:54 am

Overall, this was a fairly a dry reading; had many strong and some weak points. Among the strong points, naturally, is setting a goal for all programs to make their interfaces “invisible” – allowing users to thing about the process itself, not about an interface. Modern days Windows and Mackintosh seem to be created following these guidelines; these systems are designed in such ways that even casual users soon stop thinking about all the nuances of their operating systems like which button to press, which window to open. Instead, these users can define their tasks in high level terms concentrate on executing them: “Create a Word document and e-mail it”. Many rules defined in this article like the ones above can be found in many modern applications and are considered the ideals for creating interfaces. However, since nitpicking is fun, here are some not so successful ideas from the reading. The authors of this article speculate about different forms of input: sounds, touch, even smell. Many science fiction writers of that period also fantasize about such innovations, feeling limited by primitive keyboards and “small, low-resolution screens.” However, sight is a dominant sense in humans, much more precise than hearing or smell. So far, no method has been developed for using these senses to encode as much precise information as it is possible with a simple monitor. Also, it is doubtful that touch or speech will ever be able to compete with keyboard and mouse outside of applications specifically suited for speech input. One more piece of criticism and I am done: authors scorn Lisp and UNIX for being overcomplicated, cryptic, and not easily accessible by users. And while all these descriptions may be true, the author could not envision the full scale at which the computers would be used today. True, they knew the computers would be huge; that is why they worried about a casual user terrified of a command line. What they, probably, did not imagine was that there would be so many computer users that creating and maintaining a separate package of operating systems for proficient users would not be a burden. That is why UNIX is so widespread now despite its apparent inaccessibility.

Alex Choy - Feb 10, 2008 05:55:09 pm

I feel that the diagrams that were included were not always helpful. Some of the examples given were unclear and difficult to understand. Of course, it was good that the article provided so many examples. The article mentioned Articulatory directness, which I feel can be seen when comparing GDB with DDD (the data display debugger). DDD provides a graphical interface to interact with GDB (which is command based). For example, when displaying the contents of an array, DDD shows a graphical image of the array and the contents it holds. In addition, it is easy to see what a certain entry contains (or even an object or variable of that entry). Another thing is that because direct manipulation interfaces have difficulty handling variables, lower level programming languages have an advantage over graphical ones. When abstracting tasks, a good balance needs to be maintained. Also, people think in different ways. Direct manipulation interfaces require the interface to provide a comfortable way to think in terms of the application domain, and not all people will think about the application domain in the same way. Therefore, there can be problems with different users using the same interface.

Michael So - Feb 10, 2008 06:45:14 pm

This was sort of a difficult reading in the comprehension department. I am a little fuzzy on the what is semantic distance and what is articulatory distance. Semantic seems to be about user intentions and language. Articulatory seems to be more about actions and aesthetics. About the directness thing, I want to comment about the minimizing cognitive effort. When I think about tasks that don't use minimal "cognitive effort", I would think of the tasks as either being intuitive, or automatic. I haven't thought of them as being "direct" or as having a feeling of being "direct". But when I think about it, interfaces where you move around objects (like folders with your mouse), it's intuitive and requires minimal cognitive effort and it's direct manipulation.

I don't think programming done graphically will cause the programming done "textually" to be extinct. Because as the author pointed out, there are tasks better suited for a graphical user interface and others for a more text/language-based programming. Some things are sometimes best communicated "symbolically" than graphically.

JessicaFitzgerald - Feb 10, 2008 09:03:17 pm

I found this paper extremely hard to follow and difficult to understand what point the author was attempting to make. Even with his example about the differences between the directness of the piano and the violin, his point was very unclear to me. Although I was able to understand that how direct an interface is depends not on the interface itself, but how the interface is used and looked at. That doesn't seem to make too much sense though, because an interface should be direct because of what it is able to do, not how it does it, which the article seems to suggest the contrary. I also thought it was interesting that an interface can be direct in the eyes of a user depending on how frequently they use it, because if they use some feature often, then they use it with ease and view it as direct. But if they barely ever use it, they may find it to be quite indirect.

Gerard Sunga - Feb 10, 2008 09:10:23 pm

A bit of a side note: The article was fairly interesting, although it seems a bit dense and out of date when looking at the core concepts it presents. For example, Windows has had the "object representation" of files, with the appropriate interactions with them) for well over a decade. Also,the jargon used to describe some of the major concepts seems really odd (semantics/articulatory distance? gulf of execution/evaluation?)

One of the more interesting things I found about the article was the fact that they constantly referred to "language" as a primary interface for this "direct manipulation interface." I don't dispute the fact that command-based interface is vital, but considering the Apple Lisa was released before this paper was published, I find it odd that they're not pushing for a more mouse-based GUI interface. They seem to push for a more complicated solution that is geared for developers rather than a typical user through not mentioning many alternatives to a command line interface. They do not even mentioning (as far as I can tell) abstracting away basic system commands from the typical users. Instead they seem to simply complain about the problems of the growing complications arising for the desire for more options.

Chris Myers - Feb 10, 2008 10:05:49 pm

What a perfectly cromulent paper.

But Seriously. The more delicate features that you pack into your program, the more the user will be able to articulate tasks. This will in turn, cause more distance semantically, as the extreme number of individual functions causes the interface to be complex. There is a delicate balance as to what works best for whom. For example, I found it easy to learn to use an attractive text editor called kate, for the KDE desktop. The graphical interface was large, attractive, and the syntax highlighting is excellent. I'd say the interface has a very close semantic distance for a programmers text editor. But like many KDE programs, the mouse is needed heavily for editing. Additionally, it tries to be a jack of all trades for computer languages and does not a single one really well. Now, if I'm coding lisp, nothing will beat emacs. It has a zillion keyboard shortcuts and if I took the time to learn them all, I would be very close articulately to programming.

There is a tradeoff, I think it has to do with what the users already know, and how much they are willing to learn.

Jonathan Chow - Feb 10, 2008 11:23:00 pm

In the abstract, the points made in this paper make a lot of sense. Interfaces that the user can intuitively respond to and directly manipulate are easy to understand. Unfortunately, what one user sees as direct is not necessarily what another user finds direct. Like Brian mentioned, I remember when I took EE20 and had to use Labview. Many of the EE people found it really intuitive to use. They liked the way there were blocks that you could drag around and connect. On the other hand, I hated how I had to draw tons boxes and connect them just to make a for loop. Is this because I am used to the more indirect programming languages? Probably. This brings up the point that although indirect interfaces that could require lots of memorizing "shortcuts" like their vi example could condition people to expect the same thing out of other interfaces. If users don't have these options, the work might seem even more indirect. I'm not sure if I'm arguing in a circle, but I think this means that sometimes the more direct solutions may be in fact less direct, but more intuitive based on the user's past experiences.

Nir Ackner - Feb 11, 2008 12:27:16 am

I was not surprised when I saw the number of readers that commented on how the article seems to describe Labview. In fact, Labview was first released in 1986, one year after this paper was published. A look at the successes and failures of this product, then, would be highly informative of the benefits and drawbacks of direct manipulation interfaces in general. It seems that the authors of this paper made quite good predictions about the value of such interfaces for the layman, as seen in the popularity of Labview amongst programmers with little formal CS background. They also predict very well the drawbacks of such systems, and admit that they will never replace conventional languages.

David Jacobs - Feb 11, 2008 12:30:54 am

Many of the comments submitted thus far discuss the dated nature of the Hutchins et al.'s article. Although I agree that for modern readers the text probably spends more time than necessary describing the benefits of direct interfaces, I must say that its value still remains. For the most part, modern software interfaces rely on entrenched interfaces that are only direct because they are learned (such as the vi expert described in the reading). The menus, buttons, and scroll bars we use every day only work well because we are so used to them. Something like the iPhone's flick-based scrolling interface offers a much more natural user experience that plays off of user's conceptual models of the physical world, and are thus accessible to a wider range of users. I am excited to see how software will change as we move away from mouse and keyboard as primary I/O devices.

Bruno Mehech - Feb 11, 2008 02:17:40 pm

First I'd like to say that I think that this article is too wordy and introduces too many unnecessary terms most of which make very little sense (and the diagrams didn't help at all). Also I think that David brings up a good point. It seems that right now we seem to have reached a pretty good level of directness using a mouse and keyboard as input. For things that aren't as direct as they could be we have gotten so used to them that they seem very direct to us. Thus it might seem that this article is outdated, but it is very far from being so as new methods of input such as touch screens and motion sensing devices become more common and which will hopefully lead to even more direct interfaces than the mouse and keyboard can provide.

Richard Lo - Feb 11, 2008 02:51:50 pm

Seems like most of the previous comments have touched on my general feeling of the article. Most everything with a decent user interface these days and used by the common public is considered to be direct manipulation. Whether it be the OS, text editing, web browsing, or email checking, many wide-spread applications allow the user to perform complicated functions with the click of a button and easily manipulate data on-screen however they wish. This concept of direct manipulation may not necessarily be obvious, but for the experienced computer user these days its almost a fundamental idea learned just by playing around with modern technology.

Adam Singer - Feb 11, 2008 03:38:59 pm

Cromulent paper indeed. It really embiggenned my soul.

Anyways, though the paper was written over twenty years ago, it seemed to be describing something that is currently revolutionizing the way we view user interfaces: the idea of "touching" your data. With the advent of the iPhone, it seems the industry is trending toward interfaces that more directly manipulate data, pictures, videos, etc. This paper certainly described what it means to "directly manipulate" an interface, and was prophetic in predicting the interfaces of the future. Interfaces today are more and more resembling their science fiction movie counterparts, and users are demanding more novel ways to interact with their data. We as user interface designers must respond to these industry trends and try to make our interfaces seem more "direct" or natural.

Though the paper was a little tedious to read, it was an interesting insight into the realm of direct interaction.

Daniel Gallagher - Feb 11, 2008 10:01:33 pm

In the interest of not directly restating previous comments, I'll point out the section that was most interesting to me: where the reading describes how users of a "well-designed model-world interface willfully suspend belief that the objects depicted are artifacts of some program" similar to how an audience at a masterfully acted play may do (p10). I found this a much better description of how users mentally connect with the use of a well-designed UI than "they get really into it", which was my previous best. Yes, the paper is dated, but perhaps more because it points out such fundamentally true interaction ideas that we(I) feel so comfortable with they could have been around forever. As a matter of fact, the above quotation from the reading and subsequent discussion makes me wonder if twenty years from now students will look at our user interfaces and dismiss them as primitive compared to new technology in bringing direct engagement to new levels. Perhaps with advances to virtual or augmented reality, perhaps with other new technologies, interfaces appear on track to become so personal to the user that the suspension of belief may become trivial- how cool would that be?

Jonathan Wu Liu - Feb 11, 2008 10:23:34 pm

The thing I thought about in the section of the problems with direct manipulation was the statement that "if we restrict ourselves to building a [direct manipulation interface], we will miss the most exciting potential of new technology". It argues that we will not think of new ways to interact with the domain. I just don't think this is a good argument because the argument is not valid in the perspective of the designer, but could be valid in the perspective of the consumer. Of course the consumer will not think about new ways to interact with the domain. The consumer just wants an easy way to finish tasks. A competent user interface designer consciously pursues new ways of creating new direct manipulation interfaces even though he is exposed to existing direct manipulation interfaces. I concede it is a caution to be wary of, but I feel like a person is not a user interface designer if they don't analyze and criticize existing interfaces.

Michelle Au - Feb 11, 2008 10:46:49 pm

Hutchins, Hollan & Norman's point about automated behavior is very important to consider when designing good interfaces. The idea that automation does not actually reduce semantic distance is one that many designers overlook when developing a new interface. Many times, designers use their own experiences and expertise to design an interface, already taking advantage of their familiarity with the execution of the task. Then they get the feeling of directness through automated behavior; however it is not truly directness. This is where other design ideas discussed in previous readings come into play, especially the emphasis on customer/user feedback and interaction early in the design phase. An outside customer that does not have the same background as the designers can evaluate the directness of the interface more reliably than the designers themselves.

Hannah Hu - Feb 11, 2008 10:52:52 pm

While true that the article was written more than 20 years ago, and vast improvements in interface design have occured since then, the guidelines outlined in the article still holds true today. There is still more improvements to be made. One could argue that the mouse, for example, is almost the epitome of HCI, but touch-screen technology has proved it inadequate or inefficient. Even before the propagation of that technology, stylus-controlled interfaces, such as those used for PDAs, graphics tablets, adn tablet PCs, mades use of more natural manipulation than the mouse can ever achieve.

Of particular note in the article is the fact that frequent use can lead to the illusion of directness. We may take the keyboard and mouse for granted, but that familiarity comes form practice. Not everyone has this privelege, however, and to make matters, the ubiquitous keyboard-and-mouse combo does serious carpal neural damage. So not only do we have to consider directness, we must also address potential physical changes introduced by a new interface.

Fan Yang - Feb 11, 2008 11:05:22 pm

This article seems to deal with what is currently very normal in user interfaces, the ability to directly interact with the information that is available. It deals with how powerful it is to let the user see what they are doing, making it more intuitive to control any devices. This type of ability is seen in PDAs with the stylus and also in the devices like the iPhone with touch screens. Direct manipulation is very powerful because it is in human nature to work that way, from when we start out as little kids with building blocks and manually sorting them to when we become adults and start sorting files. The idea that is described in the article is now common place in many devices and is considered part of great UI design.

Zhihui Zhang - Feb 11, 2008 10:21:45 pm

I agree with most of the previous comments: Hutchins, Hollan & Normangoes through a very indirect way of talking about directness.

Like Brian, I was also reminds of tools such as LabView and Logisim when I read the article. Particularly, I think an important factor in whether someone finds these tools to be helpful or "frustrating" is their level of prior experience and the amount of detail involved in the task. For example, when I took 61C, i was exposed both the graphical Logisim as well as the Verilog HDL. While at first I found the graphical interface of Logisim to be intuitive and easy to visualize, i soon became annoyed at how long it took to perform relatively simple tasks compared to Verilog. Likewise even in looking at document editors, while 'direct' interfaces such as those found in Microsoft Word and OneNote can be intuitive and easy to use, it is often difficult to specify exactly what you want the program to do and professionals today still use LaTeX. In the example Hutchins, Hollan & Normangoes gave, while it may be simple to have the user 'circle' groups of dots, such tasks become more complicated when a certain level of detail is involved (if the user only wanted to select points whose x and y coordinates are multiples of two for example). In situations like this, writing code still seems like the better way to go. So even though new input methods such as touch-screens and voice recognition will innovate and improve the user experience, it is unlikely that classics like the keyboard will go away.

Benjamin Sussman - Feb 11, 2008 10:40:36 pm

While it has been said before, it seems so relevant to both the paper and the class that I simply must mention it as well: The iPhone. Touch input has such significantly different affordances than other inputs that new and interesting interactions are being used to interface with data, and the sole reason whey they are interesting and intuitive is because of their "directness". Because of the natural physics of the world around us, touching something and then moving most often moves the object with us (a paper on a table for example). While this may be a learned manipulation technique, it is learned at the earliest years of our lives, and thus has become what we consider "direct". Hutchins/Hollan/Norman states that: "Directness is an impression or a feeling about an interface", and it's lack of a concrete definition is what makes it so hard design and implement fully "direct" interfaces.

We have come a long way in the 20 odd years it's been since the paper was written and products like the iPhone and Tablet PCs are allowing for users to experience what Hutchins/Hollan/Norman refer to as "Direct Engagement" by seeing the effect of their actions immediately and (in my opinion more importantly) at the epicenter of their action. By contrast, a mouse moves the pointer on screen immediately, however the mouse is strictly removed from the screen, and is limited in the on-screen space it can reside in while not at all limited in the 3D world outside. These major differences are what place touch-interfaces closer to the "Direct Manipulation" interface than older interfaces like the mouse or the drop down menu. With this new interface however, we will need to change the method of data input and output, drop-down menus don't make sense in terms of a stylus on a tablet, but are perfectly reasonable with a mouse. Instead, a button requiring only a single tap with the stylus would make more sense, and then a tap out of the region of the drop down could make it disappear. These kinds of subtle changes could make a world of difference for the user, and thus a significant amount of design, development and, most importantly, testing with end users is necessary during this important transition. To sum it up, in my opinion touch interfaces are the next extremely important step in what hopefully will be a continual march towards more "direct" user interfaces.

Johnny Tran - Feb 11, 2008 11:20:25 pm

The article brings up a good point about direct manipulation interfaces: while they are adapted to a domain, tasks outside of that domain are either impossible or hard to perform. One example that the article gives is with conventional programming languages. The article was written in 1985; there did not exist a direct interface for programming tasks then, and there does not exist one today. Some do exist for very limited programming domains, which brings us back to the main flaw of direct manipulation interfaces: a lack of flexibility.

It can be argued that the strength of conventional programming languages is in their abstraction. Higher-level languages don't get more concrete and closer to the task at hand; rather, they get more abstract and allow the programmer to do more things more easily, not less things more easily (which would be the case for a direct manipulation interface). Direct manipulation seems like a path towards the more and more concrete. But concrete is solid and inflexible, while an ideal programming language must be formless and adaptable.

Virtuosity and being able to do more with a system than its designers intended is also a highly-desirable characteristic. No one system can accommodate everyone's needs, and it is better to design the system such that unforeseen extensions are not prohibited. It is even better to allow the user to easily extend the system him/herself. Directness, as the article states, flies in the face of this abstraction and flexibility. The challenge of UI designers will be striking the right balance between directness and capability.

Lita Cho - Feb 12, 2008 12:05:53 am

I believe Hutchins, Hollan, and Norman had progressive ideas back in 1985 with user interfaces. Currently, a lot of operating systems are being implemented with a direct manipulation with pictures and interaction. They even mentions the drawbacks of direct manipulation with are similar to the drawbacks of current interfaces. I highly agree that directness does not equate to ease of use, such as LabView. LabView has a very direct manipulating interface for programming. However, the program has so many functions and options cramped into the menus, as well as hidden editing tools, that it makes the program hard to use and confusing for certain people.

The two forms of distance between the user's thoughts and goals, semantic and articulatory, were very interesting to read about. The articles critiques about how UNIX made to be simple and general so people could add functions of their own. However, the additions to the OS cause it to be more confusing and most of the functions are hidden from the user. I also see lot of direct manipulating user interfaces going for that direction. For example, the remote has a very direct user interface. However, with all the buttons forced into a tiny space, the user becomes confused due to the hidden functionality.

Randy Pang - Feb 12, 2008 12:35:28 am

First off, to beat a dead horse, I agree that this article was too indirect in stating the obvious and though it may have been revolutionary at the time, it was quite boring at the present (I am also still completely oblivious to what is going on in the first diagram).

In response to Hannah, while I do agree that touchscreens are gaining traction quickly (Tablet PCs, iPhones, Microsft 'Surface', etc.), I think you're overlooking the "epitome of HCI" a little bit. For some interfaces, touchscreens do provide a more natural environment and better feedback (try for example, drawing a picture with your mouse). But there's many uses of a mouse that will prevail beyond the touchscreen wave that's upon us (they're not even there yet either, for example you can't even do a fundamental task like copy and paste on your iPhone). First is that touchscreens provide a 1:1 mapping, whereas a mouse can provide an arbitrary mapping (i.e. if I want to press that button 2 inches away on my iPhone, I have to move my hand 2 inches, not so bad, right? But if I want to press that icon on my 22" monitor that's 2 feet away, I may only have to move a few inches with a mouse, but the full 2 feet with a touchscreen -- not to mention my mouse is right next to my keyboard, and my screen is 2 feet away). Second, in terms of gaming, I can't imagine anyone using a touchscreen or stylus type deal to play certain types of games like FPS's and RTS's. This may be partly due in part to the familiarity that the article talks about, but for some reason I really just can't imagine someone quickly tapping a screen to fire some rounds off. Some things are more natural (like the photo flipping in the iPhone, which wouldn't make sense with a mouse), but other things, not so much. Finally (though I'm sure there's more, this is probably the most important advantage), the mouse does a lot more then pointing at things. Newer mice have multitudes of buttons (the logitech I'm using right now has 12 different 'inputs') which makes it great for controlling multiple things (the most useful thing I control with my mouse is the forward/back and volume control on my music player. it's extremely nice to have. linking the mouse to expose/program switcher type deals is very convenient as well). However, even with the older standard 2 button scroll wheeled mice provides leaps and bounds more functionality then a mere pointing device (if you've ever used the standard 1 button apple mouse, you'd understand). You could argue that in the future, stylus's will come with buttons on them and they'll be just as good (though sole touchscreens will never be able to replicate this, though they try through various gestures). I think this is a possibility, but for now my familiarity and fond memories say the mouse won't be getting eclipsed any time soon (if anything eclipses it, it won't be because touchscreens are so much better as an input medium, but rather because there is a shift to mobile computing, where touchscreens make more sense over mice due to size and portability constraints in addition to usability [you can't use a mouse when you're holding your cellphone with both hands]). For the record, I've always been a piano man myself (the elegance, feeling, and passion in spite of it's obvious directness constantly amazes me).

William tseng - Feb 12, 2008 08:59:03 am

There were a couple of points in todays reading which I felt were noteworthy. First, the concept of gulf of evalutation is essentially just another word for the "feedback" concept we learned from previous lectures / readings. The button on the elevator lighting up is an example of this. The key difference and important thing to note is that we can not just throw random feedback at the user, and that it is the responsibility of the system designer to do some parsing of the data and present it in a usable form for the user. The example used in the reading was of the arrow signifying increase or decrease in water level. In addition the system in that case further did processing of feedback for the user by making the arrow large or small to depict how fast the water level was rising / lowering.

The portion of the reading about how automation does not equate to directness of a design was particularly relavent. In industry people are always fighting over emacs vs vi vs mouse based text editors. Really all of them are not necessarily easy to learn but all become powerful to the familiar user. I think when looking at other applications for ideas we as designers must learn to differentiate between something that is easy because our user is familiar and things that are actually easy because of the interface of that existing application. We must not be swayed just because the user we are studying claims something is easy and we must be objective in our analysis of existing interfaces.

Katy Tsai - Feb 12, 2008 11:25:36 am

If anything, I think this article serves to further emphasize the importance of user testing when it comes to UI design. We must really understand the needs of our user before we actually distinguish how to mitigate the semantic and articulatory distance between the user and the system we design. I think with any new product or system, there is always some sort of learning curve that a new user must overcome. However, more and more today, we are learning to draw from products we already use and have developed some sort of expertise in and bringing it into new systems that we design each day.

In general, finding this balance between the system and the user will continue to be an ongoing struggle. While we need to cater to a user's needs and decrease the learning curve, we do need to ensure that some type of boundary exists. When the writers mentioned the complexity of the Lisp language and the UNIX operating system, it reminded me of the recent trend in open-source business models (Facebook apps, and even Google's Android). Sometimes we get carried away in customizing functions to the point of excessiveness, and it is crucial to remember at the core, what each user's needs include.

Jeffrey Wang - Feb 12, 2008 11:42:36 am

As mentioned above, I agree that some examples provided in the paper may seem a bit outdated because it was 1985. The article was a bit verbose in describing its concepts. We have made drastic improvements since then, but I still believe the author's message is true and we have a lot to improve on. The author breaks directness into two categories: distance and engagement. Distance aims to lower cognitive effort and engagement offers qualitative feeling that one is directly engaged.

I think there are still a lot of improvements to be made. For example, the computer is still single-touch by a mouse. It would seem more direct with we could access multiple things on our desktop with multiple fingers. The experience is still distanced and not very tangible. One way that the author suggested tob ridge the gulf between the intentions of the user and the specifications is to have higher-level languages. I believe this concept can be applied in a broader sense beyond programming languages -- just improving interfaces to better fit an user's familiarities. It is beneficial for the user to just feel more natural. On the other hand, one might argue that learning a more complicated interface can lead to a more efficient or effective execution of products. I think a good solution would focus on exactly what kind of user the software is targeting, and tailor it accordingly.

Harendra Guturu - Feb 12, 2008 11:32:35 am

I am not sure I understand the concept of inter-referential I/O as described by the example used in the paper. I feel that file listing systems do allow direct manipulation. In a text-based system the name is the representation of the file and applying commands just as cd and rm to it will manipulate the file. In a GUI based system the representation is the icon and how we click on the icon is the manipulation. I feel operating on the names of the file does manipulate the files unlike the claim that it does not in the paper. Perhaps I am not understanding the subtlety between the name and providing the instance of the object to manipulate.

Gordon Mei - Feb 12, 2008 10:55:30 am

While direct manipulation invokes references to WYSIWYG desktop interfaces or touch-based computing, let's not forget the increased appearance of direct manipulation in the web interface. Hutchins-Hollan-Norman emphasize that maintaining rapid feedback in terms of the behavior of objects maintains an illusion that allows a feeling of acting directly with objects. The surge in popularity of AJAX techniques on the web has allowed smoother-feeling 'real time' manipulation features like drag and drop in place, whether to more intuitively relayout tables or page elements without a control panel of checkboxes and multiple page reloads, or whether to drag a product icon into a sidebar to add to the shopping cart. It engages the user, as it feels much more like a familiar interaction with the physical world and its objects, for the objects of the real world aren't shuffled around with the equivalent of a panel of toggles and switches.

Or digressing, we perhaps use translucency to hint to the user that the behavior of a page element has changed - perhaps that it is currently able to be moved, or that it's been active hovered over, or that it's inactive or ready to be deleted. This type of cue is somewhat similar to the Hutchins-Holland-Norman example of the meter levels becoming more semantically direct when rate change arrows proportionally sized by extent of change reduces the mental computation otherwise required to monitor too subtle incremental changes in the water level over time. Linking in a circle back to the web interface, this is akin to the "tag clouds" where text tags of articles or blog entries are the larger typeface-sized ones in the grid/cloud if they're more popular. This again reduces some mental computation in sifting visually through the plot.

All of these together are part of the metaphor of interfaces as the model world, and part of a long goal of developing abstract formalism to interface with the world.

Edward Chen - Feb 12, 2008 11:26:34 am

I must admit that the reading seemed to spend a lot of time trying to explain what they meant, yet still being incredibly unclear and vague about what they were trying to explain. I suppose that is acceptable for a paper from 1985, since the idea of direct manipulation was unique to that that. One important point from the paper that I found rather interesting was that, despite the superiority of direct manipulation that they mentioned, they still pointed out the disadvantages of direct engagement and applications in which direct manipulation would not work.

Even 23 years later after the article has been written, this still holds true. Applications such as programming just doesn't seem to be fitted for direct manipulation. Like they said, things that are repetitive should not be done via direct manipulation otherwise you'd be manually have to repeat your manipulation. However, at the same time, direct manipulation has become rather widespread in applications that afford direct manipulation, especially in the interfaces of mobile devices.

Robert Glickman - Feb 12, 2008 11:53:04 am

Contrary to the past readings for this class, I found this article to be particularly mundane and lacking true insight into today's issues. It felt like a rehashing of the idea for every good interface I have used since I was born. Talking about the gap between user goals and how the interface satisfies these goals was old news.

However, there were a couple interesting tidbits in this document, particularly towards the beginning. The initial explanation of direct manipulation caused me to think about high-level, graphical programming languages which I was first introduced to lately. Certainly, to develop a language so high-level, that a typical user with little or no programming experience can develop powerful, custom functions and programs, is a powerful concept.

Henry Su - Feb 12, 2008 11:55:57 am

I found it notable that even though the assigned reading was published over 20 years ago, it still brings along ideas that are found true to this day. For example, Hutchins, Hollan & Norman noted that even though direct manipulation interfaces are powerful for some purposes, it won't replace all "coding", so to speak. However, I do find that for many applications on the general user level, a direct manipulation interface is a superior idea. For example, during high school, there was a proliferation of text-based games on graphing calculators. Though they were funny, the user does feel somewhat detached, because instead of using graphics to show what happens, the game simply tells the users in text what happens. Also, in the case of text editing, there is a substantial difference between the "GUI" versions and the text versions. The GUI versions certainly seem much more natural and easier to learn, because you can actually point your mouse to a menu, select text, etc. However, like the article mentions, users who become used to the text-based interfaces can do many tasks on impulse. This, however, is caused by practice, not by initial intuitiveness. Of course, even today, some people prefer non-direct manipulation interfaces, because (at least in the case of vim, etc) typing commands may be faster than pointing the mouse.

Zhou Li - Feb 12, 2008 12:20:34 pm

In direct manipulation, all the “programming” and commands are done graphically in the interface, allowing users to have a “what you see is what you get” feeling. Since users interact with the interface through physical actions such as connecting objects or clicking on buttons, the impact on the objects can be immediately visible while having close representations of the intended operations. In order to decrease the distance between user’s intentions and operations required to get to the final results, interface designers must match thoughts and goals of the user to the commands and mechanisms of the system to reduce cognitive effort in the process. Unlike the conversation metaphor used by most interfaces, the model-world metaphor gives users direct control over objects in the system instead of manipulating language that describe the objects. The trade off of reducing semantic distance by introducing higher level language for the users is that the closer it represents people’s thinking process, the more specialized and more level of complexity between the top lair and bottom lair, making the system harder to maintain and the interfaces harder to be unified.

Megan Marquardt - Feb 12, 2008 12:14:12 pm

This article pointed out several things in interface design that I just thought was natural and elementary. Only dealing with interfaces that rely heavily on graphics and manipulating icons as a direct way to complete tasks, I didn't really think too much about the history of how this trend developed and the analyzation of why it feels "direct" to the user. The SketchPad example they illuminated earlier on in the article was a good reference point that made me realize that the interface highly relies on its interaction with the user's goals, and how the user recieves that information. As opposed to the conversation model, SketchPad used direct manipulation of graphical objects to complete tasks. It seems like the type of programs that would be hard to implement using this direct manipulation method are programs that are conversational themselves, a word processor program, for example. It seems very easy to apply this method to a graphical program, like a photo editting program or image drawing program.

Maxwell Pretzlav - Feb 12, 2008 10:48:12 am

The ideas in this article seem very relevant when the end goal of a product design is for the user to feel comfortable with the software even when unfamiliar with it. Additionally, many of the abstractions Hutchins et al. describe allow certain types of data to have complex manipulations applied to them very rapidly -- however the possible manipulations must be heavily limited. What strikes me as an unexplored aspect of this discussion is when user comfort and 'cognitive distance' get in the way of being fast.

For most consumer applications user efficiency is unimportant -- only the user's comfort matters -- but in business applications where employee time directly equates to money, the field is very different. I can imagine a number of applications (such as text editing) where the "direct manipulation" interface is easier to use and makes the user feel more comfortable, but where a well-trained user is much more efficient with the more indirect interface. The vi example from the text illustrates a good point -- while dw might be an awkward and unnatural way to delete a word, if spending a few days training an employee to use a very efficient but less user-friendly interface saves ten days of repetitive work per year, then the more indirect interface may be a better choice.

Jason Wu - Feb 12, 2008 12:20:52 pm

This seemed like a pretty abstract and technical article, with diagrams and jargon filling up 28 pages of material. However, I feel like much of what was written is in fairly common practice in UI today. 20 years down the road, we've come up with a fair amount of GUI with these concepts of semantic / articulatory distance. The folder system, and the rising of the touchscreen/tablet PCs, are both examples of directness working in UI. The fewer steps between using the interface and achieving what you want, the better. However, ultimately the summary of the article for me was something fairly obvious: keep the interface intuitive and simple; don't introduce any unnecessary complexity in performing the user's tasks.

The only other criticism I have is the article's inflexibility with what a "good" interface is. It fails to address that different levels of control in an interface works with different people. Sure UNIX's command line can be rather complicated, but for a large number of computer users it is much preferred over the more "direct" mouse controlled GUI.

Diane Ko - Feb 12, 2008 12:18:25 pm

The main difficulty I saw with this article is that I tend to forget how much technology and visualization has changed in the 23 years since this article was written. Just yesterday I was talking to a classmate about the evolution of technology and operating systems in just the time span of our lives. The article points out many of the important characteristics of interfacing and interaction that are still applicable today. It's also important to recognize that the drier language and approach is related to the fact that this paper is relatively old and set during a period of technology where not as many people were using computers as they are today (especially general users). A lot of the mentioned points in the article seem like no-duh points to us now because we're so used to that idea being standard.

Cole Lodge - Feb 12, 2008 12:39:57 pm

I know I am not the first to mention this but it is very important to note the age of this article. It has obviously been well accepted by most software based interfaces. I also think that the influx of this form of interface is due to the ability of computers to support the interface not because of the paper. The idea of a directly manipulatable interface has become common knowledge and general accepted. The problem is that, in most cases, a static simple interface is far less resource intensive, yet as time has progressed and performances has become less of an issue, far more directly manipulatable interfaces have been developed. So in short, this article did not bring anything new forward; instead, it only showed where everyone intended to go once the performance caught up with development.

Yang Wang - Feb 12, 2008 12:51:54 pm

This article really gives me a feeling of how much we developed our electronic systems in 20 years. One important thing though, the "good" interface in this article is more focused on common user. To me, it seems the shorter the learning curve the less powerful user can become by the end. Things that are really easy to be learned often gives less flexibility to the end when user really "mastered" the product. Command line versus pure mouse control is an example. The Wii console Nintendo just came out with is a good example too. It may be fun and innovating for a new game player and much easier to learn than the traditional controller; however, it offers a much less accuracy. For a hardcore player, Wii's idea only sells for first few hours. It seems the interface sometimes trade with easiness and the usefulness. The target user group is probably the most important thing here. With it, we can decide how powerful we want our product to be, or just how simple it should be.

Jeremy Syn - Feb 12, 2008 01:22:17 pm

I thought that a lot of what they were saying makes a lot of sense and the reason why it seems they are the stating the obvious is because today, many of the good interfaces follow their guidelines. One of these I noted was the fact that the interface should be easy to learn to use, without the user having to struggle too hard to get the hang of the interface. Comfortability is extremely important when designing an interface because after all, what makes a good interface is the ability to get quickly familiar to it and not having to struggle too much with it.

Joe Cancilla - Feb 12, 2008 01:27:18 pm

I believe that direct manipulation is a great way for novices to interact with a system, but can be considered tedious and limited to more advanced users. Novice users, for example, find the command line to be quite intimidating, whereas expert computer users tend to feel that command line allows them to get things done faster and more elegantly.

Andrew Wan - Feb 12, 2008 12:58:30 pm

The interface as a language is an interesting, if abstract, metaphor. User interfaces, like languages, provide a way of communicating information across some "gulf". In a programming language, an API defines exposed functionality. Similarly, a device's interface provides access to its features. The article is long-winded in its analysis of direct manipulation interfaces in general, and many of the strongest points seem fairly common-sense: the need for continuous workflow (inter-referential screens), matching user intentions, etc. Nonetheless, given the paper's age, the author seems to have forecasted the entire direct manipulation issue very accurately. I would guess that over time, these kinds of interfaces will become much more commonplace, not only as a result of technological advancement, but also of better "directness".

Jiahan Jiang - Feb 12, 2008 12:39:29 pm

I don't think the issues the article discusses is as applicable today. The direct manipulation the author promotes stresses simple interaction, continuous feedback of action results, as well as role-oriented interactions. I think in today's world people have been exposed to various types of media and are much more patient and sophisticated in their interaction with technological systems. The "instant reflection of user actions" methodology is, in my opinion, not as crucial as the article deems.

Timothy Edgar - Feb 12, 2008 01:50:26 pm

It was a bit ironic that the paper spoke of directness yet read like an academic paper (which I suppose is a means to be precise, but not necessarily direct). Granted it was a bit old of a paper (citing Sutherland's works!), it did have some insight in both the conversation and model relationships. All I could think of was MATLAB vs LABVIEW. EE20 was resigned in LabVIEW, which caused a lot of issues since he has a much higher learning curve. It follows the "direct manipulation" principles, however it abstracted it in a way that it took more work to get what you wanted out. Perhaps LabVIEW keeps it at a high level that you need a huge palette, which the article references. However, I just couldn't get my head around the idea of "direct manipulation" due to the failures in LabVIEW, trying to do a very technical task inefficiently using a graphical dataflow model. It works in some cases, but it isn't a catch-all generalization. It was a bit amusing that on the last page it mentioned that difficulty and directness are different beast, and that difficulty is due to the domain, which may be true.

Kai Man Jim - Feb 12, 2008 02:13:09 pm

This is a great article; it gives you many pioneer thoughts which lead to today's development. But since this article is kind of old, many of the idea are already outdated, and what we have now is the idea that built on top of it when deep complex application. Therefore, I think this article is a bit outdated.

Jeff Bowman - Feb 12, 2008 12:23:15 pm

The quote I find most interesting:

…all the "programming" is done graphically, in a form that matches the way one thinks about the problem.

At some level, I inherently reject the idea that a graphical model can be produced that matches all users—or, in some cases, even most of the users. When applied to certain types of modelling—DirectShow filters in Window Graph Editor, for example—it makes perfect sense. However, not all procedures lend themselves to this model, and even for those for which an accurate conceptual model could be constructed, I think it's a generalization to propose that this is any different of a conceptual jump than any other form of programming. I do understand the point about it being less arbitrary than most text-based programming languages, though.

I really appreciated the allusions to suspension of disbelief in the world of theater and acting. If you look at it one way, that's what user interface design is: The same type of concessions allow the user to work with a representation of a file [rather than bits] as they would to watch actors [rather than the characters incarnate]. In fact, certain interface systems (notably my favorite, Jellyvision's Interactive Conversation Interface used in the You Don't Know Jack series of games) employ literal suspension of disbelief to interact with their users.

Pavel Borokhov - Feb 12, 2008 12:53:24 pm

The directness of interfaces is something that is very appealing to a large audience of users, though it seems that it would mostly benefit those who are not yet proficient with conventional interfaces. For example, the iPhone's touch-based interface is in many ways more direct than the interfaces of most cell phones and even maybe full-size computers. At the same time, the "pinching" gesture so frequently touted by Apple does not seem to be extremely useful to most people I talk to who have at least some experience with computers. Perhaps this is more reflective of the frequency of the task at hand - for example, zooming into and out of a photo on a 3-inch screen is not something most people do frequently (generally, smaller screens are used on cameras to get a rough idea of the picture, and any zooming is performed on a larger, computer screen of 10+ inches). Perhaps, as the "gesture vocabulary" of the touch interface expands, these interfaces will have greater relevance in today's world.

Two important things should be noted, however. First off, it seems that no interface can be "100%" direct because it will always need to use some sort of "interaction vocabulary" to allow users to interact with the system. This vocabulary could be representative of things that we do in the real world to manipulate objects (for example: grabbing a file icon and throwing it off the screen to delete it), but they might not be universal among users (perhaps, "crumpling up" the file would make more sense to some users). The closer the vocabulary is to the way we normally think about things, the more direct the interface will be, but determining the "normal way of thinking about things" is something that might not be inherently obvious or easy to accomplish with a diverse group of users. Second, as mentioned in the reading, non-direct interfaces have the benefit of being able to express abstract ideas and account for errors in our tasks. As an example of the latter case, I like the fact that my desktop icons are automatically arranged alphabetically and do not really want the "flexibility" of having to arrange the file icons by hand for each file that gets placed to the desktop. It's bad enough that I have to do it on my physical desk; I'd rather not have to go through the ordeal on my virtual one too. Of course, a hybrid solution to this issue would probably make the most sense: allow the user to quickly organize desktop items by placing them in a certain order (and keep them that way), but also give the ability to turn this option off and give the user freedom in clustering related groups of files in freehand fashion (then again, perhaps the real solution to that is to just create a folder on the desktop and place the files into it).

In closing, I'd like to present this video of multitouch demos by Jeff Han and point out that the model-world interface is only usable by sighted users, something to keep in mind as accessibility becomes a more serious concern for user interfaces in computing.

Yunfei Zong - Feb 12, 2008 02:39:05 pm

The authors' discussion of high level languages seems a bit outdated. Specifically, the example of UNIX as a huge system that required endless reading of man pages to use correctly, or that users needed a large grasp of the system to execute small parts of it. The best way to learn a language is to do a project using that language. As such, when people need to learn UNIX, they find something they want to do with it, then learn the commands they need to do it with; they don't learn the whole system and then apply what they learned. Helpful tools such as Google and Wikis makes it much simpler to learn new commands or to look for a specific command. A metaphor to this is like a feature-rich mobile device. Just because it's equipped with tons of software features doesn't mean that the user needs to use or even know about the esoteric ones; the user simply uses what he needs to get the job done.

Tam La - Feb 12, 2008 02:28:23 pm

Direct manipulation is a style of Human Machine Interaction design which features a natural representation of task objects and actions promoting the notion of people performing a task themselves not through an intermediary like a computer. A good example that help me to understand direct manipulation principles in contrast with the intermediary style of interaction is travel in a car. With direct manipulation, you drive the car by manipulating the steering wheel and pedals. The car responds immediately to your actions, and these responses are immediately evident. If you are making a mistake such as turning too sharply, you can quickly recognize this and perform a corrective measure. With an intermediary style of interaction, you sit in the backseat of the car giving a stranger directions. Further, imagine the stranger possessing poor interpersonal skills and having a limited vocabulary. You've lost the feel for the road and you don't have a direct view of where you are going. Worse yet, you have to rely on a stranger who, if they don't receive explicit directions using particular phrases in a fixed order, idles in the middle of the road or takes you to unfamiliar places from which you don't know the way out.

Andry Jong - Feb 12, 2008 02:43:38 pm

I find this article by Hutchins, Hollan & Norman to be extremely hard to follow. Even with examples they chose, they do not seem to make their point clearer. Also, if we see programs that we use nowadays, they already try to use direct manipulation interfaces as much as they can. Icon that shaped like a trash can is a place where we throw away stuff that we do not need anymore. And the response of putting things into the "trash can" can be seen instantly (i.e. the document will disappear from the previous container.

Although this article is very hard to follow, I like the fact that Hutchins, Hollan & Norman, at section 6, states the trade offs of creating direct manipulation interfaces; how it always depends on what kind of task we want to do.

Roseanne Wincek - Feb 12, 2008 02:32:58 pm

I totally agree with a lot of you, for an article on "directness" this was awfully indirect. I thought it was verbose, confusing, and too long. There was definitly a lot of distance between me and this article. When reading this article, I immediately thought of labview (and I see that some of you guys did, too). When I first used labview, I had never really programmed before. I thought that it would be easy to use, because you didn't have to learn any code and could represent everything graphically. I think that labview is a mess when you try to do anything that isn't extremely simplistic, because you have boxes and wires everywhere. However, I think what is important here (and still today) is that interfaces should be intuitive. The more you have to think to figure them out, the harder they are to use.

Ravi Dharawat - Feb 12, 2008 02:49:49 pm

This article has a few interesting ideas. Of course, the time it was published is an issue, and I do agree with many of the posters that some terminology was unnecessary, and that led to a much longer document than was necessary to convey its idea. But the balance between how much processing is done on the user side and how much is done on the machine side, that is, the balance between how much the user must learn or wait and how much the machine must emulate something the user is already familiar with, is an important consideration in the development of software. And as much as it is an (sic) olde idea, it is being reapplied constantly to greater effect, from the desktop, to the palm stylus interface to the multitouch interfaces appearing in newer products.

Brandon Lewis - Feb 12, 2008 02:51:53 pm

I like this article because it gave terminology to features of UI design that I have experienced but been unable to describe: namely the concepts of semantic distance and interface languages. However, I think the claim that all interfaces have a "language" is a little dubious. I don't feel that I'm using my linguistic faculties when I'm driving my car. Turning the wheel to follow the contours of the road is a learned reflex reaction that I do without much conscious thought (unless I'm going very fast, or the road is very narrow). It is a continuous process that does not break down into discrete utterances. Even discrete actions such as shifting are guided by fuzzy logic, and modulated according to road conditions. It is more like singing in a choir than holding a conversation.

However I can see that the actions taken in a drawing or image manipulation program would constitute a language: you could parameterize every action taken by the user as a textual command. The interface has modes and submenus which correspond to productions and subproductions in languages described by context-free grammars. Moreover, an image manipulation program illustrates the concept of the input and output language matching: the output of one operation can become the input of another. The UI simply serves as an easy, intuitive, or _direct_ way to manipulate the sequence of statements in the input language. The output of any operation can be fed as the input to any other operation.

Paul Mans - Feb 12, 2008 02:25:10 pm

Although my experience reading this article was similar to that expressed in a number of the other comments (it was more of a chore to wade through then some of the other articles), I still thought there was value in reading it. The authors succeeded in establishing a language with which to discuss the merits of computer software interfaces and a unit, directness, with which to measure them by. Some of the principle terms and techniques the authors suggest are listed as follows:

  • The number-one determinant in "directness" is the amount of cognitive resources that a user has to commit to the accomplishment of a task.
    • This seems like an excellent principle to shoot for across all interface design be it in software or the physical world.
  • "The systems that best exemplify direct manipulation all give the qualitative feeling that one is directly engaged with control of the objects--not with the programs, not with the computer, but with the semantic objects of our goals and intentions."
    • This falls right in line with the value system that prizes interface whose users have to exert the least amount of cognitive effort--an intuitive example of this is the effort it would take to play a video game in which you are controlling the movements of a character who is driving a car verses a video game where you are directly interfacing with the controls of the car.
  • The authors use the concept of "semantic distance" to describe more precisely the gulf that often arises between the computer's interpretation of what a user has expressed in the interface language and the idea or action that the user was trying to express.
    • Executive distance is the measure of the semantic distance between what the user attempted to do and the commands that were actually executed.
    • Evaluative distance is the measure of the distance between the user's conception of the result of his or her commands and the actual effect of his or her commands.
  • One theme that recurred throughout the article was the always present trade-off in interface design between higher level languages, which make tasks easier to specify, and lower level languages that are more general for any action.
    • One solution to this problem (which is often echoed in predictions of what future role computers will have in society) is to have lots of very specific solutions that are specialized to solve individual problems.
  • One argument the authors make for the value of good interface design is the notion that interfaces can affect the way a user thinks about the domain of the software itself in the same way a linguistic grammar can be deterministic of how an individual views the objects or ideas it describes.
    • While I believe this is probably the case, it is an idea that is difficult to measure and thus it doesn't provide much guidance when designing our own interfaces.
  • Another analogy to a concept of linguistics that the authors extend to interfaces is the use of onomatopoeias.
    • I think this is a very nice idea and interfaces that employ it I expect are tremendously successful, but I suspect it is actually quite difficult in practice.
  • One of the more concrete suggestions the authors provide for improving interfaces is to improve the form and the speed of feedback to the user.
    • To bridge the gulf between executive and evaluative semantic distance the authors say that having the "...same object as both an input and output entity is essential to providing objects that behave as if they are the real thing."

These were the main principles I took from the article and the most useful techniques I found for designing and evaluating my own interfaces.

Mike Ross - Feb 12, 2008 02:59:29 pm

This article essentially dissects and formalize what seems like some otherwise basic ideas. Maybe it's a testament to the importance of the article's point that most of us grew up around technology which does its best to create an environment model type of interaction, rather than the conversation model. Furthermore, it seems like tradeoff between learning time and flexibility is one of the first issues tackled when designing any sort of program. I also think it's hilarious that the author mentions the idea of graphical interfaces for programming replacing sytactic programming, though, at the same time, if you've ever played with a graph-based system like most 3D shading tools or Apple's compositing program Shake, you'll understand that these system do give you a lot of power in a mostly visual interface (my comments always seem to come back to computer graphics). Basically, I think the article is right about what it's saying, but I feel like it's already become an ingrained and widely understood property of technology.

Reid Hironaga - Feb 12, 2008 03:14:38 pm

Direct manipulation is presented as a means of allowing people to use intuition and our knowledge of everyday affordances to guide our understanding of an interface. Direct manipulation forges a common-sense bond between the user and the tool, with a minimized amount of required instruction. This method seeks to eliminate the tedious and unconstructive learning curve that comes with poorly designed interfaces. Directness is a strong concept, upon which much of today's best interfaces are designed around. The more abstract interfaces are made, the slower the human mind adapts to adeptly utilizing it; directness is a guidance tool for clarity and simplicity in real world modelling.

Brian Trong Tran - Feb 12, 2008 03:20:25 pm

I found this article very long and difficult to follow. I agree that it is important for users to understand what happens when they directly interact with something and that designers should take that into account, but this article was just a very tedious read. I did like how the article said that users should get a sense of interaction to emulate that what they do actually influences the program. Things like buttons would provide that interaction.

Siyu Song - Feb 12, 2008 03:15:28 pm

Aside from being difficult to read, and thus forcing the reader to adapt to the article. The main point of the particle was to make the user interact directly with a problem with minimal overhead of learning the interface, so it puts the burden of designing the interface in a way that hides the implementation from the user.

Raymond Planthold - Feb 12, 2008 03:11:19 pm

If it helps anybody else to distinguish semantic and articulatory distance, my impression is this:

Semantic distance deals with translating between two systems of representation -- the one you hold in your head, and the one the computer understands. An example of this would be arithmetic expressions. They are usually written "on paper" with infix notation, but various programming languages (e.g. Lisp) require the user to translate to prefix notation.

Articulatory distance is about the user's actions. For example, to use a "button" on the screen, the user presses a "button" on the mouse. If the screen representation were instead a stopper that the user "pulled" to activate, the mouse click would have a much greater articulatory distance.



[add comment]
Personal tools