Human Information Processing (KLM, GOMS, Fitts' Law)

From CS160 User Interfaces Sp09

Jump to: navigation, search

Lecture on Mar 4, 2009

Slides

Contents

Readings

Optional Readings

Saung Li - Mar 02, 2009 01:32:44 pm

I thought the section on Fitt's Law and Hick's Law is really interesting in how they quantify how long it takes to do something. Macintosh's window menu is better than Window's since the menu options are on the edge so the buttons have a bigger space to be clicked on. The Window's menu options float down so the user needs to move the cursor to a more precise position. For Hick's Law, the more options there are the longer it takes for the user to make a decision. Making a menu that has a lot of submenus is less efficient than one menu with all the options shown simultaneously, unless there are a ton of options and it is hard for the user to glance at all of them. All in all, interfaces should be designed so that users can perform their tasks with the smallest number of actions and thinking possible. The graphical interface of the two thermometers, for example, is fancy but can take a lot of clicking and scrolling to get to the right degree. The number of steps is reduced a lot in the bifurcated example where no delimiter is needed and both C and F are shown. This, however, may lead to errors since the user may read the wrong output, and it is unclear how to clear the fields. User interfaces should also reduce the number of errors that users may make. Some 0 information efficiency content should be removed from the interface altogether. For example, a dialog box saying a word search is complete and requiring the user to hit "ok" is useless since the user can be notified somewhere else in the program, like showing a progress bar that hits complete and stops. This would allow the user to continue with his task without having to make an unnecessary action, unless the notification is very important. Interestingly, the current Firefox browser I am using has a back button that is relatively large and a forward button that is small like the other choices. They may be utilizing Fitt's law since the increased size makes doing a task shorter, and the back button is used a lot more often than the forward button and possibly more than all the other choices so they increase the back button's size to reduce the time it takes for users to go "back."

Anatol Tsang - Mar 02, 2009 11:41:32 pm

After reading this section, I located a source of some of my uneasiness with this course. In most scientific courses, data is presented to support a certain hypothesis or statement (for example, time in CPU clock cycles is given to show the superiority of the quicksort algorithm over another sorting algorithm). In user interfaces, however, there is not quite a qualitative analysis- user interface designers tend to make observations and follow general rules in their design. Ironically, when there comes time to measure human response times, I still get uneasy.

(As a side note, the JavaScript alert is useful for debugging.)

All these calculations seem quite tedious, but interesting at the same time to me. I guess if someone is making a game based on reaction speed, these calculations would be important. But it seems that other factors (aesthetics, affordability of the features on the interface, its ease of use) dominate when the time factor is not as important in the application.

Denise Ngai - Mar 03, 2009 01:01:30 pm

Similar to the comment above me, I agree that it is rather strange to me that the readings in this course attempt to quantify what I would consider very qualitative things that differ on a person-to-person basis.

For example, in the third reading, it states: "Fitts' law is an effective quantitative method of modeling user performance in rapid, aimed movements, where one appendage (like a hand) starts at rest at a specific start position, and moves to rest within a target area." It's odd to me to even consider a LAW that attempts to quantify user performance with regards to movement. In addition, the principles mention in the reading do not strike me as "principles."

Theoretically, the following principles exist when applying Fitts’ Law to interface designs: 

   * Things done more often should be assigned a larger button. This seems an intuitive principle, but it needs to be used very carefully, since it harms the consistency of the interface.
   * Things done more often should be closer to the average position of the user's cursor. The amplitude (A) of a widget allows more control from interface designers compared to the width (W). Again, this needs to be used with caution, since frequency-based widget arrangements may slow down the user from finding things compared to logic-based arrangements.
   * The top, bottom, and sides of the screen are infinitely targetable because of the boundary created by the edges of the screen (unless a virtual screen exists) [3]. They should be fully utilized.

Rather, these "principles" seem like features of a UI that should be considered, depending on a user's preferences. In addition, these principles also seem rather self explanatory when discussed in the general sense.

I suppose it is science to want to explain and quantify everything in a scientific manner, but sometimes it's just odd.

Stephanie Shih - Mar 03, 2009 07:13:29 pm

I found the breakdown of actions using H, P, and K to be quite useful an idea. All the harping on timing, on the other hand, seemed somewhat over the top; I can see situations where knowing how long it takes an action to go through would be useful, but when the action is variable depending on user, it seems a little presumptuous.

I admit, I didn't really get why it was important to know how many bits of information one could get.

Ling Chen - Mar 04, 2009 12:37:36 am

At least this article wasn't as long as the last one, but again I found myself skipping through the equation sections. I haven't thought about analyzing interface details quantitatively before. When it comes to analyzing and understanding interface designs, I think about the qualitative methods. I guess it would make sense, as the article suggested, to measure and compare the interface efficiency with some numbers.

I enjoyed the section on Fitts' Law and Hick's Law because they actually make some sense intuitively. "Fitts' law quantifies the fact that the farther a target is from your current cursor position or the smaller the target is, the longer it will take you to move the cursor to the target." Even without all the complicated equations, we can see why it would be true. I also found out that it is faster to move the cursor to an Apple Macintosh-style menu than to a Microsoft Windows-style menu. Hick's law "quantifies the observation that the more choices of a given kind you have, the longer it takes you to come to a decision." My first thought was, that is so true. I always have much more trouble deciding what to choose when presented with multiple choices. I didn't know we can actually show it quantitatively. The equation for this law wasn't pretty either. However, we did learn that making choice from one menu of eight is faster than making choices from two menus of four items.

William Cho - Mar 03, 2009 04:06:45 am

Similar to some other people, I felt at times that the author was taking the idea of quantitatively analyzing user interfaces too seriously while reading the article. He had some interesting ideas about noticing and taking into consideration various variables of user interaction into the design, such as the time it takes for the user to move the mouse pointer to a specific location, or the time it takes for the user to move his hands from the keyboard to the mouse. However, I feel that this method is a bit too subjective to be useful for analyzing more complex user interfaces.

Szu-Chun Mao - Mar 04, 2009 02:20:42 am

This reading introduces the model from 1983 to do a quantitative analysis on user interfaces. Similarly to the last required reading, Raskin includes a few variables and shows us how to do the calculation using GOMS model. I feel that this chapter is well organized. The author has not only explained how GOMS model works, he uses a case study to exemplify the use of GOMS clearly. On the other hand, I don’t buy into this quantitative analysis. This might be a good way to measure the efficiency of the software by comparing users’ reaction time in each small software changes. Nevertheless, I find that using the revenue generated by the software or the user feedbacks as the measurement scale seems to give us more important information for user interface design. Since user satisfaction and profits are primary concerns of user interface developers. A faster HCI time does not equal to a better user interface design.

Chunwei Lai - Mar 04, 2009 02:13:20 am

I felt like with the previous reading the use of formulas and other data models are perhaps too specific to cognitive science and has yet little applicability to computer science or interface design except on a general level. I'm interested in hearing if there are companies who do take the formulas presented and actively use them in their design. I've know search engines to track user eye movements to place things better and gain understanding of user behavior but not specifically using the ideas presented in these readings. I don't doubt a connection but I just personally never heard of it.

Colin Downs-Razouk - Mar 04, 2009 02:14:50 am

I thought this chapter was interesting because it presented a much more quantified view of user interfaces, which is something I have been complaining has been lacking in many of other readings (particularly Raskin's other chapters.) I still have several problems with the way Raskin makes his arguments though, and this chapter has given me many more fresh examples. Example 1 was his discussion of double clicking. He says that double clicking is a problem because it is difficult to keep track of exactly what is going to happen when one double clicks on something. This seems like an arbitrary problem that we are accusing double clicking of. We could just as well as accuse clicking, or right-clicking of it. It is all part of affordances, right? Why is double clicking so different from clicking. There were other arguments that Raskin was not really clear about as well.

Joseph Tsay - Mar 04, 2009 02:50:01 am

I found the last sections of the reading on Fitt's and Hick's laws to be the most interesting. It was intriguing to see how these laws quantified with equations how long certain tasks should take. I also enjoyed reading about how long different types of tasks take, and the methods that are used in GOMS for estimating how long certain tasks will take in given interfaces. I found the portion comparing the mac menu bar with the windows menu bar to be pretty true in practice. Another area where this idea comes up is with clicking on the X in the top right of the screen to close a window. This is much easier to do when the window is maximized, as you can just drag your cursor as far as it can go to the upper right, without needing to actually aim for a button.

Rohan Dhaimade - Mar 04, 2009 03:00:40 am

At some point, the quantifying view of user interfaces become too prevalent. I think when your going this into mathematics to measure UI, you're just going to get bogged down in details. Especially, since it's hard to judge if something is "better" or faster since there is random deviation in all users based on their status at the time if they were busy or not paying attention, or whatever else. I think the author does point out smlal things and stick iwth them a bit too much, things like double-clicking and other things (in earlier chapters). Minimizing options is a good idea though (HIck's Law), which seems to make the most and easiest idea that is kind of obvious.

Timofey Titov - Mar 04, 2009 03:09:40 am

One thing that follows from the reading is that quantitative analysis is time-consuming, and requires ironically just as much interpretation and preparation as qualitative one. It is not a simple reading off of an "interface meter". The question then becomes how useful are such techniques in the real world? A relevant article on the disadvantage of available choices to the user:
http://www.columbia.edu/~ss957/whenchoice.html

Cuong Ngo - Mar 04, 2009 03:00:04 am

I find this chapter a pretty good read even though it was long. I never thought that we could quantify and formulate the efficiency of a user interface. The math is fairly complicated because a lot of variables are involved, not to mention we have to take the probabilities of user actions into account. The qualitative methods presented in the chapter would help us optimize our interface so that it can maximize the users' performance.

Jeffrey Patzer - Mar 04, 2009 03:24:45 am

Although this reading and the past one have presented formulas on how to quantify user's abilities to navigate the interfaces which are somewhat obscure and unlikely to be used, they do give good insight into how one should think when designing an interface from a human limit stand point. I thought that Raskin's comments on understanding the user's need for feedback about delays was very interesting. The idea that we need feedback that makes sense to us and is "humane" is an idea that makes a lot of sense. User's limits to deal with wait times when there is no feedback can prove deadly to a system when they pound on the keyboard looking for a response.


Carolchen - Mar 04, 2009 03:59:30 am

The GOMS calculation demonstration was interesting. I was surprised that the proposed UI for temperature conversion that had more direct manipulation took longer in the worst case. That was a good example of when a neat design isn't necessarily more convenient for the user. And it showed that when the controls (range and precision in this case) are not set just right, the efficiency can be very different. As for the GOMS heuristics for placing mental operators, I found that I was able to rationally piece together why Ms needed to be inserted or deleted, but I felt the text could have done a better job of explicitly saying "Delete a mental operator if it's redundant" or something to that effect.

I also found the consideration of the bifurcated converter to be insightful. Yes, it may be fast, but what about the chances for error? Those need to be carefully considered, as human error can be very likely. The information efficiency section was a little hard to follow, though I was able to muddle through it. Finally, I was glad the reading gave an introduction to Fitts' and Hick's Laws. I'd heard of them as being very useful rules of thumb in HCI, and the equations themselves made alot of sense.

Adit Dalvi - Mar 04, 2009 03:52:46 am

Finally, Raskin has something interesting to read about! I actually prefer when he breaks the monotonous rant about some user interface with equations and variables because it’s less boring to me (I’m just partial towards equations and pseudocode than words). I enjoyed reading about Fitts’ Law and Hick’s Law because they not only help quantitatively support certain types of designs, but when combined with the previous reading, we can design an interface that optimizes usability because we can easily quantify things like “how much time will the user take to reach a button” and “how long can the user remember what he was doing before he had to move the mouse to some point” and use these numbers to ensure that the interface is good to use (especially considering the fact that we can buy giant LCD screens with insanely high resolutions for our desktops now).

Shoeb Omar - Mar 04, 2009 05:20:13 am

I think it's cool that we all think in different ways. Half the above comments complain about how difficult it is to quantify something so fundamentally qualitative as UI comfort, while the other half express relief at seeing some sort of quantification and "method to the madness." I think the chapter has made me fall in between. Although the ideas posed are interesting, it is still important to use the information with caution to the wind, whereby UI friendliness and comfort/speed come at the cost of functionality or even user intuition. I won't lie, the ideas of Fitts' Law and Hicks' law sound so commonplace and obvious that you wonder why the need to delve into them so deep but I think its important also. By making a big deal out of things that may seem obvious, they aren't forgotten and are payed the attention to that they need

Kevin Huey - Mar 04, 2009 05:45:30 am

I take this article as nice justification for the tasks and methods we are undertaking. On the surface, it seemed like refining ideas to make actions quicker and smoother could only have a limited impact. That example with the temperature converter is a nice eye-opener, albeit a controversial one. Like many of the previous posts, I have a bit of a problem with these quantification equations (if you haven't caught on to me yet, I've had problems with a plethora of previous readings; just find my name and you'll see). All these so-called "average" values still don't tell me much, and since people are just so comprehensively different, I find it hard accepting the validity of these averages. But from personal experience, interactive visuals used for quantitative answers can be a hassle, just like the scrolling temperature example in the reading. Going up and down...such a hassle. Type it in and be done with it. But the greatest argument they have going for them is the comparison of the previously stated temperature examples with the one-input-two-output example. Less clicking to choose a conversion route...that's a good observation.

David Burban - Mar 04, 2009 03:42:43 am

This reading reminds me of this article, where user satisfaction drops by 20% over a 1/2 a second extra wait; "Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction". This relates to the reading when Raskin talks about R, which is the machine response time, which is not always controllable by the content provider (say the user is using IE6).

What I found interesting is the average time (H) it takes for a person to move his or her hand from the mouse to the keyboard or vice versa. Eliminating this H is essentially why programs have multiple ways to do one thing (clicking on the disk icon in Microsoft Office or hitting ctrl+s). Both do the same thing, but since you're typing, you have your hands on the keyboard, making sense that the interface doesn't force you to move the mouse to the disk icon. However, some previous readings have suggested that this is confusing since there end up being two ways to do the same task. But by having these two ways of doing the same thing, we can essentially reduce H to zero in some applications for some commands.

Derek Liu - Mar 04, 2009 07:38:43 am

Like with the previous reading, I'm not sure how useful quantitative research/analysis of user interface design would be. When evaluating UI design you reach a certain point where you can say things like "if it takes this long it is too long" instead of "analyzing these following factors this action takes 0.4 seconds, then 1.35, then .... which adds up to 8.1259 seconds and thus is too long to wait." You could easily say instead: "I waited longer than I would have prefered." A lot of this paper delves into the mathematics and analyzing of wait times when instead one could just make the point that multiple actions take too long and people don't want to wait very long, instead of going on multiple pages about it.

Kevin Nakahara - Mar 04, 2009 07:49:09 am

The readings sheds some light on some quantifiable ways by which interface effectiveness can be measured, which I'm pleases some people in the class. The idea the less time => better use and more satisfaction certainly makes sense, since as tasks become quicker to do, people can move on to more of other tasks. The law of diminishing marginal utility mandates that as we do more of something, the faster we get sick of it, so as a user is able to do less of something and more of others, their returns are greatly enhanced. Just thought I'd put a social science spin on things.

Shendy Kurnia - Mar 04, 2009 08:29:35 am

I don't read the whole reading, but what I got so far is that Raskin suggests UI designers to take an account variables of user interaction such as how much effort user might take to do some sequence of action for example. In my opinion, it indeed has to be taken into account in designing UI, but it's not always to minimize user's effort. In some case, we want user to concentrate maybe and by doing a little bit serious effort, user can stay focus.

Sean Ahrens - Mar 04, 2009 08:49:46 am

I actually have this odd affinity for Fitt's Law. The formulatic calculation of the efficiency of a user interface is music to my ears. One question I have out of the readings however is how does Fitt's law get adjusted when you talk about the advantages of the Macintosh desktop program selection. Does the width of the "button" increase if it has a block (like the edge of the screen in the way)? It has this effect, I just don't know if this is the correct way to think about it in the termology of Fitt's Law.

Meiying Li - Mar 04, 2009 08:36:30 am

I like the idea of actually "calculating" the time require for completing a task. The calculation gives better estimate when we take probability into account, as shown on Hal's Interface example.

The idea of bringing in machine learning with such a calculation in the interface design came to me when I was doing the reading. For example, in Hal's first interface design, the default setting is converting F to C. Therefore we say the probability of this being correct is a half. But if the program remember the frequency of the options that Hal chooses, we can set the default value always to the one that Hal uses most frequently.

This may be applied to interface designs where there are usually too many options for the user.

Sean Kim - Mar 04, 2009 08:38:02 am

Personally, I don't like to consider a human as a machine so that we are analyzed like any other structure. However, after reading this article, for designing better user interface to a human, it maybe necessary to understand the human behavior like any other existence. first of all, our brain is composited of perceptual memories and perceptual processor, the author said. the data for time decay of visual and auditory image stores is displayed for this reasonings. He also explained about a working memory to hold the information under current consideration and a long-term memory to store knowledge for future use. The following data from a test can be thought to support his explanations. The cognitive processor cycle time Tc is shorter when greater effort is induced by increased task demands or information loads; it also diminishes with practice. the most interested fact from a experiment was the probability of recalling a word from a list as a function of the position of the word int he list and of the delay before starting recall

Siddharth Shah - Mar 04, 2009 10:21:31 am

I am in agreement with many of the previous commenters; I did not find it so useful to be able to calculate with maddening precision the amount of time certain actions take. It seems especially futile because humans are not like ticking CPUs; they are far more complex, and it is difficult to imagine that mathematicians and others could claim to find a formula that works for ALL humans. When measuring response time, how does the equation take into account the fact that the user is thinking about his puppy who died yesterday?? To me, these equations are like love potions or more recently, male enhancement pills: the makers claim they work, and maybe the fools believe them, but the rest of us know better. Or don't need them. One of the two. I'm just sayin.

Alexei Baboulevitch - Mar 04, 2009 08:02:38 am

A very analytical way of looking at efficiency, a bit like the previous article. I'm still not convinced that this could be useful in actual design, but it certainly seems helpful for thoroughly evaluating interfaces after the fact. Unlike the previous article, this one makes a lot less assumptions about the brain's inner workings, and instead relies on experimental evidence. (The laboratory-derived timings for the gestures, for instance.) For the experiments presented, I think this method strikes a good balance between pure evaluation (i.e., the typical design cycle) and outright neural simulation or emulation.

Interestingly, even though the bifurcated interface was one of the more effective ones in the experiment, we don't see them very often in the wild.

Salman Rahman - Mar 04, 2009 10:34:21 am

This article was crazy and it was one I enjoyed a lot. IT was insane to learn how you can calcualte down to a number the effiency of a UI and how long it will take a user to navigate. It is very interesting to see how humans process information and that we don't all process it the same waya, unlike a computer. Yet there are things about our brain in the way it works that are very circuit/computation based. Along theze lines, I found the presentation of Fitt's law to be pretty bossy and I'm excited for lecture today to learn about this!

Sum Sum Wong - Mar 04, 2009 10:37:28 am

This reading is kind of interesting because it shows us how to quantify the efficiency of an UI (or human brain as well?) just like the previous reading. However, I still doubt that does it worth to give such a "precise" calculation and can the calculated result provides us with some great information that we cannot get from other methods.

Chris Thompson - Mar 04, 2009 10:39:48 am

I totally did not notice that first reading when I was saving these last night (I generally do the readings on my lengthy BART commute) and actually did just the optional readings instead. But I didn't notice that until just now, when I went to submit my comments, and it's a little late to go back. Sorry about that. GOMS is a simple idea, that directly relates to most modern programming languages. It stands for Goals Operators Models SelectionRules, and essentially means that the idea of what you want to do should be laid out in goals (this part is not explicit in modern programming languages, but is emphasized in good design and in this class, which requires us to spend as much if not more time planning out the goals in the form of interface design and task analysis than the OMS). A model can be thought of as a method -- a collection of low-level Operators that accomplish a desired goal. And Selection Rules come into play when there are multiple existing Methods that could accomplish a single goal. They then apply GOMS from a user's standpoint, choosing a list of goals and quantifying how much time each takes, in order to determine how much time ought to be required to perform an entire task (collection of goals). Fitt's Law is a very specific mathematical formula that essentially tells you how fast one can go and still be accurate when trying to click on a goal. Of course, one can go faster and be less accurate, but that has its own drawbacks, or one can go slower but be reasonably sure to hit the target, but that is less efficient (and who isn't in a hurry these days?). By analyzing the law, we can determine changes that could be made to a program in order to increase user productivity, at least in the case of quickly clicking on (sometimes unexpected) buttons. Larger buttons, for instance, can be clicked on more quickly because the acceptable input range allows for more variance. And anything falling in a corner of the screen boundary (which isn't always the window boundary) can be accessed exceptionally quickly since it's impossible to overshoot. But what this reading really made me realize is the benefit of keyboard input. I suspect the formula for pressing Enter or Escape is a lot simpler than Fitt's Law, since it doesn't matter where the buttons in question are.

Dwijgarg - Mar 04, 2009 10:54:45 am

This reading is very interesting, as it clearly shows us how to quantify the efficiency of a user interface. I did not ever think that this would be possible, as it depends on person to person as to how they like the UI, how they interact with it, and how intuitive it is to use for them. However, I also did not know that a lot of the processes and functions in our human brain can also be quantified, as they are based on numbers and calculations. Thus, I guess it does make a little sense to quantify even the quality of a user interface, based on the quantifications of our own human brain!

Jason Lo - Mar 04, 2009 10:12:02 am

I thought this article was more interesting than the last one. Although both are based in math a lot, this one was more intuitive and made more sense. It was interesting to see the idea of macintosh interface being better down in a fmore formal way although I have heard the story before.

Jason Lo - Mar 04, 2009 10:12:02 am

I thought this article was more interesting than the last one. Although both are based in math a lot, this one was more intuitive and made more sense. It was interesting to see the idea of macintosh interface being better down in a fmore formal way although I have heard the story before.

Alexander Cho - Mar 04, 2009 11:01:26 am

I found it quite fascinating to see the times it took to use different controls on the keyboard. At first I did everything with the mouse, but as I learned shortcuts on the keyboard I realized it would saved much more time, and these things always add up. This is the advantage of knowing UNIX, to save more time, over windows where most things is mouse-pointing based.

Anjana Dasu - Mar 04, 2009 11:09:02 am

I don't like the idea of quantifying human behavior so I didn't like this article. recently I've been more interested in the comments made by my peers than the articles themselves. I agree with Derek's post above that sometimes it's not necessary to know the (milli)second by (milli)second time count of an interface to judge it. I guess there would be uses to this if you were designing an interface for say NASA where timing is crucial, but I don't know if this article is that relevant to the games we are working on.

Alan Young - Mar 04, 2009 11:21:04 am

I think the notion of Hick's Law and Fitt's Law is interesting but at the same time I'm not sure how much more help or insight it gives to designers in addition to what we read in the previous readings. Even though these laws make good sense and provide a better basis for UI theory, I'm not sure how much applicability it holds in actual design scenarios. I think at this point, it may be safer bet to go with what's common and accustomed or familiar by the user than with something new, even if that new design is better or more efficient according to Hick's Law or Fitt's Law. I think Microsoft Office 2007 may be a good example since even though a lot of studies were done to determine that the new interface was better and worth replacing the old interface, many users were frustrated.

Prahalika Reddy - Mar 04, 2009 10:52:33 am

I really liked the part of the reading with the K,P,M,H,R values. It's not something I've actually thought of before and it was different to be reading about it. The M value, the time it takes for a user to mentally prepare for the next step, seemed interesting, though I don't know how well that can be timed. Which brings me to my next point: this reading and the previous one try to quantize human computer interaction with mathematical equations, and while some might be accurate in describing human behavior, I don't think there's any one mathematical way to classify the interaction between humans and computers. Even if people do certain things in certain ways, it's not always necessary that they act that way, and it's just as likely that could change their habits the next day. Reasonably, people tend to stick to their established practices, ones that can usually be defined by some sort of logic, and I can understand how the equations describe this, but it's never perfect, and I don't think using equations is the best way to do it.


[add comment]
Retrieved from "http://vis.berkeley.edu/courses/cs160-sp09/wiki/index.php/Human_Information_Processing_%28KLM%2C_GOMS%2C_Fitts%27_Law%29"
Personal tools