I'm going to try to consolidate both blogs here if I can. I may separate them if it becomes necessary.
For Module 2, I'm going to say something funny.. Usually when you learn things, you get a more advanced understanding of a topic. This module however has given me a much simpler understanding of HCI. I don't mean it's simple as in easy, just that I'm gaining an understanding of the terminology and how it all works together in what's really little more than common sense. I don't mean to belittle anything. I'm sure it is the goal of this module to make sure the basics are well-established before the more informative modules to come.
Most of what I've gained through this module is a deeper understanding of the human and system characteristics I've always taken for granted. For instance, I've always known on some level that humans are prone to errors due to misunderstanding, but what this module has illustrated is that cause of that misunderstanding is often the conceptual model, and the conceptual model is a product of the design of the interface. What I find absolutely fantastic is that I could keep explaining that the problem with the design of the interface is most likely the gulf of evalutation and so forth and so on.
I suppose what I'm really trying to say is that I don't feel like I've learned anything revolutionary in this module, but I've gained a much greater depth to the things I already knew, and now I know why I know what I know.
Sunday, February 17, 2008
Sunday, February 10, 2008
Norman Blog 1 - Andrew Lane
Chapter 1:
While I thought this chapter was mostly a lesson in common sense complicated by adding fancy buzzwords such as “Conceptual Model,” I did get one lesson out of it that hits somewhat close to home. I’m a software developer by trade. Most of my development is improving an existing product. Many times I create an innovative new solution to a problem that is intended to make things more transparent and easier to use for the end-user. My latest was a scheduling feature that allows customers to schedule services based on different times of the week. It’s taken years to get a comprehensive structure to handle the kinds of requests we take due to the enormous complexities of time, and once I finally created a working solution, creating an intuitive front-end control for it was no small task. It took me weeks to design this one webpage to control scheduling. There are around 100 options on the page that users can use if they need, but only 5 are visible up front, and many of the options should very rarely ever need to be used. Everyone who sampled and tested the page before it was released to the public was very impressed with the flexibility, new features and clear instructions, so it didn’t take too long to get it implemented (I was also facing a November 4 deadline because the new scheduling system was necessary for daylight savings time). Once the system went in however, it was a totally different story. We had always had a complicated scheduling system before this, but the new array of controls amplified the visibility of the complexity, and everyone was terrified to use it. Several users had problems with it, doing operations I had not anticipated. They were able to do them, but it wasn’t straight-forward exactly how to do it.
Chapter 1 in the text goes through many such examples where something may be brilliantly designed by one person, but when it comes to actual usage, it’s not as brilliant after all.
Chapter 2:
I don’t believe I’ve had too many issues with false causality, wrong human explanations, or naïve physics, but the beginning of the chapter reminds me of something I did right with the web page mentioned above. Once the user drills past all the easy, quick-configure options on the page, they can enter manual values. I purposely made this section more difficult to reach because common operations can be done with just a few clicks instead of manually entering start and stop times for each day of the week. This final control set can have anywhere between 4 and 400 options to configure. You can probably imagine how that has the potential to get very complicated very quickly if the user doesn’t know how to use it. This ties in with the first part of the chapter where it talked about anticipating user error. The control set checks itself, reports a graphical interpretation of the user’s commands, and will even highlight user errors. If a user over-complicates a schedule, they can also click a “simplify” button that aggregates like schedule sessions together and minimizes the amount of controls they have to deal with. No lessons learned on this chapter, but at least I have some justifications for what I’ve done.
Chapter 3:
This chapter was an interesting read. It didn’t inspire any great revelations like the last two, but it did remind me that I need to get a program to store my hundreds of passwords for bank accounts, credit cards, work accounts, email accounts, social networking sites, and this blog site.
While I thought this chapter was mostly a lesson in common sense complicated by adding fancy buzzwords such as “Conceptual Model,” I did get one lesson out of it that hits somewhat close to home. I’m a software developer by trade. Most of my development is improving an existing product. Many times I create an innovative new solution to a problem that is intended to make things more transparent and easier to use for the end-user. My latest was a scheduling feature that allows customers to schedule services based on different times of the week. It’s taken years to get a comprehensive structure to handle the kinds of requests we take due to the enormous complexities of time, and once I finally created a working solution, creating an intuitive front-end control for it was no small task. It took me weeks to design this one webpage to control scheduling. There are around 100 options on the page that users can use if they need, but only 5 are visible up front, and many of the options should very rarely ever need to be used. Everyone who sampled and tested the page before it was released to the public was very impressed with the flexibility, new features and clear instructions, so it didn’t take too long to get it implemented (I was also facing a November 4 deadline because the new scheduling system was necessary for daylight savings time). Once the system went in however, it was a totally different story. We had always had a complicated scheduling system before this, but the new array of controls amplified the visibility of the complexity, and everyone was terrified to use it. Several users had problems with it, doing operations I had not anticipated. They were able to do them, but it wasn’t straight-forward exactly how to do it.
Chapter 1 in the text goes through many such examples where something may be brilliantly designed by one person, but when it comes to actual usage, it’s not as brilliant after all.
Chapter 2:
I don’t believe I’ve had too many issues with false causality, wrong human explanations, or naïve physics, but the beginning of the chapter reminds me of something I did right with the web page mentioned above. Once the user drills past all the easy, quick-configure options on the page, they can enter manual values. I purposely made this section more difficult to reach because common operations can be done with just a few clicks instead of manually entering start and stop times for each day of the week. This final control set can have anywhere between 4 and 400 options to configure. You can probably imagine how that has the potential to get very complicated very quickly if the user doesn’t know how to use it. This ties in with the first part of the chapter where it talked about anticipating user error. The control set checks itself, reports a graphical interpretation of the user’s commands, and will even highlight user errors. If a user over-complicates a schedule, they can also click a “simplify” button that aggregates like schedule sessions together and minimizes the amount of controls they have to deal with. No lessons learned on this chapter, but at least I have some justifications for what I’ve done.
Chapter 3:
This chapter was an interesting read. It didn’t inspire any great revelations like the last two, but it did remind me that I need to get a program to store my hundreds of passwords for bank accounts, credit cards, work accounts, email accounts, social networking sites, and this blog site.
Subscribe to:
Posts (Atom)