Book reading #2: Emotional Design, ch. 1

I don't see why these two philosophies can't coexist peacefully, but I do think that emotional design is very important for some things. Norman's first analysis of design as merely scientific and necessary seems cold and calculating, but this chapter seems very warm-and-fuzzy, and I prefer it. I'm currently looking at a bookshelf I refinished--it serves its purpose perfectly, yet I'm more attached to it than other furniture because I took care of it myself. Some things, though, don't need to be emotionally designed to be used well: microwaves, washing machines, televisions (I'm attached to my television because my parents gifted it to me, not because of its design or its function).

I'm confused that this is allegedly a departure from The Design of Everyday Things. Did I misunderstand him when he wrote about necessary aesthetics in Design? Did he really focus only on usability and neglect aesthetics? That's not how I remember, but I suppose I could be wrong. Obviously, he focuses more on aesthetics here.

The effect of happiness on productivity is obvious to me. When I get frustrated with work, I have to pause and try something that I'm better at so I can return refreshed and able to think more clearly. Of course it makes more sense to design something that makes me happier; why would I use it if it didn't? I have to come back to Design here, though--easy-to-use things make me happy, too. I'll just say that both philosophies have to be used. Useless things are frustrating, and pretty things make me happier, so let's make pretty, useful things.

Once again, I find myself wondering if he's over-thought this system. However, I should reserve judgement and remember that this work is important. It is vital to know how people react to various situations. Visceral reactions are most likely what affect our emotions most; for example, I strongly disliked the UT (sorry, t.u.) campus the moment I walked onto it for a visit for no particular, discernible reason, but I loved the A&M campus. Emotionally, I would not have functioned well in Austin, yet I find myself comfortable and successful here in College Station. Behavioral processing is essentially "programming", as is reflective processing.  I could be "programmed" to use any stove, but I have a visceral reaction to the one in my apartment (the electric heating elements annoy me because it's hard to tell which one is on). I use it anyway because it's available and it makes sense to use it.

All in all, Norman says that he's "changed his mind", but I don't really think so. I think he just considered a different perspective on design, switching from cold and scientific to actually considering the psychology of it all.

Book reading #1: Design of Everyday Things

Overall book reaction: Overall, The Design of Everyday Things seems to me like a 200-page rant on the difficulty of the technology of the late 1980's rather than a universal guide to designs. While the tenets of his argument are applicable to all technologies of modern times, I found it frustrating to read his examples because many of them reference things that have come to be in the last 20 years (e.g. the "pocket calendar" that connects to his home and work systems). I appreciate his analysis of usability and his design suggestions, and I wholeheartedly agree that some things have been horribly designed and continue to be that way. Many engineers have trouble designing their work to be used by the common person, and it's a wonderful lesson for us to learn; of course, this relates directly to human-computer interaction, and I feel that this book has been a good introduction to how to design systems for various users.

Chapter 1: I find it interesting that telephones have experienced such a simplification; the author references analog telephones as failing to have specific hold/mute buttons and difficulty with other functions, yet my iPhone handles these functions rather gracefully. Overall, I agree with the "U-shaped" technological development. Technological development may make things actually more complicated, but it seems there has been a shift to more simplicity in modern times. Continuing with the phone example, telephones once required memorized telephone numbers, but I can now call friends with a single tap without knowing their phone numbers. The complexity required to make this work translates to a simple user interface.

Chapter 2: Yes, bad design makes me feel dumb. I agree with Norman wholeheartedly about his assessment of learned and taught hopelessness, though I certainly hope that no one becomes clinically depressed due to an inability to open file cabinets and childproof medicine bottles. The stages of evaluation and execution are interesting; though I usually do these things quickly, I pay no attention and did not realize that it required so many discrete steps. Similarly, I never would have given names to the difficulty of operating something simple and understanding the environment (the Gulf of Execution and the Gulf of Evaluation, respectively). I did find it amusing that he referenced VHS as an up-and-coming technology, stating "In a while...There won't be any film, just video tape." Any previous dated references (e.g. the pictures of analog telephones) were just steamrolled by a huge one.

Chapter 3: I laughed again at Norman's reference to a miniature computer with a calendar, reminders, and alarms to put in his pocket. (I reached for my phone to put a few school due dates on my calendar a few moments before) However, I find myself nodding once again--he makes good points about our daily lives and how design affects them, especially in dealing with spatial memory and reminders. Like reading the second chapter, I felt myself wondering how many terms for these phenomena are really necessary. Natural mappings are very necessary and obviously enhance the aesthetics of any design because it just makes life simpler. I have long known about the difficulty of swapping short-term memory to long-term memory.

Chapter 4: It's interesting to note that most of Norman's suggestions for visibility have come to pass. DVRs record television shows and tell us what show we're watching, for example. His in-depth discussion of affordances, visibility, and feedback seem like common sense to me, though apparently it wasn't popular in the '80s and '90s (the apparent era of the book). Aesthetics are nice, sure, but we need to keep "function over fashion" in mind. I have a quibble with the light switch in my apartment living room--instead of going to the overhead fan and light, it goes to an electrical outlet. While this does give me a chance to plug in any lamp I want, I found it frustrating to discover this and find which outlet it corresponded with. All in all, I must just say that I agree with him yet again.

Chapter 5: From our beginning classes, we have been taught to integrate error-checking into all of our work. This may seem obvious to us now, but apparently system error-checking was not popular when this book was written. Honestly, it gives me comfort that walking into a room and forgetting why I'm there is not an uncommon occurrence for all people. Understanding the brain will actually allow us to develop better and better interfaces; naturally, we will learn better when our designs match our physiology. I also never really realized the complexity of most games--when we are presented with a wide variety of moves, we are allowed to think more, and that entertains us. Forcing functions surround us; I am particularly intrigued by his statement that a particular law once required cars to alert us to unbuckled seat belts and that the law was repealed. It's back, it seems, forcing us to buckle our seatbelts or endure incessant, loud beeping. Interesting to see things come full circle.

Chapter 6: It's still interesting to see that his predictions for future technologies have indeed been slowly developed over the years. I always knew that the QWERTY keyboard was a relic from typewriters, but I didn't realize why--it proves to be an effective method for typing, even though it initially seems completely counter-intuitive. Again we see that aesthetics are nice, but harkening back to chapter 4, we need to keep the idea of function in our heads instead of focusing on aesthetics. In my opinion, we should design what we need and then make it pretty. However, if it's efficiently designed, not much modification is needed to make it pretty. Designing for specific individuals is difficult but doable, and we need to keep the end-user in mind more than the designer. I'm slightly nervous about the ethnography now because of Norman's observation that designers are often not the users. I suppose I don't understand the problems with featurism--through this whole book, Norman has been extolling the virtues of easy-to-use, multi-featured devices (I assume he loved the Palm Pilot and graduated to an Android or iPhone in good time), but now he fusses about adding too many features. It's hard to address his analysis of computer systems merely because I never experienced the frustrations and revolutions that he did.

Chapter 7: Manuals are tough to read and I don't like them. I think that's the prevalent philosophy, actually, and it makes more and more sense to design intuitive interfaces. Essentially, that's all Norman is saying, but with detailed examples about mapping and possible downfalls of certain designs (like velcro). The technology director at my high school had the perfect sarcastic saying: "Standards are great. Everyone should have one." Norman clearly agrees with this (or rather, the opposite statement, I suppose), as do I. Standardization makes life easy not only for users, but for designers as well. I understand the merits of making things deliberately difficult (like childproof bottles), and I appreciate the well-planned designs for those devices. He speaks again of the possibilities of "future computers", and again I find myself amused.

Good Design:

The iPhone's call screen is a stellar example of good design. All necessary functions are within easy reach, and they are clearly marked and need no instructions. (yes, I called myself for this screenshot)

This is the best cheese grater in existence. It apparently took humanity a very long time to decide that putting a grater over a bowl makes life easier. This eliminates fallen cheese (or whatever you're grating), huge messes, and it even measures it for you. Perfect design.

This hair dryer revolutionized my bathroom organization. It's intuitive (built like every other hair dryer, basically), its cord retracts with an obvious button, and the handle bends. How does it bend? You just bend it. Can't get much simpler than that. It's a relatively low-cost feature that makes this thing awesome. Fantastic. (for anyone who doesn't know about hair dryers--that's a diffuser, not a ray gun attachment, and it's used for curly hair) 

The built-in plugs in the tables in the new engineering building (ETB) are excellent. The lid has an opening on one side with enough room for fingers to lift it; it's clear which side it opens on, and the plugs include power, USB power, and Ethernet. It's very convenient for working on campus with our various electronics.

Poor Design:

Strangely enough, I love my vacuum cleaner. I have only one gripe, and it is the two buttons on it. One retracts the cord and one turns the machine on; they're the same size, shape, and color, and they even have very similar symbols on them. Why couldn't they have made the cord symbol a little squiggly line or made the button black or blue?

I love my car, too, and I love that it has an auxiliary audio input. However, the little door to the audio jack flips down, not up, and it's hard to hold it with one hand while plugging in the cable. Granted, flipping down keeps it from getting in the way of the power outlet, but it's still frustrating. I'm not even sure why a little door is necessary.

I hate this type of light fixture. Changing the lightbulb requires removal of screws (if you can find them while straining on top of a stepladder) and perfect replacement of the bowl when you are finished. One errant screw and the glass breaks. A screw-in bowl or something similar would be a great replacement for this difficult design.

This fan is counter-intuitive. The rotating switch goes from off to high to medium to low. Why doesn't it go from off to low instead? It's flat-out dumb. I have to switch it quickly if I just a slight breeze instead of a tornado in my bedroom (it's a powerful little fan).

The shower control in my bathtub is terrible. It took me some time to figure out which way to turn the clear plastic to adjust the temperature, and the dial to control flow is lacking. It's either high or off. Clearly marking hot-cold or making them separate controls would have been preferable. Also it's old and horribly unattractive.

Reading: Chinese Room

The Chinese Room experiment is far more of a psychological theory than it is a computer science topic. Can a computer truly understand language? By extension, can a computer really understand anything? What is understanding? Searle argues vehemently that a computer can never truly understand anything, and to be perfectly frank, his writing makes him seem fanatic about his position and horribly indignant that others may disagree with it. While he makes a good point, he seems like a stubborn child shouting “NUH-UHHHH" when argued with. His support of his opinion is occasionally shaky, and his arguments are sometimes self-contradictory.

Personally, I agree that a computer, then and now, cannot truly understand anything; it is given 1's and 0's and spits out the expected response. In this case, a computer is little more than a parrot, repeating what it is told (this is, of course, not to say that a parrot does not have consciousness---I use "parrot" in the figure-of-speech sort of way). Technology for conscious computers may be developed in the future (of course, it has been the subject of a huge number of science fiction stories from Battlestar Galactica to the Terminator series), but until we can truly create a self-aware being, I think that no computer will be able to comprehend anything other than 1's and 0's. My opinion is based on the assumption that understanding requires consciousness, however, and that assumption is never explicitly stated in Searle's article--many of the replies to his theory seem to be based on fuzzy definitions of understanding.

One such reply is the "other minds" reply: it simply states that we cannot know how other minds understand the same things as ourselves. This makes perfect sense, but this paper makes it seem like Searle and the Yale responder are operating on entirely different definitions of understanding. Searle argues that he can, in fact, assume that other people understand things because they have cognitive states and that a computer does not. His writing makes it seem like he brushes off this idea quickly and without a second thought.

This all begs important questions, though: why is he so angry, and why does he care? Is he concerned that machines are rising and threatening to take over? Is he just looking for something to argue about? This paper is famous for good reason and poses a good question, but I feel like the question could have been asked and evaluated from both sides equally before a tirade was launched. Searle seems only like a man trying to throw a hissyfit instead of having an intelligent discussion.

Overall, I tend to agree with Searle's position, but his writing makes me want to disagree just to see (or read, I suppose) his reaction. I must add a disclaimer here: I don't know anything about Searle except for what I've read in this paper. He could be an extremely rational person, for all I know, who is mild-mannered and easy to get along with, so if I have offended anyone with my opinion of his writing, I do apologize.

Paper reading #6: Improving Command Selection with CommandMaps

Intro:

Title: Improving Command Selection with CommandMaps

Reference Information: CHI '12 Proceedings of the 2012 ACM annual conference on Human Factors in Computing Systems, Pages 257-266

Author bios:

Joey Scarr was a senior in Computer Science at the University of Canterbury in New Zealand. He has produced a number of miscellaneous but useful projects.

Andy Cockburn is a professor at the University of Canterbury; his interests are HCI and multimedia projects. According to his website, he is a bit of a thrillseeker and enjoys windsurfing and rock climbing.

Carl Gutwin is a professor in the department of computer science at the University of Saskatchewan in Canada. He is one of the faculty leaders of the Interaction Lab, specializing in HCI.

Andrea Bunt is an assistant professor in computer science at the University of Manitoba in Canada; she co-directs the HCI Lab there and has worked on projects including adaptive systems and interface personalization.

 

An example of CommandMap for Microsoft Office

Summary: Four different studies were conducted for one purpose: to show whether graphical menu interface is more effective than other interface types because of spatial memory. In the first study, experienced users of Microsoft Word 2007 (a ribbon interface) were asked to identify their frequently-used tasks; they were then asked to click on a blank ribbon where the task would be located and later asked to find the task on the real interface. This study showed that most of the users had fairly accurate spatial memory and were able to easily find the tasks. The second study involved familiarizing participants with a CommandMap interface (like a ribbon tiled across the screen that appears with a key press; see above illustration), then asking them to find tasks in the CommandMap interface, a ribbon interface, and a traditional menu interface. The CommandMap interface was found to reduce time taken to find tasks, frustration, and ease of use for experienced users. In the third study, the same tests were performed in the second study, but the participants were not familiar with any of the interfaces. In this case, ribbon and CommandMap interfaces were found to be faster to navigate than menu interfaces, but neither had a clear advantage. Because the first three studies were conducted on static screens (i.e. full-screen program windows), the fourth study observed how participants reacted to a scaling CommandMap and a constantly-sized popup CommandMap. The scaled CommandMap was observed at 1280 x 1024 resolution, 640 x 512 resolution, and at 320 x 256 resolution. All participants preferred the pop-up menu. Overall, experienced users preferred the CommandMap to ribbon or menu interfaces.

Related works:

2D vs 3D, Implications on Spatial Memory - Tavanti, Lind
An investigation of how spatial memory differs between 2-dimensional and 3-dimensional displays; spatial memory is crucial to the CommandMap study and the development of 3D displays will require additional interface research.

Spatial Memory in Hypertext Information Retrieval - Fajardo, Canas, Salmeron,  Abascal
Investigating the use of spatial memory in information retrieval; CommandMap may be used for information retrieval purposes.
 
The Influence of Grids on Spatial and Content Memory - Leifert
A study about how visual grid overlays can affect spatial memory in some interfaces; could prove to be useful in spatial interfaces.

Pad: An Alternative Approach to the Computer Interface - Perlin, Fox
A discussion of a new computer interface in which the whole interface is a giant shared workspace, where zooming and motion allow information access. In this, each piece of information has a physical place, much like CommandMap (though CommandMap is not this extreme).

Query, Analysis, and Visualization of Hierarchically Structured Data Using Polaris - Stolte, Tang, Hanrahan
A presentation of a visualization of a hierarchically organized structure; in this case, it deals with a warehouse, but this could be expanded to deal with menus and the like (as CommandMap does).

Finding Information on a Menu: Linking Menu Organization to the User's Goals - Mehlenbacher, Duffy, Palmer
This 1989 paper is an example of relatively early menu development. Interesting to see that this paper, once at the height of technology, is describing a technology that CommandMap may replace.

Complementary menus: Combining adaptable and adaptive approaches for menu interface - Park, Han
A study of adaptable and adaptive menus shows that menus based on user preferences and frequency of task selection are more effective; similar to CommandMap.

Learning and retention with a menu and a command line interface - Durham, Emurian
A study of how well participants remember how to interact properly with a command-line interface or a menu interface; any interface easily remembered is relevant.

User-process model approach to improve user interface usability - Ju, Gluck
A study of menus reorganized based on users' preferences.

Design and evaluation of freehand menu selection interfaces using tilt and pinch gestures - Ni, Bowman, North, McMahan
The development of a new menu-based interface using gestures is discussed; any alternative interfaces are relevant to CommandMap.

According to the relevant research found, this is a fairly novel interface alternative, but alternatives to menu interfaces are not unheard of.

Evaluation: In the first study, only a quantitative objective analysis was performed. The number of familiar tasks, the accuracy of clicking in the blank ribbon, and the number of clicks taken to get to the task in the ribbon interface were all gathered. For studies two and three, a quantitative objective analysis was performed of the speed at which tasks were selected and the error rate. Additionally, a quantitative subjective analysis was performed to determine interface preferences (including categories like mental demand, temporal demand, and frustration). For the fourth study, a quantitative objective analysis was performed on accuracy rates, and a qualitative subjective analysis was performed after participants were asked for their opinions.

Discussion: CommandMap is a good alternative to keyboard shortcuts; one of the reasons referenced for its development is the fact that few "expert" users adopt keyboard shortcuts, preferring to stick to mouse commands. I much prefer using the keyboard and would probably find the screen real estate required for this system frustrating; perhaps that is due to my status as a programmer. The evaluation was appropriate and complete--concrete numbers were needed to determine its actual effectiveness, and user opinions are vital for the success of this project. This seems to be a fairly novel project.