Norman didn't just talk about affordances, although frequently that's what we remember him for. In his book he lamented that he was remembered for bad doors, but either that was some time ago, or among a community to which I was not a part of, as I have never yet heard anyone refer to anything as a 'Norman Door.' Throwing the word 'affordances' out like a buzz word is one of the easiest ways to pretend you know a great deal about Norman! Although, to be fair, the difficulty in affordances is not in understanding what an affordance is, but in applying it to your current situation to understand how you should design something.
But enough about affordances; I told you, already, he's talked about other things!
In "The Design of Everyday Things" Norman talks about several concept, affordances included. One of the other big topics he hit on was natural mapping. Or conceptual mapping. Or mind mapping. Or mental mapping or- gosh darn it, I'm just not sure what to call it any more. Conceptual, mind, and mental mapping all seem to be words for more or less the same thing, if you ask me!
Usually, a conceptual map is a diagram for understanding the relationships between items, in which case we could say Norman is talking about conceptual mapping because he is pretty much laying down his observations in diagram form. And a mind map is a brainstorming tool. And a mental map is one's understanding of ones sociocultural and spacial position in the world.
The reason I take the time to point these out is because almost all of them are addressed when one is in the interactive entertainment field, and I feel it is very important for me to set the record straight. Donal Norman did talk about other forms of mapping- his famous 'trying to get the temperature right in the freezer and the refrigerator' example was one such instance- but Natural mapping is one of those other buzz words we associate with Norman and which needs to be addressed in any lengthy blog post about him.
Natural mapping is the idea that components of a system should share easily observable properties that help a user correctly and intuitively guess the relationship between them.I say 'guess' because when we use non-dangerous controls, we tend to grab- without thinking- whatever control seems most natural to us, and attempt to operate it. If we are unsuccessful, we will proceed to try a few more options before actually bending our brain to the problem. Humans are not meant to think about their activities 24-7. Some things need to be doable automatically.
In most of his examples, these shared properties are a spatial map. That is, good natural mapping in these instances means that a spatial understanding of one part of a system should also apply to to second part of the same system. For example, a user, upon assessing the controls for an object, should be able to make an internal map of their spacial arrangement, and then apply that same internal map to the actual objects. This helps the user understand which switch controls which. Creating an internal spatial map comes naturally to humans. If it is ignored, we just never learn the correct controls for something (For example, I cannot tell you right now which of the light switches in my home controls which light- and I only have two light switches. Period.) If it is violated we will almost consistently attempt to input the wrong controls.
Natural mapping can also work for non-spacial relationships; for example, if I love chocolate and hate seaweed, I might keep chocolate near the good controls and canned seaweed near 'bad' controls (like scram-switches).
Natural mapping is likely similar to the 180 degree 'line' in cinematography that it is 'illegal' to cross via cut, and is still uncomfortable to cross via dolly/pan.
For me, natural mapping meant that even though it would look nice if all of my 'journal' pages were on one side of the interface, and even though I never want to cover my whole screen by having journal pages on both sides of the interface, tab-like menu items on the right side of the interface could NOT summon journal pages on the left side. I tried to do this for awhile, only to surrender to the inevitability of that which Norman observed first: its best not to agitate the user by providing unnatural and nonsensical motion. Instead, I opted to close any journal pages on the left hand side of the screen before opening journal pages on the right, and vise versa.
Due to the low gaming experience of my audience, natural mapping is actually a very important concern, particularly concerning the fact that some 'gamer' conventions are not particularly natural- and also because I am working on the iPad where many 'naturalistic' gestures are possible (and where it is equally possible to mangle them). The traditional, gamer, buttons-and-joystick combo, for instance, is exceptionally awkward for my player; while the mechanics inherent in the Sims for iPad is a perfect research model: it was already crafted specifically for my audience, after all!
Showing posts with label Design. Show all posts
Showing posts with label Design. Show all posts
Thursday, May 31, 2012
On Norman - Part One
There is such a great deal to say about Mr. Donald A. Normal, the writer of The Design of Everyday Things; some of it good, and some of it bad. He recently spoke at TED, an event at which he admitted that while usability needed to be a strong focus of HCI, beauty was also important.
Donald Norman's ideas, set forth in 2002, are now fairly common. What's more, they seem so blatantly obvious that it is strange to read a book about them, as if I were reading a book describing describing how the sky is blue, and grass is green. It takes a problem, a conundrum, a task-that-wants-not-to-be-solved before Norman's words, buried somewhere in a young designer's skull, start to breathe life into solutions.
I will divide my blog up into two sections. In the first, I shall discuss affordances; and in the second I shall discuss mental mapping/conceptual models.
Affordances can be summarized in a few neat words- so neat and so few that it's initially difficult to understand why they should inspire me. Affordances are the attributes of an object that hint at what can be done with it. Or, put in verse, an object has well-designed affordances if- by looking at it- the user can determine how to use it.
Well duh. This applies on so many levels. For example, don't design a door who's handle statistically causes a first time user to apply force in an incorrect direction to open the door. Don't design something to be indistinguishable from an 'enemy' in game if it is killable and you don't want people to kill it. Clicking on a crosshair should not cause my character to jump- ever. A crosshair means aiming. A button is something I can click. A scroll-bar can be moved up and down.
To me, this all really just sounds like "Don't be stupid. Here are some rules you can give your boss/programmer/self-absorbed teammate who's currently being stupid."
Well, that has merit on its own. If only designers know entry-level designer material (like don't make a stove look like a toilet), sometimes we are taken for granted and ignored. Real research and conventional wisdom that skews our way can help us be successful.
But that was not the end of this story.
What if I apply the idea of affordances to women and feminine products? Now of course I know that with non-gamers as my target audience, my interface has to be ten times as obvious as ever. No shape can be strange to the average web-user; no control can be more than one or two steps away from whatever real-world or online activity these women are already engaging in.
But that's not what I mean. I mean, what if I apply the idea of affordances as a fuzzy logic/boolean variable concerning whether a product is considered 'feminine' or not?
I have stumbled upon a big idea. How do women buy products? An affordance is something about a product that hints as to its use; but the use of an object cannot be fundamentally seperated from its user. It seems to me that affordances can send off social/cultural signals, as well as physical ones. And why not? Humans are pattern matchers after all. Perhaps a given affordance says: "I am unisex, I am for children, I am for old people, I am for people with short hair, I am for men, I am for people with large breasts, or I am for women.
That's it! There are things about products that act as affordances to signal which operators are intended to act upon those products. A shooting game's affordances, may specify a male actor is preferred; a bottle of Dove Herbal shampoo boldly assists a woman in navigating through shelves and shelves of hair-care products to find it.
What does this mean? This means that the products women buy may not necessarily have the same attributes that women prefer. Any given woman may prefer to use a very powerful men's dandruff shampoo, but the signals in the hallway have called her to the curvaceous, baby blue, Aussie shampoo bottle.
This goes back to the old pink & purple debate. Toys for girls are pink and purple because toys for girls have always been pink and purple. The pink and purple helps moms and daughters locate the 'girl' side of the toy aisle. That girl grows up identifying with these symbols, and eventually internalizes them and perpetuates them on to her own offspring. Its not like pink is naturally feminine; but it does serve a useful function of providing clear color dividers between one side of the toy store and the other.
So how does one apply information of this nature?
First, identify products that women buy. Look at their websites, brand labels, and advertisements. Does this tell you what women like? No. But it tells you what visual clues women are going to be looking for when they try to determine the gender of a new product. For instance, the outside of a barbie horseback riding game may be gratuitously pink to signal itself as a toy for girls. On the other hand, the inside of the game may be surprisingly pink-free.
Why did the outsides and insides of the game have a different color scheme? Easy. The color scheme on the inside is the one the target audience actually prefers. The color scheme on the outside is not actually part of the game or the user experience, it is nothing more than a signal. It is a word-less sign of pink-dome, and it reads loudly: "I am for girls."
Certain objects have affordances that signal themselves to women. Almost all female products are targeted about clothing, the color white, clenliness, health, utility, social, children, home life, soft tints, and curvaceous lines. Check out a bottle of Suave shampoo. How do you know if its for men or women, if you don't read the label? There are glaring color and font differences.
Does that mean you have to make a white, cleaning, health-oriented, utilitarian, social based, can-play-with-children, helps you cook and clean, mauve colored dear-Abby game for women? Of course not. But at first glance, it needs to have the proper affordances to hint as to its intended operator. It must signal the woman. It must let her know that she is the intended operator, and it must work exceptionally hard to build her expectations concerning the game.
This is largely manifested in marketing and posturing, of course, but this also means the fonts, the character artistic style, the placement of the interface items, and in fact the overall metaphors used for designing and later skinning the game, all require a sensitivity to feminine affordances. It also means that as long as the shell builds up the proper expectations concerning the internal game, many of those affordances can later be discarded or modified.
For me, affordances are two things: the properties of Heros: Duelworlds that signal women to come in and give it a try; and the properties of the game interface that let her know what to do with the actual controls.
Donald Norman's ideas, set forth in 2002, are now fairly common. What's more, they seem so blatantly obvious that it is strange to read a book about them, as if I were reading a book describing describing how the sky is blue, and grass is green. It takes a problem, a conundrum, a task-that-wants-not-to-be-solved before Norman's words, buried somewhere in a young designer's skull, start to breathe life into solutions.
I will divide my blog up into two sections. In the first, I shall discuss affordances; and in the second I shall discuss mental mapping/conceptual models.
Affordances can be summarized in a few neat words- so neat and so few that it's initially difficult to understand why they should inspire me. Affordances are the attributes of an object that hint at what can be done with it. Or, put in verse, an object has well-designed affordances if- by looking at it- the user can determine how to use it.
Well duh. This applies on so many levels. For example, don't design a door who's handle statistically causes a first time user to apply force in an incorrect direction to open the door. Don't design something to be indistinguishable from an 'enemy' in game if it is killable and you don't want people to kill it. Clicking on a crosshair should not cause my character to jump- ever. A crosshair means aiming. A button is something I can click. A scroll-bar can be moved up and down.
To me, this all really just sounds like "Don't be stupid. Here are some rules you can give your boss/programmer/self-absorbed teammate who's currently being stupid."
Well, that has merit on its own. If only designers know entry-level designer material (like don't make a stove look like a toilet), sometimes we are taken for granted and ignored. Real research and conventional wisdom that skews our way can help us be successful.
But that was not the end of this story.
What if I apply the idea of affordances to women and feminine products? Now of course I know that with non-gamers as my target audience, my interface has to be ten times as obvious as ever. No shape can be strange to the average web-user; no control can be more than one or two steps away from whatever real-world or online activity these women are already engaging in.
But that's not what I mean. I mean, what if I apply the idea of affordances as a fuzzy logic/boolean variable concerning whether a product is considered 'feminine' or not?
I have stumbled upon a big idea. How do women buy products? An affordance is something about a product that hints as to its use; but the use of an object cannot be fundamentally seperated from its user. It seems to me that affordances can send off social/cultural signals, as well as physical ones. And why not? Humans are pattern matchers after all. Perhaps a given affordance says: "I am unisex, I am for children, I am for old people, I am for people with short hair, I am for men, I am for people with large breasts, or I am for women.
That's it! There are things about products that act as affordances to signal which operators are intended to act upon those products. A shooting game's affordances, may specify a male actor is preferred; a bottle of Dove Herbal shampoo boldly assists a woman in navigating through shelves and shelves of hair-care products to find it.
What does this mean? This means that the products women buy may not necessarily have the same attributes that women prefer. Any given woman may prefer to use a very powerful men's dandruff shampoo, but the signals in the hallway have called her to the curvaceous, baby blue, Aussie shampoo bottle.
This goes back to the old pink & purple debate. Toys for girls are pink and purple because toys for girls have always been pink and purple. The pink and purple helps moms and daughters locate the 'girl' side of the toy aisle. That girl grows up identifying with these symbols, and eventually internalizes them and perpetuates them on to her own offspring. Its not like pink is naturally feminine; but it does serve a useful function of providing clear color dividers between one side of the toy store and the other.
So how does one apply information of this nature?
First, identify products that women buy. Look at their websites, brand labels, and advertisements. Does this tell you what women like? No. But it tells you what visual clues women are going to be looking for when they try to determine the gender of a new product. For instance, the outside of a barbie horseback riding game may be gratuitously pink to signal itself as a toy for girls. On the other hand, the inside of the game may be surprisingly pink-free.
Why did the outsides and insides of the game have a different color scheme? Easy. The color scheme on the inside is the one the target audience actually prefers. The color scheme on the outside is not actually part of the game or the user experience, it is nothing more than a signal. It is a word-less sign of pink-dome, and it reads loudly: "I am for girls."
Certain objects have affordances that signal themselves to women. Almost all female products are targeted about clothing, the color white, clenliness, health, utility, social, children, home life, soft tints, and curvaceous lines. Check out a bottle of Suave shampoo. How do you know if its for men or women, if you don't read the label? There are glaring color and font differences.
Does that mean you have to make a white, cleaning, health-oriented, utilitarian, social based, can-play-with-children, helps you cook and clean, mauve colored dear-Abby game for women? Of course not. But at first glance, it needs to have the proper affordances to hint as to its intended operator. It must signal the woman. It must let her know that she is the intended operator, and it must work exceptionally hard to build her expectations concerning the game.
This is largely manifested in marketing and posturing, of course, but this also means the fonts, the character artistic style, the placement of the interface items, and in fact the overall metaphors used for designing and later skinning the game, all require a sensitivity to feminine affordances. It also means that as long as the shell builds up the proper expectations concerning the internal game, many of those affordances can later be discarded or modified.
For me, affordances are two things: the properties of Heros: Duelworlds that signal women to come in and give it a try; and the properties of the game interface that let her know what to do with the actual controls.
Tuesday, April 17, 2012
Designing for Fun: How Can We Design User Interfaces to Be More Fun - Ben Shneiderman
My first and biggest pet peeve with this short and informative little article... is his use of the word 'Fun'. He can't seem to keep his definitions straight.
Mr. Shneiderman talks about there being two different kinds of fun: fun-in-doing and fun-in-not-doing. The first is active fun, the fun one associates with performing some activity; the other is passive fun, the fun one associates with laying back and receiving something. Active fun is playing volleyball; passive fun is sun tanning.
So far, so good. But wait! Let's look at the title again. "Designing for Fun: How Can We Design User Interfaces to be More Fun?"
Hold on a second. Be more fun? An interface is neither an action nor a passive experience. How can an interface be fun? We just said that fun is event/experience-driven. Interfaces are not experiences! Interfaces may give experiences, but they are not experiences in themselves! Work with me here, take a moment and follow my train of thought.
Definition A: The word 'fun' belongs to the kingdom of the word 'experience'. It is a component to an experience, be that experience active or passive. Experiences own the word fun. Fun is an adverb applied to experience, or some kind of metaphorical substance that is extracted from experience. Fun is derived from some kind of temporal happening. Fun is derived from events. Fun belongs to verbs.
Definition B: Fun is a property of a construct, ie: a ball, a person, an interface. All nouns share the word fun, and fun is an adjective applied to a noun. Otherwise it is extracted from that noun. Fun is not uniquely bonded to the word 'experience.' Fun belongs to nouns.
Hmm.
Now any dictionary will tell you that there can be multiple definitions of a word, but usually when you're writing an academic paper, you want to pick one definition and stick to it. If you start mixing and matching definitions like this, you end up with conclusions that aren't valid. You might as well be mixing and matching the various definitions of the world resume: 1) to continue, 2) a curriculum vitae. (Hah, I kinda cheated there, resume should have an accent on the e for the second definition. But work with me here!)
Strictly Speaking, I Side With Definition A
Whenever I use Definition B, I'm basically saying that an object frequently provides Definition A. I don't believe a noun can inherently be fun, only that it can provide a fun experience. When we start using fun to describe nouns... well blatant misuses of the word start to occur.
Misusing the Word Fun
If I examine Figure 1 and 2 from this article, I see that the author calls a boring chart with poor readability 'plain,' and a chart with lots of pleasant shapes, good shading, and enhanced readability 'fun.'
...
If I dot all of the 'i's with little hearts, will that be fun too? The author using 'fun' for this purpose is... is... I feel like I am being patronized as I read it! I feel like I just got called up by a client who wants to design a website for men's aftershave, and after reviewing my site mock-ups, he said that he thinks the website should be more 'fun.'
Is 'Fun' A Visual Style? Like 80's Rock Album Covers?
What? What does that mean?! What does it mean for a noun, an object, to be fun? Is 'fun' some kind of visual style, linked to abstract art or funk? Does fun mean enhanced readability? Does fun mean nice shading on diagram bubbles, and curvaceous shapes? Does fun mean the inclusion of animations? Goodness gracious man, I'm a video game designer, and you just used the word 'fun' to describe rounded boxes in a diagram.
The reason I have to come down so hard on his usage of fun is this: I have to stop the word 'fun' from turning into an empty word, a word that means simply 'I (the speaker) like it.' When a video game designer is designing for 'fun,' fun has to mean something real. It's not a visual art style or enhanced usability; it's not a property a game can have. It's a feeling that the game may or may not instill in its users.
This is vitally important because we are studying Human-Computer-Interaction. The users- the people on the human side of the interaction- are the ones who are either having fun or not. There are no universal principals of 'fun.' Fun is not an attribute. Fun is an interpretation of an event, it's tied to experience. I cannot sit here in a little box, with a list of things that are 'fun,' add all of them into my design, and call that design 'fun.'
Instead, what I have to do is think about the goals (active and passive) of my user and try to design my product to yield fun experiences for them. I must go out and observe my user having fun (and having frustration) and then come back and work with my findings. I must then give my product to the users for testing, to see if they are having fun or not. I can only design my product around them. I cannot design my product around some abstract manifestation of fun.
But We Use 'Fun' To Describe Nouns, Don't We?
Using 'fun' on a noun (like saying 'hey, Bob's a fun guy!') is a colloquialism, but hardly useful for academic discourse. Fun is, as you said once, a component of an experience. Fun only occurs when a human interprets an event, and stores it internally as an experience. Something you might find boring, I find fun.
A human being cannot be fun. Assuming the existence of a person named Bob. If I frequently experience fun when interacting with Bob, I may label him 'fun' in common conversation. Nevertheless, you are completely entitled to derive a not-fun experience from interacting with Bob. Bob himself is not fun. Fun is part of my experience of interacting with Bob; Fun is one flavor of the overall spectrum of positive interpretations of an event.
Also, I'm Pretty Sure Interfaces Aren't Supposed To Be Fun
Last I heard, a good interface was practically invisible to its user. The user isn't even supposed to notice the interface; the interface just facilitates communication between the human and the product.
Fun Can Be Provided By a Noun
Let's change the meaning of this paper so that we can continue talking about it. Let's change it to, "How Can We Design User Interfaces to Yield More Fun?" Then when we think of "How Can We Design User Interfaces to Be More Fun?" we can internally know that we are really asking about ways in which the Interface will facilitate more of its users deriving fun experiences from it...
But Wait, That's Not Actually What This Paper Is About
This paper was a survey of good design techniques and interesting observations about usability. It was a great survey of design methodologies and golden rules. Remarkably, it had almost nothing to do whatsoever with fun user interfaces. Fortunately, in a few locations it has something to do with fun, or user interfaces, independent of one another.
So What Is IT ABout?
This paper is phenomenal when it comes to discussing the tools for crafting enjoyable user experiences. Some of his sources at first seem questionable; he cites Tom Malone on educational games and educational games don't have the best reputation for 'being fun'. A quick search on the man's name shows he's a MIT professor with a lot of papers and a good reputation, but he's a theorist, not a game designer. Am I sure I want to trust this kind of source? But NASA (and science centers in general) has a surprisingly good reputation for making learning fun! He makes some good points about fun, children, and learning in this section.
Yet after giving us this little background on fun, the author proceeds to go through the complete rest of the paper calling a lot of things fun, but seeming to have disregarded the original meaning of the term for something else entirely. After rambling about shopping carts and banking, the author makes this statement:
"For these new and highly competitive markets, I believe designers must address three almost equally important goals that contribute to fun-in-doing: provide the right functions so that users can accomplish their goals, offer usability plus reliability to prevent frustration from undermining the fun, and engage the users with fun-features."
I feel demeaned again. What the heck is a fun-feature? Ugh, it sounds icky. Let's take that sentence and replace the word 'fun' with 'desirable.' We get
"For these new and highly competitive markets, I believe designers must address three almost equally important goals that contribute to being desirable to do: provide the right functions so that users can accomplish their goals, offer usability plus reliability to prevent frustration from undermining the desirability, and engage the users with desirable-features."
Was the word fun really all that important? It looks to me like the author is confusing 'fun' for the basic HCI component of 'desirable.' Ergo, this paper is not about making interfaces fun, it's about making interfaces desirable.
Interfaces
After briefly explaining that there exist models of design spaces for input devices and menus, he reflects sadly that there are few higher-order models that might help with thinking outside of the box. While sprinkling his sentences with the word fun-filled (who uses the word fun-filled?) he casts a gorgeous cloak over many fields of interaction design. He talks about activities between information technologies and human relationships, about the Eight Golden Rules for Designing the User Interface, but then things start to get a little weird.
Fun... Is Not.... An Aesthetic! (Hey Haven't We Been Here Before?)
The author then proceeds to talk about the development of theories of user engagement through fun-features (What does that mean!?) According to him, these fun-features are "alluring metaphors, compelling content, attractive graphics, appealing animations, and satisfying sounds." This is the section he devotes to delighting and amusing users. He uses the example of a shimmering rainbow. At this point I honestly have no idea who he is designing for. I feel again like a child. Looking back at his reference to Tom Malone, I wonder if the author specializes in designing for children, and perhaps underestimates their sophistication. Who talks like this? Most importantly: Content is not part of the interface. The Interface is for accessing the content.
Lots of the Author's Advice Is Good (Minus His Opinion That Sparkles = Fun), He Just Has Trouble Staying On Topic
His advice isn't interface specific. While coming up with an alluring metaphor has stronger ties to interface design than to any other kind of design, he then talks about compelling content, such as first-rate writing, striking photos, and outstanding graphics. To be honest, once we're past the realm of buttons boarders and backgrounds, the realm of the interface is over. The interface contains no substantial writing, photos, or graphics. This has almost nothing to do with interface design.
He gets back on topic by talking about attractive graphics, which he specializes to say is about spacing, balance, symmetry, and using these techniques to improve performance. By this point we have lost all reference to the word 'fun,' which is something of a relief. If I had to hear anything more about fun-features (which should never, ever, be a hyphenated word), I wasn't going to be able to get anything from this paper! He discusses the importance of utility vs. attractiveness, not going overboard, the value of some animations like smooth transitions and zooming to preserve user comprehension.
He even discusses an attribute that makes Photoshop so successful: "the direct manipulation of rapid, incremental, and reversibly actions with immediate visibility of results," and something widely considered to be very important: animations that convey the progress of a download. He even talks about sound design
His Parting Thoughts Are Just Hard To Take Seriously, And He Still Can't Stay On Topic
He uses the phrase, "Did anyone notice that fun is part of functionality?" Author! No! you were doing so well not throwing 'fun' around like a bouncy ball!
Then he randomly and haphazardly mentions user customization, which was also a phenomenal insight given the fact that this article was published in 2004 and before the massive mobile device and casual gaming boom, the freemium model, and the idea that a game like Team Fortress 2 can exist entirely off of the benefits of providing an endless variety of strange hats. He also acknowledges the fact that some users want flourishes, and others don't. He makes the unfortunate mistake of confusing 'fun' with 'cute animations,' yes, but he notes that even productivity tools should be fun to use- the fun aspects just shouldn't interfere with goal attainment.
Being terribly off-topic all the time, he then talks about how new guidelines are necessary for designing enjoyable interfaces - guidelines like graphical style issues, symmetry, elegance, simplicity, and distinctiveness- I wonder if he remembers basically saying that these models already existed (see his 'How can we design interfaces to be more fun?' subsection, first paragraph.), and that the problem was that models needed to be made for higher order design theory for out-of-the-box thinking. Then he mentions that rules need to be made for creating images- wait... rules for art? Za? We don't have those? My God, Michelangelo, you mean you did art without any theoretical foundation whatsoever!? He mentions lastly that we need rules for branding. I'm sure those exist. Really.
His Last Paragraph is Phenomenal.
Despite being a conclusion paragraph, very little of it is expressed anywhere else in the entire paper. Even his terminology is spot-on. He speaks of design as a facilitator of fun, instead of a model for it. He also describes user interfaces as playful and liberating instead of fun. He mentions testing for the first time ever. Actually, all of it is pretty spot-on. In fact, maybe I should have just read the last paragraph.
My Final Grade: C for Confusion! (I couldn't give him an F, because F would remind me of the word 'fun', which I never want to hear in this context ever again).
This author rambled, got lost, contradicted himself, used cross definitions, and the title of this article actually had very little to do with the things in the article that were substantive. For a three-paged paper, I sure had a lot to say! I would say that if I could cut up his paper, re-edit it, and use it for my own purposes, the individual sentences of it are actually very enlightening at times. The worst part of the essay was definitely the author's use of the word 'fun.' It made me cringe every time he used it. I always felt like a child being told a story about a unicorn.
Mr. Shneiderman talks about there being two different kinds of fun: fun-in-doing and fun-in-not-doing. The first is active fun, the fun one associates with performing some activity; the other is passive fun, the fun one associates with laying back and receiving something. Active fun is playing volleyball; passive fun is sun tanning.
So far, so good. But wait! Let's look at the title again. "Designing for Fun: How Can We Design User Interfaces to be More Fun?"
Hold on a second. Be more fun? An interface is neither an action nor a passive experience. How can an interface be fun? We just said that fun is event/experience-driven. Interfaces are not experiences! Interfaces may give experiences, but they are not experiences in themselves! Work with me here, take a moment and follow my train of thought.
Definition A: The word 'fun' belongs to the kingdom of the word 'experience'. It is a component to an experience, be that experience active or passive. Experiences own the word fun. Fun is an adverb applied to experience, or some kind of metaphorical substance that is extracted from experience. Fun is derived from some kind of temporal happening. Fun is derived from events. Fun belongs to verbs.
Definition B: Fun is a property of a construct, ie: a ball, a person, an interface. All nouns share the word fun, and fun is an adjective applied to a noun. Otherwise it is extracted from that noun. Fun is not uniquely bonded to the word 'experience.' Fun belongs to nouns.
Hmm.
Now any dictionary will tell you that there can be multiple definitions of a word, but usually when you're writing an academic paper, you want to pick one definition and stick to it. If you start mixing and matching definitions like this, you end up with conclusions that aren't valid. You might as well be mixing and matching the various definitions of the world resume: 1) to continue, 2) a curriculum vitae. (Hah, I kinda cheated there, resume should have an accent on the e for the second definition. But work with me here!)
Strictly Speaking, I Side With Definition A
Whenever I use Definition B, I'm basically saying that an object frequently provides Definition A. I don't believe a noun can inherently be fun, only that it can provide a fun experience. When we start using fun to describe nouns... well blatant misuses of the word start to occur.
Misusing the Word Fun
If I examine Figure 1 and 2 from this article, I see that the author calls a boring chart with poor readability 'plain,' and a chart with lots of pleasant shapes, good shading, and enhanced readability 'fun.'
...
If I dot all of the 'i's with little hearts, will that be fun too? The author using 'fun' for this purpose is... is... I feel like I am being patronized as I read it! I feel like I just got called up by a client who wants to design a website for men's aftershave, and after reviewing my site mock-ups, he said that he thinks the website should be more 'fun.'
Is 'Fun' A Visual Style? Like 80's Rock Album Covers?
What? What does that mean?! What does it mean for a noun, an object, to be fun? Is 'fun' some kind of visual style, linked to abstract art or funk? Does fun mean enhanced readability? Does fun mean nice shading on diagram bubbles, and curvaceous shapes? Does fun mean the inclusion of animations? Goodness gracious man, I'm a video game designer, and you just used the word 'fun' to describe rounded boxes in a diagram.
The reason I have to come down so hard on his usage of fun is this: I have to stop the word 'fun' from turning into an empty word, a word that means simply 'I (the speaker) like it.' When a video game designer is designing for 'fun,' fun has to mean something real. It's not a visual art style or enhanced usability; it's not a property a game can have. It's a feeling that the game may or may not instill in its users.
This is vitally important because we are studying Human-Computer-Interaction. The users- the people on the human side of the interaction- are the ones who are either having fun or not. There are no universal principals of 'fun.' Fun is not an attribute. Fun is an interpretation of an event, it's tied to experience. I cannot sit here in a little box, with a list of things that are 'fun,' add all of them into my design, and call that design 'fun.'
Instead, what I have to do is think about the goals (active and passive) of my user and try to design my product to yield fun experiences for them. I must go out and observe my user having fun (and having frustration) and then come back and work with my findings. I must then give my product to the users for testing, to see if they are having fun or not. I can only design my product around them. I cannot design my product around some abstract manifestation of fun.
But We Use 'Fun' To Describe Nouns, Don't We?
Using 'fun' on a noun (like saying 'hey, Bob's a fun guy!') is a colloquialism, but hardly useful for academic discourse. Fun is, as you said once, a component of an experience. Fun only occurs when a human interprets an event, and stores it internally as an experience. Something you might find boring, I find fun.
A human being cannot be fun. Assuming the existence of a person named Bob. If I frequently experience fun when interacting with Bob, I may label him 'fun' in common conversation. Nevertheless, you are completely entitled to derive a not-fun experience from interacting with Bob. Bob himself is not fun. Fun is part of my experience of interacting with Bob; Fun is one flavor of the overall spectrum of positive interpretations of an event.
Also, I'm Pretty Sure Interfaces Aren't Supposed To Be Fun
Last I heard, a good interface was practically invisible to its user. The user isn't even supposed to notice the interface; the interface just facilitates communication between the human and the product.
Fun Can Be Provided By a Noun
Let's change the meaning of this paper so that we can continue talking about it. Let's change it to, "How Can We Design User Interfaces to Yield More Fun?" Then when we think of "How Can We Design User Interfaces to Be More Fun?" we can internally know that we are really asking about ways in which the Interface will facilitate more of its users deriving fun experiences from it...
But Wait, That's Not Actually What This Paper Is About
This paper was a survey of good design techniques and interesting observations about usability. It was a great survey of design methodologies and golden rules. Remarkably, it had almost nothing to do whatsoever with fun user interfaces. Fortunately, in a few locations it has something to do with fun, or user interfaces, independent of one another.
So What Is IT ABout?
This paper is phenomenal when it comes to discussing the tools for crafting enjoyable user experiences. Some of his sources at first seem questionable; he cites Tom Malone on educational games and educational games don't have the best reputation for 'being fun'. A quick search on the man's name shows he's a MIT professor with a lot of papers and a good reputation, but he's a theorist, not a game designer. Am I sure I want to trust this kind of source? But NASA (and science centers in general) has a surprisingly good reputation for making learning fun! He makes some good points about fun, children, and learning in this section.
Yet after giving us this little background on fun, the author proceeds to go through the complete rest of the paper calling a lot of things fun, but seeming to have disregarded the original meaning of the term for something else entirely. After rambling about shopping carts and banking, the author makes this statement:
"For these new and highly competitive markets, I believe designers must address three almost equally important goals that contribute to fun-in-doing: provide the right functions so that users can accomplish their goals, offer usability plus reliability to prevent frustration from undermining the fun, and engage the users with fun-features."
I feel demeaned again. What the heck is a fun-feature? Ugh, it sounds icky. Let's take that sentence and replace the word 'fun' with 'desirable.' We get
"For these new and highly competitive markets, I believe designers must address three almost equally important goals that contribute to being desirable to do: provide the right functions so that users can accomplish their goals, offer usability plus reliability to prevent frustration from undermining the desirability, and engage the users with desirable-features."
Was the word fun really all that important? It looks to me like the author is confusing 'fun' for the basic HCI component of 'desirable.' Ergo, this paper is not about making interfaces fun, it's about making interfaces desirable.
Interfaces
After briefly explaining that there exist models of design spaces for input devices and menus, he reflects sadly that there are few higher-order models that might help with thinking outside of the box. While sprinkling his sentences with the word fun-filled (who uses the word fun-filled?) he casts a gorgeous cloak over many fields of interaction design. He talks about activities between information technologies and human relationships, about the Eight Golden Rules for Designing the User Interface, but then things start to get a little weird.
Fun... Is Not.... An Aesthetic! (Hey Haven't We Been Here Before?)
The author then proceeds to talk about the development of theories of user engagement through fun-features (What does that mean!?) According to him, these fun-features are "alluring metaphors, compelling content, attractive graphics, appealing animations, and satisfying sounds." This is the section he devotes to delighting and amusing users. He uses the example of a shimmering rainbow. At this point I honestly have no idea who he is designing for. I feel again like a child. Looking back at his reference to Tom Malone, I wonder if the author specializes in designing for children, and perhaps underestimates their sophistication. Who talks like this? Most importantly: Content is not part of the interface. The Interface is for accessing the content.
Lots of the Author's Advice Is Good (Minus His Opinion That Sparkles = Fun), He Just Has Trouble Staying On Topic
His advice isn't interface specific. While coming up with an alluring metaphor has stronger ties to interface design than to any other kind of design, he then talks about compelling content, such as first-rate writing, striking photos, and outstanding graphics. To be honest, once we're past the realm of buttons boarders and backgrounds, the realm of the interface is over. The interface contains no substantial writing, photos, or graphics. This has almost nothing to do with interface design.
He gets back on topic by talking about attractive graphics, which he specializes to say is about spacing, balance, symmetry, and using these techniques to improve performance. By this point we have lost all reference to the word 'fun,' which is something of a relief. If I had to hear anything more about fun-features (which should never, ever, be a hyphenated word), I wasn't going to be able to get anything from this paper! He discusses the importance of utility vs. attractiveness, not going overboard, the value of some animations like smooth transitions and zooming to preserve user comprehension.
He even discusses an attribute that makes Photoshop so successful: "the direct manipulation of rapid, incremental, and reversibly actions with immediate visibility of results," and something widely considered to be very important: animations that convey the progress of a download. He even talks about sound design
His Parting Thoughts Are Just Hard To Take Seriously, And He Still Can't Stay On Topic
He uses the phrase, "Did anyone notice that fun is part of functionality?" Author! No! you were doing so well not throwing 'fun' around like a bouncy ball!
Then he randomly and haphazardly mentions user customization, which was also a phenomenal insight given the fact that this article was published in 2004 and before the massive mobile device and casual gaming boom, the freemium model, and the idea that a game like Team Fortress 2 can exist entirely off of the benefits of providing an endless variety of strange hats. He also acknowledges the fact that some users want flourishes, and others don't. He makes the unfortunate mistake of confusing 'fun' with 'cute animations,' yes, but he notes that even productivity tools should be fun to use- the fun aspects just shouldn't interfere with goal attainment.
Being terribly off-topic all the time, he then talks about how new guidelines are necessary for designing enjoyable interfaces - guidelines like graphical style issues, symmetry, elegance, simplicity, and distinctiveness- I wonder if he remembers basically saying that these models already existed (see his 'How can we design interfaces to be more fun?' subsection, first paragraph.), and that the problem was that models needed to be made for higher order design theory for out-of-the-box thinking. Then he mentions that rules need to be made for creating images- wait... rules for art? Za? We don't have those? My God, Michelangelo, you mean you did art without any theoretical foundation whatsoever!? He mentions lastly that we need rules for branding. I'm sure those exist. Really.
His Last Paragraph is Phenomenal.
Despite being a conclusion paragraph, very little of it is expressed anywhere else in the entire paper. Even his terminology is spot-on. He speaks of design as a facilitator of fun, instead of a model for it. He also describes user interfaces as playful and liberating instead of fun. He mentions testing for the first time ever. Actually, all of it is pretty spot-on. In fact, maybe I should have just read the last paragraph.
My Final Grade: C for Confusion! (I couldn't give him an F, because F would remind me of the word 'fun', which I never want to hear in this context ever again).
This author rambled, got lost, contradicted himself, used cross definitions, and the title of this article actually had very little to do with the things in the article that were substantive. For a three-paged paper, I sure had a lot to say! I would say that if I could cut up his paper, re-edit it, and use it for my own purposes, the individual sentences of it are actually very enlightening at times. The worst part of the essay was definitely the author's use of the word 'fun.' It made me cringe every time he used it. I always felt like a child being told a story about a unicorn.
Tuesday, April 10, 2012
Alan Cooper and the Goal Directed Design Process - Hugh Dubberly
This paper was written as Hugh Dubberly's explanation of Alan Cooper and Alan Cooper's Goal Directed Design Process. It receives a Gaming Imperatrix Thumbs Up.
Style and Contents
This paper was written in an instructive/explanatory/educational format. It was smooth reading even though it contained a great deal of useful insights, and was generally a pleasurable paper to read. The paper is structured with a page of introductory material.
It introduces the reader to Alan Cooper, who he is, what he cares about, what his goals are, what is background was, and what his driving forces were, which let's the reader get a good sense of where the paper is going to go.
After this, it highlights in bold the five steps of his goal-directed design process. In each section, it writes in italics the old methodology, that this bold step replaces. Then it explains the reasoning for the approach in plain text.
After this phase, he goes into a further study of the goal-directed design process, homing in on useful details. For example, the Designer + Design Communicator core that Alan Cooper advocated building teams around, the evolution of the design process and the necessity of putting design before programming, the different dimensions of design, an input/output table for the software development process concerning persons on the team, and then a final overview of Goal Directed Design and a methodology for how to build a successful product by using GDD. The paper is covered in graphics, tables, and charts, all of which are fairly easy to synthesize.
Interesting Observations
I liked this paper, and learned a bunch of interesting little tidbits from it. Although I knew that software development had gone from lone-wolf programmers up to an elaborate design process, I hadn't thought of it in discrete steps before, or realized that the step we are currently unseating (or have just recently unseated) was a phase of doing design and code work at the same time.
I noted with interest that Alan cooper (or Hugh Dubberly, I'm not sure which) considered Art and Design to be more-or-less the same thing! This was a useful insight for me, because I am interested in being a game designer, not a game artist. In the movie industry, movies usually always have distinct producer, director, art, and technical roles. In an analogy, I want to be the director for a video game. I've been coming to the realization over the years that this role is still working to manifest itself clearly in the industry. One would hardly think of shooting a movie without a director, but for some reason it seems okay to build a game without one? Nonsense!
I have also been listening to how gaming companies are structured, and have noticed that the role of director/designer frequently gets mistaken for or folded in to other roles. Sometimes it is the lead programmer, other times it is the 'Creative Lead.' Now I understand why anyone would fold 'Designer' into 'Creative Lead,' as there is a theoretical precedent for it!
Hugh explains- and I think his phrasing/Alan's idea is superb- that there is a conflict of interest between Programmers and Designers. Programmers want something to be easy to program, and Designers want it to be easy to use. If you use that means of thinking, then obviously there must also be a conflict of interest between Designers and Artists. But the conflict of interest is deeper than just how much work a person has to do.
A Programmer has a conflict of interest with a Designer because the Programmer wants something to have good, functional code that he/she is proud of. He wants to show off his programming. His programming becomes his center of focus, instead of design. Likewise, the artist's art becomes the center of focus for them, instead of design. Design- the composition of all of the game's various interrelated elements, from the data gathered by market researchers for use in HCI, to programming, to art, to user requirements, to producer requirements- that composition job is a job all in its own, and should be kept free from any other job that might try to claim it.
I love the idea of pairing a Designer- or really any job- with a dedicated communicator. Usually the people who have technical skills are not necessarily the best communicators!
I enjoyed looking at how the individual rules on the software development process interrelate based on the input/output chart, but some of my favorite graphics were about Cooper's People/Technology/Buisness model. At my old school, Architecture and Design were of course grouped together, and our Games students presented their final projects with Archtiecture students.
I agree that they share many attributes- although I feel Architecture is more closely related to Level Design and Installation Art than to Game Design as a whole. In the end, Architecture is about designing spaces, and the usability of spaces; but Game Design also requires Interior Decorators to make the art, Physicists to make gravity work, and a Director to make sure they're all working on the same project.
I also like how the paper compared Cooper's specific software-design model to the original model and derivations thereof. He showed us the abstract version (Desirability/Capability/Visibility) with its abstract-y words next to a more functional and applicable version, to show how the abstract version could be instanced into a functional model. Cooper's explanation of Apple, Microsoft, and Novell using this system extended its ease-of-use even further.
All in all a pleasurable read. A+
Style and Contents
This paper was written in an instructive/explanatory/educational format. It was smooth reading even though it contained a great deal of useful insights, and was generally a pleasurable paper to read. The paper is structured with a page of introductory material.
It introduces the reader to Alan Cooper, who he is, what he cares about, what his goals are, what is background was, and what his driving forces were, which let's the reader get a good sense of where the paper is going to go.
After this, it highlights in bold the five steps of his goal-directed design process. In each section, it writes in italics the old methodology, that this bold step replaces. Then it explains the reasoning for the approach in plain text.
After this phase, he goes into a further study of the goal-directed design process, homing in on useful details. For example, the Designer + Design Communicator core that Alan Cooper advocated building teams around, the evolution of the design process and the necessity of putting design before programming, the different dimensions of design, an input/output table for the software development process concerning persons on the team, and then a final overview of Goal Directed Design and a methodology for how to build a successful product by using GDD. The paper is covered in graphics, tables, and charts, all of which are fairly easy to synthesize.
Interesting Observations
I liked this paper, and learned a bunch of interesting little tidbits from it. Although I knew that software development had gone from lone-wolf programmers up to an elaborate design process, I hadn't thought of it in discrete steps before, or realized that the step we are currently unseating (or have just recently unseated) was a phase of doing design and code work at the same time.
I noted with interest that Alan cooper (or Hugh Dubberly, I'm not sure which) considered Art and Design to be more-or-less the same thing! This was a useful insight for me, because I am interested in being a game designer, not a game artist. In the movie industry, movies usually always have distinct producer, director, art, and technical roles. In an analogy, I want to be the director for a video game. I've been coming to the realization over the years that this role is still working to manifest itself clearly in the industry. One would hardly think of shooting a movie without a director, but for some reason it seems okay to build a game without one? Nonsense!
I have also been listening to how gaming companies are structured, and have noticed that the role of director/designer frequently gets mistaken for or folded in to other roles. Sometimes it is the lead programmer, other times it is the 'Creative Lead.' Now I understand why anyone would fold 'Designer' into 'Creative Lead,' as there is a theoretical precedent for it!
Hugh explains- and I think his phrasing/Alan's idea is superb- that there is a conflict of interest between Programmers and Designers. Programmers want something to be easy to program, and Designers want it to be easy to use. If you use that means of thinking, then obviously there must also be a conflict of interest between Designers and Artists. But the conflict of interest is deeper than just how much work a person has to do.
A Programmer has a conflict of interest with a Designer because the Programmer wants something to have good, functional code that he/she is proud of. He wants to show off his programming. His programming becomes his center of focus, instead of design. Likewise, the artist's art becomes the center of focus for them, instead of design. Design- the composition of all of the game's various interrelated elements, from the data gathered by market researchers for use in HCI, to programming, to art, to user requirements, to producer requirements- that composition job is a job all in its own, and should be kept free from any other job that might try to claim it.
I love the idea of pairing a Designer- or really any job- with a dedicated communicator. Usually the people who have technical skills are not necessarily the best communicators!
I enjoyed looking at how the individual rules on the software development process interrelate based on the input/output chart, but some of my favorite graphics were about Cooper's People/Technology/Buisness model. At my old school, Architecture and Design were of course grouped together, and our Games students presented their final projects with Archtiecture students.
I agree that they share many attributes- although I feel Architecture is more closely related to Level Design and Installation Art than to Game Design as a whole. In the end, Architecture is about designing spaces, and the usability of spaces; but Game Design also requires Interior Decorators to make the art, Physicists to make gravity work, and a Director to make sure they're all working on the same project.
I also like how the paper compared Cooper's specific software-design model to the original model and derivations thereof. He showed us the abstract version (Desirability/Capability/Visibility) with its abstract-y words next to a more functional and applicable version, to show how the abstract version could be instanced into a functional model. Cooper's explanation of Apple, Microsoft, and Novell using this system extended its ease-of-use even further.
All in all a pleasurable read. A+
Sunday, April 1, 2012
The Continuous Construction of the Computer User: Visions and User Models in the History of Human-Computer Interaction - Michael Friedewald
Reason for Blog Post
Part of any master's degree involves doing a lot of reading and researching, and studying video games is no different. This blog has been commandeered as a forum through which I will be reviewing various readings for my Human-Computer Interaction class.
And so this journey begins with a quick review of The Continuous Construction of the Computer User: Visions and User Models in the History of Human-Computer Interaction by Michael Friedewald.
Disclaimer
Let me begin by say that I am somewhat prejudiced against the academic style of writing. I think I'll write a blog post about that later. I personally think that many academic writing conventions are completely counterproductive to, well, academia. But that's a conversation or another time.
Let me also say that I did not like the writing style of this paper, so while I found it plenty informative, I still had a negative opinion of it!
Reading Purpose
For now let's just say that Michael Friedewald's essay was assigned as little more than a quick survey of the evolution of Human-Computer Interaction. It was featured early on in the book Total Interaction. And it did a pretty good job as a survey. Important names and developments are all sprinkled in for review.
As I've been a student of Digital Media for almost five years now, this paper serves as a nice neat little tool for matching a bunch of names to their corresponding breakthroughs and stoking the fires of my memory. I've studied all of these individuals/devices before, but as their names were never applicable for longer than a test or two (and I'm terrible with names to boot!) they only stuck with me for as long as I was going to need them.
I thought the information graphic prefixing the essay was rather interesting as well. It's completely un-intuitive to look at (in that being able to interpret it relies on an intuition I appear to lack. Actually, I usually find info graphics unnecessarily opaque) but I can tell that it's trying to show a map of the author's influences and/or interests so we can get an understanding of what kind of essay we're going to read.
Writing Style
Now I'm a bit of a writer- if I wasn't going to become a game designer I'd want to be a novelist- so his writing style is almost as important to me as what he was saying.
As a virgin reader of this writing, with little to no information on his background or why he originally wrote this article, I can say that the entire thing felt mildly passive-aggressive, non-committal, and slightly pouty- like an old man who's grumbling that he can't understand his mobile phone, and certainly like he can't exactly place his finger on what he's writing about. His paper appears to be an amalgamation of him reporting on historical trends he's observed, using strange wording to hint at his feeling towards certain theories, and then evidencing a sudden and melancholy complete lack of faith in technological gurus in the last five sentences
The writing style is almost coy, mildly hinting at displeasure without actually saying what displeases him. He primarily lists historical events, only to suddenly throw in a paragraph- quite out of nowhere- at the end that suggests he feels things are spiraling out of control and that technology is leaving humanity in the dirt. Which he doesn't support with anything else, throughout the entire course of the paper (he even kind of contradicts it).
This all is a manifestation of one of my biggest problems with academic papers: frequently they refuse to be read by anyone who does not already have a comprehensive understanding of the social-political discussion that they originally took place in. They are so vague, subtle, and scattered that they cannot easily be interpreted without the comprehensive context.
But I digress.
His Point
From what I could gather from my initial read-through, Mr. Friedewald was attempting to give a short history of human-centered interaction design first by defining and discussing the development of technical determinism and social determinism, and then discussing a transition into social constructiveness, which he appears to support.
Historically, he does a good job discussing major contributors to the field and their inventions/ideas: Allan Kay, Vannevar Bush, Douglass Engelbart, Marshall McLuhan, Memex, Dynabook, the mouse, teleconferencing, the medium being the message- all good stuff.
He was obsessed with software agents, as well. To be honest, I don't think the idea of a software agent is a bad idea; I think its just beyond our current technological means to implement one well at this point in time. For the uninformed, a software agent is something like Microsoft World's Clippy. In theory, it acts like a digital personal assistance. In practice, it has only been able to severely annoy anyone who comes into contact with it.
Dynabook (Allan Kay)
I got particular pleasure out of reading about the Dynabook, because reading Kay's description for the Dynabook was like reading a spec-sheet for an iPad- and I just purchased an iPad2 recently. At the time, Kay was restricted to the vocabulary and ideas of his time. For example, he described the Dynabook as, through an interface to a data network, being able to access the accumulated knowledge of mankind.
Now he was writing this before the truth birth of the internet, and he could never possibly know that this 'accumulated knowledge of mankind' would be accessed by things called 'Google' and 'Wikipedia', but he got pretty darn close.
Jerome Bruner
I had also never read Jerome Bruner's thesis concerning how humans break down and store experiences as mental models. The three types of abilities for how we make these models are: Sensomotoric, Iconic, and Symbolic. Want to hear how they apply? Imagine a child trying to learn the skill of 'jumping' for the first time. Sensomotoric abilities permit the child to look at another person jumping beside them, and then mimic the same actions. Iconic abilities permit the child to examine a picture of a person jumping, interpret the picture, and then mimic what the person in the picture is doing. Symbolic abilities permit a child to hear a parent describe the action of jumping, form a mental picture of how it must be done, and then try to mimic that mental picture.
Why is this applicable to video games/human-centered interface design? Easy: The designer needs to be able to create an interface that people can learn to use. An interface that users either already have a mental model for, or which users can quickly and easily build a new and accurate mental model for.
GUI
The author didn't particularly care for the desktop metaphor; something on which he and Allan Kay agreed. He lamented the failure of Microsoft "Bob" (Look it up, you're laugh. It's like a giant room of Clippys). I think it's important that authors continue to draw attention to the fact that everything about the computer and its current metaphors are fairly arbitrary. The Desktop is just a metaphor after all, and yet it structures everything about how we interact with computers. Inventive young people should know this, and be encouraged to look for alternatives, should they desire.
The author pointed out, amusingly, that many younger computer users from the "Nintendo Generation" who have gathered experience with computers from their childhood contribute to the fact that an office-based desktop metaphor is no longer necessary and may even be restrictive. I agree with this point: young technologically savvy people definitely have different needs than the older crowd.
I also thought it was unique to note that a great many new computerized devices eschew the model of the desktop. My in-car computer, GPS, and mobile devices all lack desktops.
Old vs. New
The author spent a great deal of time discussing the LOGO programming lesson and Kay's discovery that people did not necessarily need a large amount of training in order to use and even develop for computers. Previous to this, it had been assumed that people had to be good programmers before they could use the computer effectively. At this point, before the birth of GUI, his assertion was that a good programming language could be usable by people even by people with very little training. This translates forward into the idea that all human-computer user interface should be conceived so that the humans can understand and work with them with very little difficulty.
Yet after all this discussion and hope for the future, the author ends with the strangest conclusion, including sentences like: "An abyss is yawning between the feverish promises of cybergurus and the experience of typical computer users, who again and again {...} wonder where their data disappears [to] when the computer crashes, who have no idea why they can't get into the Internet. It seems that up to now, the digital revolution has swept along only the computer - and left the human behind."
It was actually sort of odd that he concluded in this fashion. The rest of the paper suggested that developments in HCI were making it easier for laymen to use computers. Wasn't he just a few seconds again simultaneously suggesting that A) products were being made that took into account the metaphors of traditional users like office workers, B) that a new generation of computer-savvy young people was coming up that could handle tasks like coding, and that tools are also being provided for them? Of course we can always improve, but this conclusion seemed rather melodramatic in light of the buildup he made. But on that note he appeared to disapprove strongly of technical determinism, so this may be a cautionary word of advice he's giving out to the cyberguru community.
What New Things I Learned
I will definitely be highlighting this article and using it as reference. It's useful, and it perked my interest in looking at Allan Kay's work a little. I like going back in time to study the problems of previous times, and since I'm interested in iPad development, taking a look at what Allan Kay thought a Dynabook could be used for is actually quite interesting. To extrapolate data into the future and predict where products will be in a few years, you need not only to understand the current ideas of the present, but also the ideas of the past. After all, you need more than one point to plot a line!
Part of any master's degree involves doing a lot of reading and researching, and studying video games is no different. This blog has been commandeered as a forum through which I will be reviewing various readings for my Human-Computer Interaction class.
And so this journey begins with a quick review of The Continuous Construction of the Computer User: Visions and User Models in the History of Human-Computer Interaction by Michael Friedewald.
Disclaimer
Let me begin by say that I am somewhat prejudiced against the academic style of writing. I think I'll write a blog post about that later. I personally think that many academic writing conventions are completely counterproductive to, well, academia. But that's a conversation or another time.
Let me also say that I did not like the writing style of this paper, so while I found it plenty informative, I still had a negative opinion of it!
Reading Purpose
For now let's just say that Michael Friedewald's essay was assigned as little more than a quick survey of the evolution of Human-Computer Interaction. It was featured early on in the book Total Interaction. And it did a pretty good job as a survey. Important names and developments are all sprinkled in for review.
As I've been a student of Digital Media for almost five years now, this paper serves as a nice neat little tool for matching a bunch of names to their corresponding breakthroughs and stoking the fires of my memory. I've studied all of these individuals/devices before, but as their names were never applicable for longer than a test or two (and I'm terrible with names to boot!) they only stuck with me for as long as I was going to need them.
I thought the information graphic prefixing the essay was rather interesting as well. It's completely un-intuitive to look at (in that being able to interpret it relies on an intuition I appear to lack. Actually, I usually find info graphics unnecessarily opaque) but I can tell that it's trying to show a map of the author's influences and/or interests so we can get an understanding of what kind of essay we're going to read.
Writing Style
Now I'm a bit of a writer- if I wasn't going to become a game designer I'd want to be a novelist- so his writing style is almost as important to me as what he was saying.
As a virgin reader of this writing, with little to no information on his background or why he originally wrote this article, I can say that the entire thing felt mildly passive-aggressive, non-committal, and slightly pouty- like an old man who's grumbling that he can't understand his mobile phone, and certainly like he can't exactly place his finger on what he's writing about. His paper appears to be an amalgamation of him reporting on historical trends he's observed, using strange wording to hint at his feeling towards certain theories, and then evidencing a sudden and melancholy complete lack of faith in technological gurus in the last five sentences
The writing style is almost coy, mildly hinting at displeasure without actually saying what displeases him. He primarily lists historical events, only to suddenly throw in a paragraph- quite out of nowhere- at the end that suggests he feels things are spiraling out of control and that technology is leaving humanity in the dirt. Which he doesn't support with anything else, throughout the entire course of the paper (he even kind of contradicts it).
This all is a manifestation of one of my biggest problems with academic papers: frequently they refuse to be read by anyone who does not already have a comprehensive understanding of the social-political discussion that they originally took place in. They are so vague, subtle, and scattered that they cannot easily be interpreted without the comprehensive context.
But I digress.
His Point
From what I could gather from my initial read-through, Mr. Friedewald was attempting to give a short history of human-centered interaction design first by defining and discussing the development of technical determinism and social determinism, and then discussing a transition into social constructiveness, which he appears to support.
Historically, he does a good job discussing major contributors to the field and their inventions/ideas: Allan Kay, Vannevar Bush, Douglass Engelbart, Marshall McLuhan, Memex, Dynabook, the mouse, teleconferencing, the medium being the message- all good stuff.
He was obsessed with software agents, as well. To be honest, I don't think the idea of a software agent is a bad idea; I think its just beyond our current technological means to implement one well at this point in time. For the uninformed, a software agent is something like Microsoft World's Clippy. In theory, it acts like a digital personal assistance. In practice, it has only been able to severely annoy anyone who comes into contact with it.
Dynabook (Allan Kay)
I got particular pleasure out of reading about the Dynabook, because reading Kay's description for the Dynabook was like reading a spec-sheet for an iPad- and I just purchased an iPad2 recently. At the time, Kay was restricted to the vocabulary and ideas of his time. For example, he described the Dynabook as, through an interface to a data network, being able to access the accumulated knowledge of mankind.
Now he was writing this before the truth birth of the internet, and he could never possibly know that this 'accumulated knowledge of mankind' would be accessed by things called 'Google' and 'Wikipedia', but he got pretty darn close.
Jerome Bruner
I had also never read Jerome Bruner's thesis concerning how humans break down and store experiences as mental models. The three types of abilities for how we make these models are: Sensomotoric, Iconic, and Symbolic. Want to hear how they apply? Imagine a child trying to learn the skill of 'jumping' for the first time. Sensomotoric abilities permit the child to look at another person jumping beside them, and then mimic the same actions. Iconic abilities permit the child to examine a picture of a person jumping, interpret the picture, and then mimic what the person in the picture is doing. Symbolic abilities permit a child to hear a parent describe the action of jumping, form a mental picture of how it must be done, and then try to mimic that mental picture.
Why is this applicable to video games/human-centered interface design? Easy: The designer needs to be able to create an interface that people can learn to use. An interface that users either already have a mental model for, or which users can quickly and easily build a new and accurate mental model for.
GUI
The author didn't particularly care for the desktop metaphor; something on which he and Allan Kay agreed. He lamented the failure of Microsoft "Bob" (Look it up, you're laugh. It's like a giant room of Clippys). I think it's important that authors continue to draw attention to the fact that everything about the computer and its current metaphors are fairly arbitrary. The Desktop is just a metaphor after all, and yet it structures everything about how we interact with computers. Inventive young people should know this, and be encouraged to look for alternatives, should they desire.
The author pointed out, amusingly, that many younger computer users from the "Nintendo Generation" who have gathered experience with computers from their childhood contribute to the fact that an office-based desktop metaphor is no longer necessary and may even be restrictive. I agree with this point: young technologically savvy people definitely have different needs than the older crowd.
I also thought it was unique to note that a great many new computerized devices eschew the model of the desktop. My in-car computer, GPS, and mobile devices all lack desktops.
Old vs. New
The author spent a great deal of time discussing the LOGO programming lesson and Kay's discovery that people did not necessarily need a large amount of training in order to use and even develop for computers. Previous to this, it had been assumed that people had to be good programmers before they could use the computer effectively. At this point, before the birth of GUI, his assertion was that a good programming language could be usable by people even by people with very little training. This translates forward into the idea that all human-computer user interface should be conceived so that the humans can understand and work with them with very little difficulty.
Yet after all this discussion and hope for the future, the author ends with the strangest conclusion, including sentences like: "An abyss is yawning between the feverish promises of cybergurus and the experience of typical computer users, who again and again {...} wonder where their data disappears [to] when the computer crashes, who have no idea why they can't get into the Internet. It seems that up to now, the digital revolution has swept along only the computer - and left the human behind."
It was actually sort of odd that he concluded in this fashion. The rest of the paper suggested that developments in HCI were making it easier for laymen to use computers. Wasn't he just a few seconds again simultaneously suggesting that A) products were being made that took into account the metaphors of traditional users like office workers, B) that a new generation of computer-savvy young people was coming up that could handle tasks like coding, and that tools are also being provided for them? Of course we can always improve, but this conclusion seemed rather melodramatic in light of the buildup he made. But on that note he appeared to disapprove strongly of technical determinism, so this may be a cautionary word of advice he's giving out to the cyberguru community.
What New Things I Learned
I will definitely be highlighting this article and using it as reference. It's useful, and it perked my interest in looking at Allan Kay's work a little. I like going back in time to study the problems of previous times, and since I'm interested in iPad development, taking a look at what Allan Kay thought a Dynabook could be used for is actually quite interesting. To extrapolate data into the future and predict where products will be in a few years, you need not only to understand the current ideas of the present, but also the ideas of the past. After all, you need more than one point to plot a line!
Subscribe to:
Posts (Atom)