Human Information Processing (KLM, GOMS, Fitts' Law)
From CS160 User Interfaces Fa06
Lecture on Oct 9, 2006
Readings
- Quantification. The Humane Interface. Chap 4. Raskin.
Optional Readings (you don't need to comment on these)
- GOMS. University of Maryland Course Notes. 2002. Hochstein.
- http://www.cs.umd.edu/class/fall2002/cmsc838s/tichi/printer/fitts_4print.html Ftts' Law: Modeling Movement Time in HCI.] University of Maryland Course Notes. 2002. Zhao.
Hiroki Terashima - Oct 07, 2006 12:02:43 pm
I enjoyed reading chapter 4 of The Human Interface because it had easy-to-follow quantitative analysis of various interfaces of things that we have used before, like the Fahrenheit/Celcius converter, mac/windows menus (mac wins by 0.4 seconds!), moving the cursor across the screen, JavaScript alert messages, etc. It's amazing how these people meticulously analyze these things and can reason quantitatively about how good the interface is. Raskin argues that “quantitative methods can often reduce argument to calculation”. I thought this was funny because it could be taken to mean that people who argue about interfaces must shut up if some numerical analysis of the interface design is presented to them...or at least that's how I read it.
The section called “Double Dysclicksia” was fascinating because I haven't thought about double-clicking this way; I consider myself “unaffected by dysclicksia”, and weren't really aware of the problems inherent in using double clicks: I click fast, don't move the mouse around too much, and know which icons are double-clickable, so I don't experience many problems. I wonder how other people felt about this section?
Kang Chen - Oct 07, 2006 12:39:41 pm
Although Ch4 has some equations, I find it much easier to understand and more enjoyable to read than the previous reading. The only section I really found confusing was when Raskin tried to come up with the method for inputting the temperatures. It took me awhile to realize the steps for the next step are already appended to the previous one. Aside from that, I really enjoyed the discussion on the GUI for the temperature converter. The bifurcated interface certainly reduced the time it takes to perform the task of converting temperatures and in the long run, will be much more efficient than the other designs. However, it might be a little confusing to an amateur user why the "incorrect" conversion is also presented. A bigger problem is that there's no indication which conversion was performed so it will rely solely on the user's working memory to remember what s/he was trying to do once their locus of attention has been shifted.
Another interesting point from the article was the comparison between Mac and Windows toolbar locations and size. I usually perform tasks on both OS by using keyboard shortcuts and so, wasn't aware of the differences in the time it takes to move the cursor to the menu location. Yet, the Windows menu does give the impression of being very crunched up and so selecting an action from the menu would require higher precision.
Tak Wong - Oct 07, 2006 03:34:11 pm
It's quite interesting how Raskin can use quantify how long it takes to input/interact with an interface. Before reading this article, I would think people choose among differnet interfaces based on how good it looks or takes the input time into consideration only if it has a significant difference (perhaps more than a second or two). I can totally see a lot of beginners having the double dysclicksia problem. They usually can't have their mouse in place or can't click fast enough, then end up attempting 3 or 4 times before sucess.
According to Hick's Law, it would be faster to select among 8 items than two of 4 items. But what if the number of possible items are so great that it is overwhelming to see all the possible choices? Then would having a few menus make sense or speed the process? Also, I wonder if Hick's Law is the reason why the Macintosh never switch to 2 button mouses. Having 1 button is always faster to click because you don't have to think?
Scott Friedheim - Oct 07, 2006 05:57:45 pm
I appreciated the simplicity in being able to analyze an application based on the M,P,H,K, terminology. Although Raskin really didn't mention how the associated time values were determined (perhaps similar methods as the previous reading addressed) I found that they were sufficient for doing a good job of timing out an application. This was certainly a whole different level to designing software; rather than make decisions (as I have done in the past) based on having users click here or there, it is much more important to consider the movements and thought that the user must make in doing the clicking.
I enjoyed Raskin's explanation on the differences between the Mac and Windows toolbar. Even though I have used Mac's and PC's extensively, I have never noticed the difference until it was mentioned in the reading. I can see how small details like this can have an effect on a users work flow. Rather than have to aim and land somewhat perfectly on a button, a user could just keep moving his mouse pointer up and click anytime the pointer is above the button.
Tabassum Khan - Oct 07, 2006 06:28:40 pm
This reading had some mathematical calculations but not as much as in the previous one. The explanation of GOMS calculations through examples i.e Hal's interfaces was pretty straightforward and easy to understand. However, I found the bifurcated temperature converter interface confusing because the input unit was not specified. How will the application behind the interface know whether the input figure was in Celsius or in Fahrenheit. For instance, say I type 32 in the input field, so if I meant 32 degree Fahrenheit then the two output fields should display 0 in C and 32 in F; if I meant 32 degree Celsius then the two output fields should display 32 in C and 90 in F.
Patrick Rodriguez - Oct 07, 2006 09:02:15 pm
It's very cool that UI designers have different ways to numerically quantify the efficiency of a given design. This opens up the possibility for optimization. The previous reading also left me with this impression. There's way too many equations and variables though, so I wonder how many designers actually consider this stuff. It's a lot easier to explain in vague terms and generalizations about why a design is good. Is it really worth it to figure out the numbers if the design just "seems" right?
On the subject of double clicking. I find it funny that this is actually a real problem. I have observed many computer users (inexperienced or otherwise) get into the habit of double clicking on everything. Sometimes I remind them that they usually only have to click once, but they still continue. Some sites even have a warning to not double click, especially when something like charging a credit card is involved. Maybe a standardized icon could be developed to signify whether something is "double-clickable" or not.
Jonathan Yen - Oct 08, 2006 12:21:34 am
This reading had quite a bit in common with the reading in the last lecture. I found this to be much easier to understand and less technical. I think that trying to quantify efficiency in terms of how much time it takes to perform a task is a good step towards trying to improve interfaces. I agree that a more efficient interface is a strong indication of how humane an interface is. However, I think that there are some flaws to this approach as well, as there are some assumptions that are made for some of the scenarios: people are perfect typists, each key typed on the keyboard is considered independent, all people type at roughly the same rate, etc. I am curious as to whether efficiency can be regarded as the sole indicator for how humane an interface is.
Heung Tai - Oct 08, 2006 03:03:51 am
Setting constant time for different operations: H,K,P,M is the same idea that we assume each addition, multiplication, comparison... as constant time in analyzing algorithms. The idea is simple yet very powerful. It eliminates the concern of individual behavior. It gives us a systematic way to analyze an interface. Given two interface, we can do a ">" or "<" comparison on them.
GOMS provides an abstraction, but it goes too far. It makes the analyze becomes a function that base on input only, and this is the problem! A good interface is very subjective to the users. A beginner and an expert have two very different feel of the interface. If the analyze doesn't take in account of the states (past experience, knowledge), the analyze is not complete, or even doesn't have practical value. It's like redefining a question to give out an answer, that is, not answering the question.
David Hoffman - Oct 08, 2006 09:17:26 am
On some level, I think its a good idea to quantify the efficiency of an interface. However, I don't think these equations should be relied on in any serious way to develop a piece of software. There are many intangible aspects to software which need to be taken into account than the pure mathmatics of human gestures. So generally, I think that putting planning into the user actions is a good thing, designing an interface to minimize the time it takes a user to perform operations shouldn't be a driving pressure in the design. Besides, I find that for the most part, maximal efficiency means less thought and that leads to more errors and more time wasted in the longrun.
Bowen Li - Oct 08, 2006 11:14:52 am
The note on double clicking, in which Raskin says that it is unclear which interfaces require a double click and what the response will be rings true in my mind. I know that my grandmother, who is learning to use the computer always gets confused as to which elements require single click and which require double click. Especially since many of the items look similar: for example, a firefox icon on the desktop requires 2 clicks to open, while the icon on the "quick launch" only requires 1 click, but they look identical.
The idea of serializing actions and calculating the times seems to be a good idea for a simple interface. I think such actions will only dictate in one direction: that is, reduction of movements the user has to make and reduction of steps the user has to take. These two (P, M) are the most costly in terms of time. But I think this discounts other elements of the design: clean vs. clutter, GUI vs. command line, etc. Having the interface be the "fastest" may not be the final goal when designing an interface.
Although the "Alert" function has been abused to no end, I don't agree that it doesn't provide unnecessary information. There are a couple cases when pressing "Ok" is a valid response: suppose on your website you asked the user to do something with another program, and you didn't want your code to run until they had done the specified task. Then it would be appropriate to create an alert that says "Press ok when ready". So in essence the user is providing temporal data by deciding when to press the button.
Sean Carr - Oct 08, 2006 11:56:28 am
It is very nice to know the estimated quantities for the time it takes to perform various standard actions on a computer. The numbers certainly validate my own experience and why I hate interfaces which require me to use pointing devices because they take so much longer. One thing this chapter didn't directly address is that some users are just "more comfortable" with one input method or another and are not very adaptable. I think this is mostly for people who have not grown up using computers and therfore have a more difficult time learning how to do so when older. In my experience once they get good at one input method they try to use only that one.
I had also never really heard UIs explained in terms of entropy and information theory before but the application makes sense and I think Raskin did a good job of explaining it for people that aren't familiar with the concept of entropy as well. Even though this section was a bit technical I think Raskin does a good job of making it easy to read and understand.
Patti Bao - Oct 08, 2006 12:48:50 pm
After reading all the comments on double clicking, I wonder what would happen if we did get rid of it altogether. Like Bowen, I have also seen people double click on things that only require one click. It becomes problematic when they click slow enough such that the clicks are recorded as two single clicks, and result in two instances of a program or window opening. As far as I know, the only time I ever have to double click is for desktop icons, so maybe the double click wouldn't be missed all that much.
As for GOMS, it is an interesting way to evaluate an interface, and although I agree that there are other things to consider besides efficiency of movement, I can't see what's wrong with having an interface that allows you to interact with it quickly and accurately. Why should you have to be thoughtful when it comes to clicking a button? If implemented correctly, an interface that is efficient should also minimize the error rate.
Michael Moeng - Oct 08, 2006 03:02:05 pm
I was somewhat confused by Hick's law. It seems to imply, with logarithmic scaling when adding more elements to a list or choices, that if we wanted to display X choices to a user, the best method would be to display them all on one gigantic list. This is probably not correct, as few interfaces use this--almost all lists are displayed in some kind of tiered, categorized way.
I do see how Hick's law applies to lists with a small number of elements, such that I could process the whole list with one look, but I think there is probably some sort of threshold at which the law ceases to apply, and a user needs to look at all the items, and then compare his/her "best" options.
Randy Hilarbo - Oct 08, 2006 03:47:05 pm
Overall, I think the article is pretty interesting. It's remarkable how having a quantitative goal can really affect the development of a UI. As demonstrated in the temperature example, the time goal that they have in performing the desired task can force a designer to come up with an interface to meet this goal. It's interesting how different the interfaces that they came up with by just bettering the efficiency of the design. I also thought that the ruleset that is presented in this reading in evaluating the time of doing a task can make a big difference in UI design. Also, similar to the reaction by the previous commentor, Hick's Law surprised me. I also thought that having a long list of options could worsen the effecieny of an interface. I am still unclear of the reason why this is not the case.
Robert Taylor - Oct 08, 2006 04:02:09 pm
As with the last reading, while one can appreciate the amount of work that goes into these things, I really wonder how hard real UI designers try to get programs to work with GOMS results. I only say this because computers themselves vary so much in speed based on hardware and software that millisecond differences seem like they wouldn't make all that much of a difference. Additionally, unless you're speccing your design for some worst case computer speed scenario, it seems like you're not appropriately taking into account computer speed in causality calculations for how speedy your program's UI must run. But what would the worst case scenario be? Does it even matter?
Eric Yoon - Oct 08, 2006 04:02:59 pm
In a previous comment I questioned the usefulness of relying too much on quantitative measurements in assessing user interface design. But this article makes a very clear argument about why some measurements can be quite useful. It's hard to argue with the concept that interface A is better than interface B if interface A allows a user to perform the same action in less time and/or with less keystrokes or mouse clicks.
I thought the short piece on mouse dyslicksia was interesting and relevant. Raskin also adds that it is very important to give users regular, honest and accurate status updates, so that they know what's happening under the hood. Experienced users -- like, I'm sure, everyone in the class -- don't get nervous when a computer stalls a bit or when a second click wasn't quite fast enough. But less experienced users -- like my parents -- do in fact get concerned, particularly when they're not told whether or not they failed or succeeded in their goal, or whether the computer is still working on the action.
Andrew Tran - Oct 08, 2006 05:50:54 pm
I found it quite interesting how others have already conducted experiments in finding the times it takes for people to perform simple tasks such as hitting a key on the keyboard. The GOMS model was simple and easy to understand. The section about measurement of interface efficiency was very hard to understand, the equations just make it more difficult to comprehend the section. My own interface for the Hal problem was very much like the first proposal. The second proposal was nice but i do agree that it takes too much time. I don't think the last proposal works so well, even though it is very fast. I think its confusing because you don't specify which conversion you are doing. Like how does it tell apart from knowing you entered a celsius and want farenheit, and vice-versa. All you do is just enter a number, and it gives you a celsius and farenheit of that number, but what unit is that number in the first place? IF it was celsius does it appear the same on the right hand side or would it think its farenheit and convert it, i don't know.
Jason Shangkuan - Oct 08, 2006 05:49:21 pm
GOMS:
GOMS is an interesting way to approach HCI because it provides a way to quantify the effectiveness of a task. By breaking down tasks into subgoals and identifying the operations involved to achieve these goals, a designer can define how many steps or times it takes for a user to accomplish. This is particularly helpful when prototyping such as low fidelity prototyping because modes and steps can be taken into account. As mentioned, however, GOMS is still only a method and depends on predicting behavior. GOM needs to be applied to more users to become a more refined model and apply across a wider range of prototyping.
Fitt's Law:
The article on Fitt's law references back to what we read on The Model Human Processor by Russo. Fitt's law models human action in general and the movement that we make to accomplish a task. Although it is interesting to have a mathematical model, it does not take into account multiple thoughts and processes occurring during a task; although it seems complicated, it still is an over simplification. However, it is very useful especially when applying it to GOMS. GOMS looks at the overall goals and methods, and the timing can also be utilized to determine if the number of steps are realistic or to make trade-offs.
Rayhan Lal - Oct 08, 2006 06:32:10 pm
First, I appreciate that Raskin, as in previous sections, points out the variability in his constants (especially K). I would venture to guess that almost no one in the class suffers from dysclicksia. It’s quite interesting and worthwhile to ask why? My hypothesis is that we are all programmers very accustomed to current paradigms, so we are aware where double-clicks will be because we would put them there ourselves. One issue I had with the alert messages is that while they do have an information theoretic efficiency of 0 from user to computer they give the application a chance to communicate something to the user (and so I do not consider them completely useless). The temperature converter I liked the best was the one that used the units as a delimiter. I argue that the input it not simply the digits of the temperature but also the units, since putting in Fahrenheit means you want Celsius and vice versa.
Ramy Ghabrial - Oct 08, 2006 05:31:08 pm
It seems most people agree dysclicksia is a problem. I think the worst culprit for this (certainly the one that first comes to mind for me) is renaming icons in Windows. As far as I can tell (at least in XP) the proper procedure for doing this is clicking once on the item so it's highlighted, waiting a while, and clicking again, not on the icon but on its accompanying text. This is not very intuitive, and I did a whole lot of opening files I wanted to rename, or renaming files I wanted to open, before figuring it out.
I thought the bifurcate temperature UI was interesting in the context of noun-verb vs verb-noun choices, because it bypasses the verb altogether by automatically executing both possible desired actions on the noun.
Maksim Lirov - Oct 08, 2006 07:27:11 pm
For me, this reading highlighted the important design task of trying to limit the time required to input data and commands. I have a feeling that many designers of applications do not take this into account and thus create interfaces that are very clumsy to use. The temperature interface problem example showed that sometimes a real-life metaphor (interface #2 with the thermometers and slide selectors) can be less-efficient than one that is closer to just presenting data (interface #1). Interface #1 is the best because it only presents the data desired based on one input and two-choices (many times the desired choice will be already selected). The interface #3 proposal I believe is worse than both interface #1 and #2 because Hal will be presented with both a fahrenheit and celcius readings, when he only wanted just one of them.
The Mac menu vs Windows menu comparison was interesting because it shows how small simple things like menu placement can lessen the stress on the user to interact with the system in the "right way" in the shortest time possible. I agree that the less thinking that the user must do to select the proper menu, the easier and more enjoyable the action will be.
Utsav Shah - Oct 08, 2006 07:36:43 pm
Who would've thought there's a way to measure efficiency of an interface? I certainly did not. Anyway, Raskin does a good job explaining his nomenclature and it's use through some great examples, especially temperature conversion one. I agree with some of my fellow classmates that one he claims to be very efficient is somewhat confusing as to it's not clear what to enter. I think the radio buttons interface works good in situation like this. In the begining, he talks about interfaces not giving enough feedback while downloading files online. I think new browsers such as Firefox does a good job of providing status and progress bar for those situations. Lastly, I think Fitt's law fits well in this reading than last one since it's easier to understand with Raskin's one-letter mnemonics.
Tony Yu Tung Lai - Oct 08, 2006 09:16:58 pm
In this chapter, I find the dysclicksia section to be the most interesting. It is true that I don't have much problem knowing when to and doing the actual double click action, but it is by no mean to be something obvious or something that eveyrone could do. For example, if we were to put someone who have never used a computer in front of one and give him no direction about how to use the mouse, he can probably figure out how to click on icons and even move them around. Yet, without specific in struction, it might take him months to even think about double clicking the icons. Moreover, as mentioned by Raskin, there are too many other inputs that is too similar to double clicking. I know from experience that it is way too easy to open 20 files all at once while trying to drag and drop them from one folder to another.
Vijay Rudraraju - Oct 08, 2006 09:53:05 pm
I was very interested by the idea that a designer can estimate a lower bound for the amount of information that a user must provide to an interface to perform a function. It never occured to me that a user interface could be quantitatively analyzed with the methods that Raskin introduces. It seems counter-intuitive that a visual interface could have a theoretical maximum efficiency. I continue to be amazed by the broad applicability of information theory.
Alex Wallisch - Oct 08, 2006 08:41:24 pm
Although I've heard of interface analysis by means of "number of clicks" or similar metrics, I'm impressed with the method outlined in Ch4 of Raskin. The ability to compute how "good" an interface is by looking at the time it would take to perform actions and the information efficiency of the interface seems quite useful for the designer. I also enjoyed Raskin's analysis of the little parts of computer use that you never think about - dysclicksia, for example, is a phenomenon that I never really thought about before, but once Raskin mentioned it I realized that I've seen many people who have a hard time determining what can be double-clicked and what constitutes double-clicking.
One comment on the time estimates presented in the description of the GOMS Keystroke Level Model is that the rules for where to insert and delete M's seems a bit contrived. On one hand, they make up a good rule of thumb. However, the precise places one has to stop and think depend on how often one has used the interface previously (and how used to it they are). Furthermore, the amount of time required by an M depends on the ease of use of the interface. I've used interfaces before that didn't require me to stop and think often, but when I did, it often took me a long time to figure out exactly what I wanted to do next.
Yimin Yao - Oct 08, 2006 11:38:33 pm
I found the idea of measuring the efficiency of an interface quantitatively is quite fascinating. As the author pointed out, the model is not an accurate estimation for the time the users will need to complete the tasks. For example, for the second temperature convertor interface cited in the chapter, the model does not take into account the time the user needs to slide the mouse to the accurate position on the thermometer, and whether a random number can be counted as a unit. The comparison between the efficiency of two interfaces by such model can only be reasonable if the two models are slight modification of one another to check for improvement.
Speaking of disclicksia, one of the biggest mouse clicking problem I have is when I try to select several items in a folder to move or to delete, I use the mouse to select while pressing the control key. Often times, when I try to select an additional item by clicking the mouse, the mouse gets slightly shifted, and the clicking is read as a copy command that replicate all the items I have selected so far. ><
Antonis Mannaris - Oct 08, 2006 11:23:59 pm
Quantitative analysis, as it is briefly explained in the chapter, provides yet another simpe and useful tool for evaluating an interface design. I am not however convinced by the linearity and over-simplicity of the analysis. In particular, the chapter seems to assume that users cannot multitask. For example, I think it is naive to assume that if a "Yes/No" popup window appears with instructions to the user, the distance of the buttons is important. In this case, the user is likely to be able to move the cursor WHILE reading the instructions, in which case the time it takes to move the cursor is not additional to the time it takes to make a decision. One other aspect of the chapter with which I strongly agree is that faster does NOT mean better, especially when the probability of error or confusion is sacrificed for speed (like the temperature conversion example). If that where the case, there would be no confirmation messages, which would be disasterous.
Cheng-Lun Yang - Oct 09, 2006 12:22:16 am
As everybody said previously, this reading is easier to understand with less technical formulas. The idea of formulating a person's interaction to a computer is an interesting idea. However, the rules that get rid of a few M's and K's are a bit confusing and might very easily slip when deriving the access time of an action.
As of the temperature converstion interface, i think the graphical interface with a thermometer is really hard to use without first looking at the stats. It's making a simple program too fancy to be practical. The graphics look nice but it is pretty useless. I would rather have something with simple interface than something that's pretty but hard to use.
Chen Chang - Oct 09, 2006 03:12:27 am
In this reading, I felt that it was nice to get some numerical data for a sense of timing in real life for even the most abstract processes such as hitting a key on a keyboard or clicking a mouse. When it comes to mouse clicks, 1 ms can certainly make a difference whether the user succeeds with a double click to open an application on a desktop or rather only highlighted the icon because the processor registered the two clicks being spaced apart too far and thus counted them as two single clicks. I agree with the fact that feedback should be provided if delays are unavoidable, show a WORKING progress bar or something of the sort (not those progress bars that jump directly from 0% to 50% and then up to 100%). After all don't try to deceive the users and test their patience as it will most likely result in extraneous unwanted mouse clicks which could cause application crashes and/or os instability.
Ming Huang - Oct 09, 2006 03:34:03 am
The reasoning and quantifications in Chapter 4 of Raskin’s The Humane Interface are well-founded and in line with cognition theories, however they do not necessarily produce the "perfect", or "best", interfaces. I will make two arguments for it here:
The notification boxes have an information efficiency of zero, but it does not mean that it is useless. A user would like to know when a task finishes by having the system telling him so in a dialog box, because there is no other way to be sure for some processes (like the one used in the example). It did not require information from the user, but rather presents information. Considering it unnecessary based on information efficiency is too single-minded.
In the discussion on Hick's law, I slightly disagree from the proposition that any increase on the nesting of menus will delay the decision making process. In my case, my favorites are organized in subject categories and if the items in a single category are too many (more than one column from the top of the screen to the bottom), I will even split them into subcategories. This makes my browser display a multi-level favorites menu. The effect of grouping allows the user to quickly narrow down his selection without going through what otherwise would be a monolithic monstrosity of a list where one has to go through an average of half of the list to find what he needs. In this case I would argue that subdividing and grouping actually helps accelerate the time user takes to make a decision by taking out multiple choices, groups of choices, out of the user’s mind so that he goes through less choices in effect, thus reducing both the frequency and time of M and P and thus the total time of the task.
Michael Mai - Oct 09, 2006 04:07:47 am
This chapter stresses the importance of gathering qunatification data on interfaces in order to improve the overall layout. Although briefly discussed, I feel that R is one of the most important variables in quantifying interfaces. User attention spans are dropping and responses from the interface is crucial to maintain use and continued actions.
Lastly, I would like to bring up a question I had about the Mac and Windows comparisons. How does the mouse for the Mac, which use to have one button, compare to the windows mouse which generally has at least two? Due to their interfaces and modes, does the mac will out again in speed?
Simon Tan - Oct 08, 2006 11:12:55 pm
I felt that this text was a much simpler way of expressing the quantification and efficiently of user input compared to last week’s reading. There is much less math, more room for variation, and fewer variables for clarity. Also, it makes it clear that interface designs can be vastly improved using GOMS, and that possibilities for efficient interfaces could be missed if GOMS was not considered. The author even shows how concepts such as Fitts’ Law explain why the Mac OS’s menu bar is much more efficient than the Windows’ counterpart, something I never really thought about before. Real life examples like that really brought the relevance of this kind of analysis home, and should encourage people to save every millisecond they can when designing interfaces. (Although I wonder what the tolerance for shaving milliseconds off user interfaces is for most people.)
About the double-clicking issue - I think if icons, etc. were just designed to catch the different kinds of clicking (double, single, drag, etc.) and be smart enough to only accept one kind while discarding the others, we wouldn’t have the problems of multiple instances of programs launching as a lot of people have experienced above. For example, Windows should catch you if you try to double-click on a Quick Launch icon. Since there is no logical reason why anyone would intentionally do that, Windows should just convert the action to a single-click action so the intended behavior happens.
“dysclicksia” - I want to know how long the author sat thinking up this word.
Edward Karuna - Oct 09, 2006 09:40:32 am
It is interesting how, when subjected to formulaic analysis, the winner is a (rather non-conventional looking) GUI application. Of course, I suppose the constraint that the conversion requests are at discreet times makes that solution the most efficient, otherwise I would lean towards the text-based interface, which will automatically clear after given a C or F. Put into a loop, I lean towards that interface being the most efficient for repeated temperature conversion. In addition, it only has the one requested output, instead of the user having to choose which output is meant.
Andrew Hao - Oct 09, 2006 09:59:04 am
It is fascinating to see the sheer amount of quantifiable data that interface engineers can deal with.
GOMS - Through the categorization of mental (cognitive) operations and human-computer gesture and action and predetermined times for each action, engineers can estimate the execution time of a task by summing up the corresponding times to every sub-action. This is fascinating to me because we are watching the iterative design process go on in Raskin's example. He takes the Celsius-Fahrenheit converter and iteratively designs it down to the most efficient interface possible by pinpointing unnecessary actions or processes and designing them out.
Johnathan Hawley - Oct 09, 2006 10:57:39 am
I liked Rakin's quick and dirty approach of approximating task time. It seemed accurate enough to get the job done. I agree with the points made in Double Dysclicksia section. I have had problems myself with double clicking and triple clicking. Occasionally in Word I will be clicking around different parts so fast that word will mistake it for a double click. Or sometimes when I want to enter a new URL in my browser I will mistakenly click the field twice which deselects the previous URL. Then I have to keep clicking until I finally select the whole thing again. I am not familiar with Mac toolbars but I could see how a Windows toolbar would be less efficient given what I saw in the reading. I suppose one Mac's big selling points these days is simplicity. I think it's funny how clicking OK on an alert window yields 0% efficiency. It's just another way to stick it to those annoying messages.
Suneet Shah - Oct 09, 2006 10:31:10 am
Finally an article that brings a science to the very subjective study of user interfaces. I really enjoyed this article becuase it is the first mention of quantitative metrics for analysis. Its great that you could take what we read about in this chapter and apply the same formulas to Amazon, Google, Yahoo, and see how they rank up against each other in some common simple and similar tasks. The article basically creates standardized notions of different subtasks, and how long they take, and then builds tasks as a collection of these subtasks, and then adds up the time of the subtasks and estimates a time for finishing a task. This chapter really places an emphasis on "efficiency", that is the interface that will allow you to finish your tasks as quickly as possible. There are some simplifications and oversights here. For example, users might be willing to tradeoff an interface that takes slightly longer than an other interface but it looks and feels a lot nicer. Which is the better interface, and which is the interface that more users will choose? Probably the one that feels and looks nicer, even though it may take slightly longer to accomplish a given task. This was illustrated in the example Rasin gave, where his most "efficient" interface was slightly confusing and not clear.
Roland Carlos - Oct 09, 2006 12:18:47 am
Is there a way where we can show users if another click would result in a double click situation? Maybe some sort of graphic on the screen, it flashes red if the next click will be a double click, green otherwise? Although the point of such a graphic is kind of limited since the double click requires an action so quick that you probably can't see the red graphic for that long anyway.
I've been constantly surprised by how much math there actually exists in the interface design world. I didn't believe it that easy to quantify user's actions, or put everything into formulas. But the reading seems to make it so easy. But as with before, it makes so much sense after reading it, you do need concrete and quantifiable goals to reach for, otherwise how will you know when to stop. When "75%" of users say that it works? The success of any good project is tied to how detailed the requirements are and even in this case you need them.
Huangnankun - Oct 09, 2006 11:09:56 am
The article talks about the GOMS model which is a set of rules which allows us to calculate the time it takes for a user to navigate an interface. The GOMS model assigns different time scale to different actions which a user can take on an interface. By adding up all the steps it takes to perform a certain operation on the interface, we are able to get a rough estimate of the time it takes for a user to perform a certain operation.
Out the output side of the interaction equation, the GOMS model introduces the concept of information efficiency and the time it takes for the interface to present different types of information messages.
The article then talks about errors, at first part it introduces the double click error and later on gives an detailed explaination of clicking errors in terms of the Fitt's law, which depends on the dimension of the target. This can be seen in real life, where many users find Mac OSX more user friendly due to its large, distinct icons compared to the small ones in windows. The dock in mac OSX also have icon shortcuts which magnified when the mouse hover over it in order to minimize misclicking errors.
Yang Wang - Oct 09, 2006 11:27:57 am
I found GOMS to be very interesting in determining how good a design is. As an engineer, I found myself constantly try to find quantative information in describing things. It is very interesting that the author broke down a process into M, P, H, K, and put them into formula to calculate the real time of a design. The is truly a novel idea.
But yet I find this process a little questionable in reality. The biggest problem of which is the mental process time. How is it possible to measure how long a person take to process that information unless we do a test sitting with a potential user, since the changing of the position of a button can double the time an user process the information. But even for that, there are significant differences in people's mental processing power. How will we be able to evaluate and give an average.
However, I am not trying to undermine this method, but like the author mentioned in article, it is not for evaluation, but for comparison
Joe Hart - Oct 09, 2006 11:21:39 am
The math behind human performance is of dramatic concequence to the user interface. Just how many things can a user process at one time... How long can you expect the user to respond messages and information. Other interesting questions like after how many messges does a user stop paying attention, are also questions that can probably be quantified. Double clicking is an interesting area to apply these metrics. I often notice that the most novice users of computers (even trough to expert) have problems knowing where to single/double/triple? click on things to get their desired result. Response time of the system is crutial to giving the user the feedback necessary to know when to stop clicking. Many instances of an application can result from bad feedback / computer response. Maybe the mac has an advantage with only having one button on their mouse.... however, I notice that haveing a right click option in windows is something I rely upon greatly. Maybe Hick's law can be circumvented by allowing the user to do more complex tasks that complete more in one action to overcome the increased time spent processing the task in the mind.
David Eitan Poll - Oct 09, 2006 11:32:34 am
The GOMS concept is an interesting and useful one indeed. It provides a way of quantifying what would otherwise be a completely subjective analysis of the actions that must be taken to achieve a goal. In the past, I had heard of the "number of clicks/keystrokes" as a measure for the effectiveness of an UI, but I think this takes the analysis one step further, incorporating mouse movement, mental preparation, and other such factors. It provides a useful tool that helps us take advantage of locality, both temporal and spatial, and allows us to more objectively judge how well an UI meets temporal and spatial goals.
Anirudh Vemprala - Oct 09, 2006 11:46:38 am
In this article, Raskin discusses the quantitative side of interface evaluation by discussing the GOMS model, Hick's law and Fitts' law.
The GOMS model uses a series of constants corresponding to keying in characters, pointing towards a position, moving a hand from the keyboard to an input device or vice-versa, mentally preparing oneself, and response time for the computer. By evaluating the number of times each constant is used in completing a task through the designed interface, a designer can estimate how efficient the interface is (in comparison to an ideal model). The ideal model is established through an information efficiency method that Raskin discusses in much detail.
Raskin also discusses the importance of Fitts' law (the relationship that links time to moving towards a target with the target's distance and size) in interfaces through the example of the Mac & Windows title bar. He also discusses Hick's law, which the time to make a decision and the number of options available to a user.
Robert Held - Oct 09, 2006 11:46:45 am
I found the quantification of the input process to be rather interesting. However, I would like to know the number of people they used to find the average values. In particular, it would be important to know how familiar the subjects were with the test interfaces before their reactions were measured. I also enjoyed what was essentially the last point in the chapter. Raskin stated that one large menu of several items is usually preferable to several sub-menus. His statement was based on Hick's law, but I would have appreciated a more in-depth discussion. For instance, does it matter if all of the menu items are related to similar topics? It seems like all of the quantification studies are well intentioned and produce predictable results, but that user interfaces also involve certain aesthetic and intuitive qualities that cannot be conveyed with numbers.
Kimberly Lau - Oct 09, 2006 12:00:38 pm
Oftentimes, a long machine response time R can negatively influence the other factors of the GOMS model (K, P, H, M). Whenever a user action does not elicit an immediate response, the user nearly always questions whether his action was or was not registered. The system may actually just be slow, but usually people will repeat their action until they receive some response. As such, when the computer finally responds, the result is that it will have recorded the original, intended user action, plus all the proceeding repetitions, so the user will need to undo everything. On the other hand, if the user does wait for the system to respond accordingly, he will likely become agitated over lost time and lose concentration or try to compensate by typing faster or performing following actions quicker. This has more potential for mistakes and ultimately slows the process.
Raskin notes in his paper that there are some dialog boxes with information efficiency E = 0. Although these boxes may slow the overall process down because users must click the boxes away, I would argue that having an "unnecessary" dialog box that gives users a response will ultimately take less time than when a late or no response is given (as described above). System response is always wanted.
Melissa Jiang - Oct 09, 2006 11:57:12 am
I find that I do not really realize when I am double clicking or single clicking anymore. When others stated that they observed new users double click on many things that does not require doubling clicking, I started looking what I do. I find that I actually do not double click that much as well. Most mouse usage I do require only one click and many times, I use keyboard shortcuts also. Is double clicking really that necessary?
As for Hick's Law stating that having 8 menu items being select is better than having 2 sets of 4 seems somewhat weird. True, for a certain small amout of number, having all the menu items display will be easy. However, when it gets to the point of above 30 items to select, it would take the user a long time to figure out what thay have to select. The sheer amount of choices can be overwhelming. Therefore, I question whether the number (as convincing as it seems) is actually accurate or not.
Tom McClure - Oct 09, 2006 11:55:58 am
Raskin Ch 4 I loved the sidebar on double dysclicksia. I have observed far more people who misunderstood double-clicking than who have learned when and why to double click. The most common coping mechanism is the user who finally learns that some things require the double click and then just double clicks everything from then on. One such user defended this action as "just in case," and had no intention of changing the behavior even after being warned that the second click could have dangerous unintended consequences. It was more important to the user that they not be frustrated by having singled clicked when a double click was required. I think historically the double click rose to popularity on the apple machines, that until very recently offered only a one-button mouse -- I can see why this design choice was made (in the interest of simplicity) but the consequent limitation in user expression (or "bits of information," to borrow the terms of this chapter) and the resulting rise in widespread user confusion has been disastrous.
Fitt's Law On the other hand, many of the UI decisions made at Apple have been brilliant. I never thought too much about the difference in where the application menus are between Mac and Windows (except to occasionally curse them both for not standardizing the location across the two OS's since I frequently use both in a single day). Similarly, the positioning of the "Dock" at the bottom of the screen in OSX, following this same design principle, must be commended.
GOMS I imagine that the application of GOMS to just about anything would be extremely tedious, and Raskin appears to agree with me, finding it useful only in resolving arguments when there are two differing opinions about which interface is the most intuitively efficient, without having to organize a focus group. In that context, it may provide some value, ie by helping to articulate the argument. His recommendation for applying it only at those points of the application that will get the most use also seems prudent.
Vahe Oughourlian - Oct 09, 2006 11:48:24 am
Like the previous reading, this reading attempts to quantify human capabilites in regards to computer interaction. While decidedly more simple than the previous reading (and so much easier to understand), I still have doubts regarding to quantify human reaction times. Again, while this may be backed up by emperical data, I don't really buy trying to mathamatically define the human interaction. I do like the ideas of not lying to users with certain "infinite" loading bars and retaining responsiveness in the program (something that only really became available in the multithreaded programs of OSes after Windows 98 and still occur even now in programs like iTunes).
The double-click thing is funny for me personally since I used to be a computer tutor, and getting people to time the clicks correctly, clicking without moving, and figuring out what to click doubly or singly is a real problem. Sometimes users continue to double-click items that require single clicks to use, and because it doesn't seem to complain, they use it everywhere, even on menu items, which usually require a single click.
Michael Udaltsov - Oct 09, 2006 12:25:28 pm
I wanted to discuss the two interfaces presented for temperature conversion. The first one, which uses a dialog box is fairly simple, however half the time it requires switching modes between F->C and C->F. Also, input is only allowed into one text field. I think a better interface would be to just have two editable text fields, one for C and one for F, such as: ( ____ C <=> ____ F ). This way, the user could input the temperature in either measurement, and the program would convert it and display in the other text field. This would eliminate the extra time needed for switching modes, and result in a faster interface. The later example that converts one text field to both units simultaneously seems easier to use because it omits the mode selection, but at the same time it's confusing, since it doesn't make sense to get two outputs from a single conversion. In the case of the presented converter, one of the outputs would be incorrect, and it's up to the user to recognize that only one of them is correct.
The second GUI uses a thermometer representation that seems overly complex. There are two thermometers that are at different levels (though measuring the same temperature), and additional compress/expand scales buttons that may be confusing. As the presented analysis shows, the interface is bad, since even a perfect user would take over 16 seconds to use it. However, I think the graphical representation may be easier to use if the interface is simplified. First, it's better to show just one thermometer with a draggable temperature level. On the sides of the thermometer, show the Celsius and Fahrenheit temperature measurements. This is more consistent with the typical wall thermometers that show both Celsius and Fahrenheit temperatures. Instead of Compress and Expand buttons, the thermometer could simply scroll up and down when the temperature level is dragged too high or too low within the measured area. This should greatly reduce potential errors, and improve usability for users.
Of course, since these were just examples for measuring speed and efficiency, it's understandable that they are not presented as examples of good UIs, and can be improved.
Julius Cheng - Oct 09, 2006 12:25:34 pm
Like the last reading, chapter 4 of Raskin's cognetics book provides mathematical formulae to quantify user/interface reaction times. While the last reading attempted to model actual cognitive processes, this reading is grounded in empirical fact. It's perfectly reasonable to say that the time it takes for a user to do something is the sum of the time it takes to do each task element. And it's no big debate that the elements are basically the keystroke, machine operation time, user preparation time, and so on (though one might contest Raskin's method of subdividing a task into elements).
Because there was a lot more truth in this reading, I gained more from it. While the last reading provided a useful model of the human mind, this reading provides something far more concrete and useful to us as we work on our own interfaces.
I also found the section on double-clicking pretty funny. Most of us have had double-clicking mishaps, and I'm no exception. But since I've been using a mouse for many years now, I've started to automatically correct my errors without even noticing that I make them (a double-clicking error doesn't usually result in something really unwanted happening that requires my full attention to deal with). I don't why double-clicking was invented in the first place. Maybe to make the hardware easier? The Unix machines here in the Soda Labs use the middle mouse button to perform actions, and wow, I wish Windows made better use of the middle button. I think some applications have, but not to a useful degree.
Dexter Lau - Oct 09, 2006 12:36:51 pm
Quantitative analysis for GUI design is a rather haphazardly science diluted by averages for basic motions/tasks/keystrokes. It is good for initial GUI design, easily applying the 0-5 rules for basic interfaces. Better measurements would be actual time samples of how fast users can navigate through the interface. Efficiency is measured as the minimum amount of information necessary to complete a task divided by the amount of information the user must supply. It can be easily noticed that the more information that a user needs to require for a task, the less efficient it becomes. The ideal situation is providing exactly what is needed in order to complete the goal, like a light switch (on is on, off is off; you don’t need to include other information like your name or why you want the light on). Also included in the reading are Hick’s and Fitt’s Laws. They deal with deciding what to do and then doing the proper gestures to accomplish that task.
Leo Chen - Oct 09, 2006 12:35:57 pm
It was interesting to see how you would put actual numbers into what I consider a subjective evaluation. Although I agree that the time a user takes to complete a task should be part of the measurement, I don't believe that it should be completely emphasized. There has been some discussion on the confusion behind double clicking and clicking. There would be a decently easy way to have a feedback mechanism that would tell the user whether to double or single click. You would just need 2 different kind of hover cursors. When your mouse goes over a button that's double clickable, change it to a different cursor than the one it would change into if it was a simple one click button.
Sung Yi - Oct 09, 2006 12:47:00 pm
This is an interesting article for showing different timings for different gestures. However, I wonder how accurate the time could be represented with formulas, since they could possibly be varied upon the situations. Also, for the temperature converter interface, I think it will be much more prolific if we get rid of the radio buttons; instead, we can label each box with "Celcius" and "Ferenheit," and make the arrow point to both ways. When the user wants to convert from C to F, he/she can type on the left box, whereas he/she can type on the right box for the other way. This way the "P" time can be reduced.
Yen Pai - Oct 09, 2006 12:44:40 pm
The methodologies used to quantitively measure efficiencies of user interfaces are clever and useful. A question that is raised for me is how are quantitive measures such as GOMS used in conjunction with qualitative assessments like prototype testing and contextual inquiries? Or are they considered different stages of the process. Also, is there a way to qualitatively account for habit acquisition and user "automaticity?"
Siu Pang Chu - Oct 09, 2006 12:22:28 pm
The reading is really cool that we can predict the respond time for a interface through the GOMS calculations. Then we can compare different designs or systems quickly. Goals, Operators, Methods, and Selection rules (GMOS) is an approach to human computer interaction observation. It divide the human action into four types: K for Keying, P for pointing, H for homing, M for Mentally perparing. So base on this equations we can reduce the respond time by figure out the large variable. The article also mention how two rules that help us to do this, for example,Fitts’ Law say the things that we use more often should be larger button and closer to the average position of the user's cursor.Hick's law says it takes log to the base 2 time the number of choice time to choose one of n options when the possibilities one of them is equal.
Siyan Wang - Oct 09, 2006 12:54:36 pm
This reading is pretty interesting in that it delves more into actual numerical analysis of interface efficiency rather than just "how it feels" to users (which is probably just as important). However, since GOMS requires the tasks to be rather well defined, it seems rather limited with interfaces that are more complex than that simple Celsius <-> Fahrenheit converter. The access to the interface elements might be easy to analyze with GOMS, but actual tasks the user performs, such as editing in Photoshop or something, would be much more difficult it seems.
Anton Mikhailov - Oct 10, 2006 07:39:14 pm
The part I enjoyed most was the comparrision between mac and windows menu bars. Although I'm die hard anti mac that is definitely good interface design. It comes, however, at the horrible tradeoff of 0 feedback about what program that menu is actually attached to, which I cant stand. The other interesting part was the efficiency of messages. I am in total agreement with the 0 efficiency warnings thrown by many interfaces. Alerts such as this should show up somewhere off to the side, and draw attention through sound or visuals. They should be timed and dissapear unless you press the button to read it for longer. Only fatal and terminal errors should pop up like that, not when word finishes searching.
CharlesLeung - Oct 15, 2006 03:49:21 pm
At first I thought that it was kind of strange to quantify how long it would take an average user to use the temperature converter using the GOMS method. But after finishing the reading, I realized that it's necessary to have a kind of quantitative metric to estimate how long a user needs to take to complete a certain task. Although to me this seems like a subjective kind of measurement, GOMS provides one way for the designer to try to anticipate how long a task will take earlier on in the design process without needed to actually test specific users.
I think that their way to save time with the temperature calculate is very clever, and I think that if I were to keep GOMS in mind, I would be much more likely to think of that kind of refinement. By using the GOMS method, the designer is quickly able to look at what seems to be redundant and make the necessary changes to improve the design. To me, their second design wouldn't have been very intuitive to me as a designer and perhaps GOMS is important because it makes the user think outside of the box.
Jae Chang - Oct 16, 2006 02:56:06 am
Comment1: The GOMS tool allows us to focus on modeling process and timing as well as evaluating. GOMS seems to have lots of disadvantages. The major disadvantage is that it works on goal-directed task only. Also, by comparing GOMS with KLM, GOMS is a very complicated method and takes lots of time, skill, and effort. Moreover, the result is not accurate because it assumes that tasks are performed by experts without errors. However, GOMS is a very useful tool even if there are many disadvantages. First of all, it gives qualitative and quantitative measures of given user interface. Also, it allows us to evaluate UI without any users so that the result can be gained very easily and quickly. When UI is revised, it is very easy to modify using GOMS.
Comment2: The quantification using GOMS Keystroke-Level Model is a very interesting article for measuring user’s time to accomplish a task with different interfaces. The KLM rule seems hard to understand at the first time, but I found out that it is very reasonable approach after understanding that the KLM rules are built on human behavior; for example, pressing enter after typing a command does not need time for mentally prepare. The different designs of the temperature converter were very good examples of evolving the design based on the KLM. However, the last example, Figure 4.5, seems too much focused on timing; the interface may generate confusion because the typed temperature converts in Celsius and Fahrenheit both. Nevertheless, I believe that, by using KLM tool, UI designers can easily evaluate their design very well and improve the design by considering the rules.
Aleksandr (Sasha) Ashpis - Oct 16, 2006 06:18:17 am
- I have personally run across the double clicking dilemma. The same experience also taught me how much experience makes me take for granted when using a computer. When I was teaching my 80+ year old grandfather to use the computer, he was having issues with the double clicking, where the rest of the basic operations he got down. The two problems he had were: one, due to age, he was at first having difficulty pressing the button twice fast enough, since he consciously needed to think about what he was doing, eventually with some practice we got over that hurdle. The second issue he was having was that he didn’t know when to use the double click feature, when learning to use the computer, my grandfather took a very manual based approach, he would write down what I told him, and what I did usually with a small diagram, thus making it hard to mark when a double click is appropriate.
- It is remarkable to me that user interaction with a computer can be quantitatively modeled and recorded in scientific experiments, but according to the article GOMS does just that. According to GOMS, it is faster to type things in than to use the mouse, even if you exclude the homing time. If this is true, then it was clearly not an efficiency idea to move away from command prompts, but I guess usability and mass consumer markets won out ahead of a two fold increase in interface efficiency
Qingyun Tang - Oct 16, 2006 08:54:21 am
- It is quite strange that the article first talks about how inaccurate measuring the time of operating over an interface could be, and then states the more completed GOM model won’t be discussed in the article. I think it is very important to give a user some sort of feedback after interacting with computer in a short time; otherwise the user becomes upset and will think s/he did something wrong or the system is failing. Not all programs are able to complete their tasks in a human reaction time, but interfaces always can. We as designers should always let users know the exact action s/he is doing.
- Unlike the previous articles, this one contains a lot of seemingly accurate calculation to reflect the quality of interfaces. I really highly doubt the accuracy of the calculation since the author himself mentioned early that the measuring of the time of operation is inaccurate. How would you use the inaccurate time to determine the quality of an interface? Some interfaces with longer operation time might actually be better. However, I do recognize the information efficiency of interfaces as a very important aspect of HCI designing.
Charles Lee - Oct 16, 2006 12:21:48 pm
Quantification 1: I am wary of the numbers and formulae provided, due to the fact that it is difficult to accurately measure durations to such precision. Trends and relations or proportions are useful, but formulae seem extremely presumptious to me. Given the other nonquantitative measure that go into a user interface, I would never use these formulae as a rule, only a rough proportionate guideline.
Quantification 2: The M, P, H, K terminology provides an easy way to give estimates on times, but in creating an abstraction, it eliminates much of the contextual information that influences the times a user takes to actually do an action. The type of user input affects response time, it seems that the context would be orders of magnitude more important. Thus, effort would be better spent on other factors.
Jonathan Chang - Oct 18, 2006 09:12:48 am
It's always interesting to me when someone takes the time to work out a formula for some natural process I'd taken for granted. Something like GOMS or KLM is, of course, an estimation only of how long it would take a user to do something, and it's based off of experimentation (I can't imagine how it could be based off anything more indepth) so the results aren't anything to set your processor to in the way the author is implying. This just means you shouldn't be taking the numbers as gospel though, it doesn't make it completely useless.
I could see something like Fitts' law, for example acting as a general guideline that galvanizes interface designers to place things in a more easily accessible manner. Take Mac interfaces versus Windows; its hard to say what it is, but something about a Mac interface is just easier to work with, isn't it? Fitts' law sort of defines what that is in a way for developers to aim at; a hard equation where they're trying to hit somewhere else on the curve.
Eric Vacca - Oct 19, 2006 12:05:24 am
I think these models of human actions are good only as guidelines. However i think that it takes design away from the focus, the target user. KLM, GOMS and Fitts law assume ideal situations and ideal targets, and that is never the case, so what meaning does 2.3 seconds mean to copy a word when that figure can be off by quite a bit depending on the user type.
Keenahn Jung - Dec 07, 2006 10:59:57 am
Raskin: The GOMS model is good in that it provides an actual quantifiable measure of time it takes to perform tasks. Of course it is just an estimation, but still, this can quickly give "back of the envelope" type results, that can be extremely useful in the prototyping stages of design. It is also good for comparing two designs to see which is more efficient. Ideally, the most common tasks should be accomplished in the fewest number of actions. The GOMS model can definitely help in this respect, even though it is a fairly crude estimation.
Raskin: Fitt's Law is not really a law at all but an estimation. During the discussion of Fitt's Law, I saw no reference (other than to his own studies) to empirical studies that show how Fitt came up with his law. Personally, I like my buttons to be close together. This minimizes the distance I have to move the mouse, but maximizes the chance of error. Fitt's law does not really account for this, because the average distance and size I have to move the pointer is the same for all the buttons, but if the buttons had been spread out more, the distance would be increased, but there would be less chance of clicking the wrong thing. I would like to see a model that incorporates the percentage of error of clicking on an incorrect thing, or a model that takes into account the time it takes to correct such an error.
Robin Franco - Dec 15, 2006 12:31:14 pm
Comment 1: This concrete way of determining the efficiency of an interface is exactly the type of information I've wanted to learn in the class. Much of the other material we covered is more general ideas used for eventually coming to a plausible interface solution. With this reading, I learned of a very good way of determining if the new found solution is actually an improvement on the old ones.
Comment 2: The mention of the “double dysclicksia” problem was a little humorous to me because I have encountered this problem when teaching my parents how to use the computer. Their inability to both be able to double click and then know when to double click was frustrating to them. Sometimes it feels that the whole need for double clicking can be removed. This might seem radical, but Apple has a similar approach. In their approach, however, instead of removing the double-click, they've removed the right-click. Most of the standard mouses shipped with new Macs come with a single button. This forces software developers to not have to rely on the right-click which therefore improves the experience for all. My proposal is to keep the right click, but remove the double click instead.
DavidWallace - Dec 15, 2006 07:32:38 pm
Raskin 1: I love Fitts' Law. It's a great example of a quantitative user interface guideline. A useful corrolary to Fitts' law would be the chance of error if the user takes a fixed amount of time to navigate to a button. If the time is short and the button small and far away, the chance of error would be great. One of my main complaints about Safari is that the tabs have close buttons on them, instead of a single close button at the end of the tab bar that applies to all tabs. Because the "dangerous" close buttons are mixed in with the often-clicked tabs, you have to carefully avoid errors when selecting a tab, which slows you down. If the close buttons were moved away from the tabs, the cost of an error would decrease, and you could change tabs more quickly.
Raskin 2: When learning GOMS I felt that it was too simple an approximation, and that the times given were too long. "I can do it faster than that," I thought. When it came time to apply it, though, I realized the value of a simplified approximation. User testing is expensive and slow, so any way to avoid it is valuable, even if its accuracy is less than perfect. I also realized that the reason I can use computers quickly is because I can predict what's going to happen next and prepare for it -- and in unfamiliar situations, this is impossible, and GOMS timings make more sense.
