commented on
Ben Carlston
Lei Gu
I understand that the reason why CHI accepted this paper was to have the experts use the paper and the authors for target practice. However, as I understand it, they are only cautioning the blind use of the newer ethnography techniques. They are recommending to the designers to also take other approaches to design into consideration, not just the new ethnography techniques. I don't see why this paper has such a bad rep. It is not unreasonable to request that other factors be brought into consideration before making design decisions.
Monday, May 4, 2009
Fitz Law
Commented on
Cole Jones
Brad Twitty
Josh Myers
The main point of Fitz Law was that the bigger and closer the item is to the edge of the screen, the better. The user can get to the object faster and a bigger target means it is easier for people to click on the item. I know my parents still have trouble clicking on the icons to make the internet run at home, so a bigger icon would make things a lot better for people. I think that Apple's Dock in Mac OS X works somewhat with this principle. The Dock can be attached to the side (top, bottom, left, right) and in some cases you can make the icons on the Dock bigger when you put your mouse near it. I think I turned off the setting for that though... :(
Cole Jones
Brad Twitty
Josh Myers
The main point of Fitz Law was that the bigger and closer the item is to the edge of the screen, the better. The user can get to the object faster and a bigger target means it is easier for people to click on the item. I know my parents still have trouble clicking on the icons to make the internet run at home, so a bigger icon would make things a lot better for people. I think that Apple's Dock in Mac OS X works somewhat with this principle. The Dock can be attached to the side (top, bottom, left, right) and in some cases you can make the icons on the Dock bigger when you put your mouse near it. I think I turned off the setting for that though... :(
Usability Evaluation Considered Harmful?
commented on
Brian Salato
Lei Gu
Source
"Usability Evaluation Considered Harmful (Some of the Time)" by Saul Greenberg and Bill Buxton CHI 2008.
The main point this article was trying to make is that usability evaluations, when performed without thinking it through, can be detrimental to creative design or innovative technology. They believe that the HCI community is negatively affected by this and proposed several ways to fix it.
First, usability tests is not the only method when performing user centered design and should be used when the problem and stage of user interface development warrants it.
Second, there are some times when usability testing is would not produce useful information, such as at the very beginning of design, when usefulness outweighs usability, and where the unpredictable culture affects how an innovative system is used.
Next, there are other ways other than using usability evaluations to validate the work, such as rationalizing the design, expected usage, case studies, and participant critiques. One of his complaints with CHI is that the conference specifies using a usability study, and in particular, a quantitative study. They believe that submissions should be judged based on the question, the system or situation described, and whether the inventors used a reasonable method to argue their points.
Fourth, the method of testing usablity tends to result in weak science. For novel innovations, they should use an existence proof, where they show one case where it could be use. For variations of already existing products, risky hypothesis testing is appropriate. Finally, there should be more help for others to replicate the results.
Lastly, they argue that HCI should look to other fields to determine worthiness. Design teams need to be able to differentiate between sketches, early designs, which are ideas that can quickly be changed, and prototypes, which are more finalized and thoughtout.
Commentary
I agree on some of the points. There are some things that are extremely useful but are designed poorly. I don't think they should be discarded. To paraphrase what I read in another paper, if the designers explain sufficiently why they designed something the way they did, it would be acceptable by the public.
Brian Salato
Lei Gu
Source
"Usability Evaluation Considered Harmful (Some of the Time)" by Saul Greenberg and Bill Buxton CHI 2008.
The main point this article was trying to make is that usability evaluations, when performed without thinking it through, can be detrimental to creative design or innovative technology. They believe that the HCI community is negatively affected by this and proposed several ways to fix it.
First, usability tests is not the only method when performing user centered design and should be used when the problem and stage of user interface development warrants it.
Second, there are some times when usability testing is would not produce useful information, such as at the very beginning of design, when usefulness outweighs usability, and where the unpredictable culture affects how an innovative system is used.
Next, there are other ways other than using usability evaluations to validate the work, such as rationalizing the design, expected usage, case studies, and participant critiques. One of his complaints with CHI is that the conference specifies using a usability study, and in particular, a quantitative study. They believe that submissions should be judged based on the question, the system or situation described, and whether the inventors used a reasonable method to argue their points.
Fourth, the method of testing usablity tends to result in weak science. For novel innovations, they should use an existence proof, where they show one case where it could be use. For variations of already existing products, risky hypothesis testing is appropriate. Finally, there should be more help for others to replicate the results.
Lastly, they argue that HCI should look to other fields to determine worthiness. Design teams need to be able to differentiate between sketches, early designs, which are ideas that can quickly be changed, and prototypes, which are more finalized and thoughtout.
Commentary
I agree on some of the points. There are some things that are extremely useful but are designed poorly. I don't think they should be discarded. To paraphrase what I read in another paper, if the designers explain sufficiently why they designed something the way they did, it would be acceptable by the public.
Sunday, May 3, 2009
The Inmates Are Running The Asylum
Source
"The Inmates are Running the Asylum" by Alan Cooper
This book seems to be for managers of software companies. Alan Cooper states that computers are spreading throughout every business field, so software design is getting more important. The title comes from the belief that software engineers are running the software company. No matter what the upper management say, the software programmers have the final say in how the program will be implemented. Although I was not aware of this, it does make sense. The managers usually are too busy to deal with the code.
In the first part, he describes how if you include a computer in everyday objects, you will get a computer back. He describes cognitive friction as the "resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes" and states that software interaction is very high in cognitive friction. He also coins the term, dancing bear, which represents something that does a lot, but really meets none of the requirements.
He stresses putting interaction design before programming in the product design phase, so it would go design->programming->user test / bug test ->tweak. This would save money in the long run, but it would take much more time. He equates it with the movie industry, where preplanning could take years and implementing the plan would take a relatively short time. The problem with this is that managers usually put unreasonable deadlines on the programmers. They don't seem to realize that the consumer would be more angry at a unfinished product, not a late released product. An unfinished product would do more to lower consumer loyalty. The typical problems with softare is that software forgets, software is lazy, software gives too much info, software is inflexible, software blames users, and software won't take responsibility.
He calls us Homo Logicus, which separates us from normal humans. I kinda agree with that statement, although I believe that something similar could apply to other disciplines such as the sciences and math. Also, he compares us with jocks from secondary schools and how the table is turned on our old tormenters.
To design good interaction design. we need to design for pleasure. Instead of trying to create one program for everyone, design for one subgroup and make them very happy. To do this, we need personas. We also need to design for power. We need to design based on goals, not tasks. The most important goal is personal goals and need to be careful of false goals. As a tie in with "The Media Equation" we can make software polite, which would be interested in the user, deferential to the user, is forthcoming, has common sense, anticipates user needs, is responsive, is taciturn about its personal problems, is well informed, is perceptive, is self-confident, stays focused, is fudgable, gives instant gratification, and is trustworthy. Finally, they need to design for people by using scenarios. Daily use scenarios would be the most important since those would most likely happen. One problem that programmers have is that we try too hard focus on the fringe cases.
Commentary
Overall, I think this is a good book and should be required for software engineering since that would've helped the project in there. I never thought of the fact that programmers have a lot of clout in the programs they design, but it makes sense since they own the code, and managers don't want to get rid of the good programmers. The design principles (design for people, pleasure, and power) is very important and the personas, personal goals, and use of daily scenarios could really help when I am assigned to projects in the future. Also, I never would've considered that I act like a jock with my computing knowledge, not strength.
"The Inmates are Running the Asylum" by Alan Cooper
This book seems to be for managers of software companies. Alan Cooper states that computers are spreading throughout every business field, so software design is getting more important. The title comes from the belief that software engineers are running the software company. No matter what the upper management say, the software programmers have the final say in how the program will be implemented. Although I was not aware of this, it does make sense. The managers usually are too busy to deal with the code.
In the first part, he describes how if you include a computer in everyday objects, you will get a computer back. He describes cognitive friction as the "resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes" and states that software interaction is very high in cognitive friction. He also coins the term, dancing bear, which represents something that does a lot, but really meets none of the requirements.
He stresses putting interaction design before programming in the product design phase, so it would go design->programming->user test / bug test ->tweak. This would save money in the long run, but it would take much more time. He equates it with the movie industry, where preplanning could take years and implementing the plan would take a relatively short time. The problem with this is that managers usually put unreasonable deadlines on the programmers. They don't seem to realize that the consumer would be more angry at a unfinished product, not a late released product. An unfinished product would do more to lower consumer loyalty. The typical problems with softare is that software forgets, software is lazy, software gives too much info, software is inflexible, software blames users, and software won't take responsibility.
He calls us Homo Logicus, which separates us from normal humans. I kinda agree with that statement, although I believe that something similar could apply to other disciplines such as the sciences and math. Also, he compares us with jocks from secondary schools and how the table is turned on our old tormenters.
To design good interaction design. we need to design for pleasure. Instead of trying to create one program for everyone, design for one subgroup and make them very happy. To do this, we need personas. We also need to design for power. We need to design based on goals, not tasks. The most important goal is personal goals and need to be careful of false goals. As a tie in with "The Media Equation" we can make software polite, which would be interested in the user, deferential to the user, is forthcoming, has common sense, anticipates user needs, is responsive, is taciturn about its personal problems, is well informed, is perceptive, is self-confident, stays focused, is fudgable, gives instant gratification, and is trustworthy. Finally, they need to design for people by using scenarios. Daily use scenarios would be the most important since those would most likely happen. One problem that programmers have is that we try too hard focus on the fringe cases.
Commentary
Overall, I think this is a good book and should be required for software engineering since that would've helped the project in there. I never thought of the fact that programmers have a lot of clout in the programs they design, but it makes sense since they own the code, and managers don't want to get rid of the good programmers. The design principles (design for people, pleasure, and power) is very important and the personas, personal goals, and use of daily scenarios could really help when I am assigned to projects in the future. Also, I never would've considered that I act like a jock with my computing knowledge, not strength.
Human-Centered Design Considered Harmful
Source
"Human-Centered Design Considered Harmful" by Don Norman
Summary
This article was mainly about how blindly following want the users want is detrimental to a product. He begins by saying that knowing one's users is very important. Current beliefs state that this is the most important part of designing a successful product. However, he points out that companies that are supposedly good at human-centered design still produce confusing products. He then points out that the car and some everyday objects were designed without user studies and they ended up being successful. The reason they are successful is that they follow activity-centered design principles. The designers developed it knowing what activities the product would perform. They take the previous design and improve upon it based on the problems they or their customers experienced. He also counters the argument that technology should adapt to human use by giving some examples of how we adapted to technology: the clock and watch, writing systems, and musical instruments. He argues that activity centered design can be successful if the designers can sufficiently explain why they designed the product that way. Activity centered design requires an understanding of people, technology, tools, and the reasons for the activities. His major problems with human centered design is that focusing on the individual person or group can make it easier for that individual but harder for everyone else, the people's needs today may be different from the needs of tomorrow, it distracts everyone from the support of the activities themselves, and too much attention for the needs of the users can produce a non-cohesive design.
Commentary
I have noticed a change in philosophy in Don Norman from his first book, The Design of Everyday Things, to this paper and his latest book, "Emotional Design". In the first book, his main point seemed to be that we need to focus on the user and the product should be easier for the user to use. Ease of use is important. However, like he said in this paper, strictly obeying the users could lead to a product that tries to please everyone, but disappoints them instead. That was one of the complaints we had when we read the first book. I agree that there needs to be a balance between the two. You can't ignore the users completely, especially when they complain, but the company knows what direction they want to go, so they should have the say in what goes into the program.
"Human-Centered Design Considered Harmful" by Don Norman
Summary
This article was mainly about how blindly following want the users want is detrimental to a product. He begins by saying that knowing one's users is very important. Current beliefs state that this is the most important part of designing a successful product. However, he points out that companies that are supposedly good at human-centered design still produce confusing products. He then points out that the car and some everyday objects were designed without user studies and they ended up being successful. The reason they are successful is that they follow activity-centered design principles. The designers developed it knowing what activities the product would perform. They take the previous design and improve upon it based on the problems they or their customers experienced. He also counters the argument that technology should adapt to human use by giving some examples of how we adapted to technology: the clock and watch, writing systems, and musical instruments. He argues that activity centered design can be successful if the designers can sufficiently explain why they designed the product that way. Activity centered design requires an understanding of people, technology, tools, and the reasons for the activities. His major problems with human centered design is that focusing on the individual person or group can make it easier for that individual but harder for everyone else, the people's needs today may be different from the needs of tomorrow, it distracts everyone from the support of the activities themselves, and too much attention for the needs of the users can produce a non-cohesive design.
Commentary
I have noticed a change in philosophy in Don Norman from his first book, The Design of Everyday Things, to this paper and his latest book, "Emotional Design". In the first book, his main point seemed to be that we need to focus on the user and the product should be easier for the user to use. Ease of use is important. However, like he said in this paper, strictly obeying the users could lead to a product that tries to please everyone, but disappoints them instead. That was one of the complaints we had when we read the first book. I agree that there needs to be a balance between the two. You can't ignore the users completely, especially when they complain, but the company knows what direction they want to go, so they should have the say in what goes into the program.
Undo and Erase Events as Indicators of Usability Problems
Source:
"Undo and Erase Events as Indicators of Usability Problems" by David Akers, Matthew Simpson, Robin Jeffries, Terry Winograd. CHI 2009
Summary
The authors of this paper wanted to study negative critical incidents which will show usability problems with Google SketchUp. They differentiated event-based reporting and self reporting. In this experiment, they used undo and erase operations for the event-based reporting and compared it with self reporting by the user. In the formal experiment, they had 35 participants from a variety of backgrounds. The experiment was 90 minutes and was separated into training to use SketchUp and identifying critical events, practice using the program, performing the modeling assignment, and retrospective commentary. For the assignment, the users were given specific instructions and told not to deviate from the instructions, and the commentary was moved to after the assignment was over because previous work noted that immediate commentary was disruptive to the process. The commentary portion included a series of questions about the critical events detected automatically (undo and erase operations) and/or self reported. The questions asked what was happening immediately before the event occured, was the problem surprising, what did the user do to get around the problem, and also if they reported it as a problem and if not, why. The commentary session paired off users as a speaker and listener. The listener would ask the question and judge when the question had been answered, and the speaker would talk about the event.
Results
The events were assigned severity based on how many operations detected it. Mild severity events were detected due to self reporting. Undo operations indicated medium severity. If all three methods were used, then the event would be catagorized as severe. Also they catagorized events based on frequency of the event and the impact of the event (whether or not the event would completely stop all work). After analyzing the data, the authors determined that undo and erase events detected about 90% of all severe usability problems. Similar numbers for the other catagories existed. Figure 1 shows a venn diagram of the results. Of particular note is the events detected only by undo or erase. When asked why the user didn't report the issue, many users mentioned that they blamed themselves and not the program, which is similar to what Don Norman said in "The Design of Everyday Things."
Figure 1
Analysis
I believe that this experiment showed some interesting results. I knew that undo and erase operations can show simple mistakes, but I never associated that they would use those operations to deal with usability problems. In hind sight, it made sense. I think that this experiment should be repeated with other programs as part of a usability test to see how to better design the interface to reduce the number of problems.
"Undo and Erase Events as Indicators of Usability Problems" by David Akers, Matthew Simpson, Robin Jeffries, Terry Winograd. CHI 2009
Summary
The authors of this paper wanted to study negative critical incidents which will show usability problems with Google SketchUp. They differentiated event-based reporting and self reporting. In this experiment, they used undo and erase operations for the event-based reporting and compared it with self reporting by the user. In the formal experiment, they had 35 participants from a variety of backgrounds. The experiment was 90 minutes and was separated into training to use SketchUp and identifying critical events, practice using the program, performing the modeling assignment, and retrospective commentary. For the assignment, the users were given specific instructions and told not to deviate from the instructions, and the commentary was moved to after the assignment was over because previous work noted that immediate commentary was disruptive to the process. The commentary portion included a series of questions about the critical events detected automatically (undo and erase operations) and/or self reported. The questions asked what was happening immediately before the event occured, was the problem surprising, what did the user do to get around the problem, and also if they reported it as a problem and if not, why. The commentary session paired off users as a speaker and listener. The listener would ask the question and judge when the question had been answered, and the speaker would talk about the event.
Results
The events were assigned severity based on how many operations detected it. Mild severity events were detected due to self reporting. Undo operations indicated medium severity. If all three methods were used, then the event would be catagorized as severe. Also they catagorized events based on frequency of the event and the impact of the event (whether or not the event would completely stop all work). After analyzing the data, the authors determined that undo and erase events detected about 90% of all severe usability problems. Similar numbers for the other catagories existed. Figure 1 shows a venn diagram of the results. Of particular note is the events detected only by undo or erase. When asked why the user didn't report the issue, many users mentioned that they blamed themselves and not the program, which is similar to what Don Norman said in "The Design of Everyday Things."
Figure 1
Analysis
I believe that this experiment showed some interesting results. I knew that undo and erase operations can show simple mistakes, but I never associated that they would use those operations to deal with usability problems. In hind sight, it made sense. I think that this experiment should be repeated with other programs as part of a usability test to see how to better design the interface to reduce the number of problems.
Subscribe to:
Posts (Atom)
