In my work as a software developer, I’m involved in every step of the systems development lifecycle (SDLC). That includes feasibility, analysis, design, development, testing, implementation and maintenance. Most of my day-to-day work revolves around maintenance, but occasionally, I take on new projects. The most exciting and crucial parts of developing are the analysis and design. In fact, the design is based directly on the analysis, so usually I consolidate these two parts of the SDLC into the same step, actively drafting designs as analyses are performed and presented.
Module 4 of this course deals with analysis. In software development, my approach to analysis is almost always the object-oriented approach. It’s critical to understand the objects you’re dealing with and the way they relate to each other. If you neglect part of an object and don’t include it, it can be costly to add it as an afterthought, however, it’s one of the easier problems to rectify. The more difficult lapses in analyses are when a relation isn’t correctly realized or when an object is left out of the model completely. Usually, such mistakes are caught during development, but if they are missed, then there can be terrible consequences when the final product is released. The typical consequence of such a lapse is that the customer discards the product, as it does not suit their needs, and in order to include that missing object or correct that relationship, it usually means a large portion of the program has to be completely rewritten, sometimes even the entire program. Clearly, analysis is no small step.
But where does Human-Computer Interaction come in to play? Obviously the software has to be designed correctly for humans to make use of it, but is that really the job of a human-computer interaction specialist? It seems to me that this is just a programmer’s design obligation. The text was correct in saying that human-computer interaction specialists are usually called in AFTER development to correct problems when it’s too late. I think the reason for that is that it’s not clear where one is needed until it is too late. Why would you hire someone to do someone else’s job you’re already paying? You may argue that it’s two separate jobs, but I think you’ll find most businesses will disagree. I suppose that’s why I’m taking this course, so I know what to look for. Unfortunately it has been less than enlightening so far.
Tuesday, April 15, 2008
Sunday, February 17, 2008
COMP 325 Module 2 COURSE Blog
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.
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 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)