I liked this article. I liked this article so much that I actually don't even have much to say about it, that's just how much I liked it. It's like when an English teacher gives you back a paper; if it's covered in red ink you did a bad job, but if the page is blank and pristine you did a good job.
What Was It About?
Let's see, well, let me give you a basic synopsis of this article before I tell you why it was so awesome. It was published here as I believe part of a PHD Thesis, in 2002, in Human Computer Interaction (Copyright 2002, Lawrence Erlbaum Associates, Inc.)
It's written by two computer scientists, one in Italy and on in Chile, and a psychologist in Chile. Most of the research appears to have been conducted in Chile. The authors explain in their abstract that the purpose of their work was to provide a game design reference. They wanted it to stick closely to real player preferences, and they used a qualitative but empirically rooted research process to find out what those preferences were. Since the scope was so broad, the article limited itself to studying the playability of a wide variety of action games; due to the dearth of female participants, their sample was entirely male.
Why Did I Love It?
It was well written. The writing was smooth, natural, and moved from point to point effortlessly. Each point was contained within a paragraph for easy reading. The paper was phenomenally structured. It was unambiguously clear. At no moment in time was I ever forced to reread a single sentence. A table of contents, an excellent abstract and conclusion, and various diagrams kept the scope, purpose, and point of each page, each paragraph, each sentence clear. This paper was a PHD research paper for goodness sake, and weighing in at a whopping 54 pages. Research papers can be some of the driest, most convoluted, jargon-filled, painful things in the world to read. This paper was smooth, pleasurable, and informative sailing.
One thing I hate about some academic papers is the way they meander around in a cesspool of opinions and implied subtitles. They're not clear. They feel like you just stepped into a room in the middle of a conversation. Without a full knowledge of their context, each text can deliver a multitude of widely divergent readings (Like, for example, did you realize I was using the art-historical definition of 'text' and 'reading' right there? No? Oh sorry then, you just walked in on the context of my life, but I'm writing an academic paper so I can be all coy and you can totally miss my point and that's your fault because you should be more informed on this subject before I'm willing to communicate ideas with you. ... Ya know or I could just briefly mention that Roland Barthes "From Work to Text" was required reading in my Art History Course and I thought his ideas were needlessly vague, in-the-clouds, and inapplicable, especially when read back-to-back with Foucault, who wrote pretty clearly and powerfully on power theory (which you may have seen referenced when discussing class, race, or feminism), but I digress!)
These kinds of papers are potentially useful (Oh my god I'm about to whip out HCI terminology) but they are very low in terms of usability, because they are not orchestrated/designed/written in such a way as to be easily used by the audience that wants to/needs to/could/should/would read them. They are more like fragments of an infinitely long Facebook conversation, and heaven forbid you not have access to the context ahead of time.
But Playability, the article I'm blogging on? Playability was clear as crystal. In the words of my English teacher (who was surely quoting someone else, and whom I regularly ignore), all papers should begin with an introduction, a body, and a conclusion. In the introduction, you tell them what you're going to tell them. In the body, you tell them. In the conclusion, you tell them what you just told them. Playability followed this convention. It sat down and laid out all of its cards. It explained its purpose, its motivation, its layout, its limitations. It laid bare its entire internal structure. On thorough examination, I found that its internal structure was so thoroughly and beautifully logical, that it could have only come from the magnificent union of a computer guy, a psychologist, and a dedicated editor. I might as well have been reading the physical manifestation of Object Oriented Programming; Each section, each paragraph, was beautifully concise, encapsulated, functional, easy.
The argument as a whole was sound. The paper outlined a problem, explained its purpose, justified its means, described its process, proffered its findings, and enumerated its own shortcomings. Few to no faults were to be found (and I scoured, I'm a perfectionist like that.)
Furthermore, the authors did something phenomenal. Every time they sought to bring in theories, frameworks, or other cite-able information to support their case, they provided a brief and concise explanation of where that information had come from (like importing in a .h file as an interface! Ho-ho my comp sci metaphors are all over the place today! I can't help it, my more artsy metaphors aren't as useful in such rigid and structured papers!). This immediately set it leagues above other papers in my estimation, as I was never forced to pause in my reading to research other people, or try to decide which of their multitudinous theories the author was referencing at any given point in time. I could always check them out later, if I were interested.
What Was It's Structure?
The paper began with an abstract, a description of its authors, and a table of contents. The table of contents were organized down to three tiers. The upper most tier read: Introduction, Method, Results, Conclusions.
The Introduction was split into a description of the problem, preexisting information on the topic, and scoping the research that the paper was now offering.
The Method was split into a description of the framework, an explanation of data collection, and then a break down of the data analysis based on the framework (and it want point by point, in excruciatingly precise and elegant detail)
The Results were divided according to main and sub categories of findings. When I turned to look at the results, I found that the authors had organized their findings according to a categorical tree. For every given sub-category, the authors had supplied a diagram to illustratively describe the current page's place in the grand scheme of the research. It was a beautiful technique for helping the reader to visualize, track, remember, and parse their enormous quantity of data. Their entire paper could have been broken apart and accessed as part of a tree, with each section belonging to a node of that tree. T'was glorious.
The Conclusion was divided into the relevance of the work, and the boundaries of the research and perspectives for future studies. The paper made no bones about its own limitations, but offered itself as-nevertheless- one of the best and only tools available for its purpose.
What Was It's Content?
The authors briefly touched on existing design theories. Some of these theories had been offered forward by theorists working in edutainment (Malone was mentioned, I'm going to shelve his name for future reference since he appeared twice in such rapid succession :D), and others had been offered by entertainment industry professionals (They used Rouse- not because he was the most enlightening, but because he summarized everyone else the best ;) I always found Rouse a little dry).
The paper then suggested that the data in the first category was flawed due to it being too-specific and not representative of mainstream video games. The second category was flawed due to lack of empirical methodology. This is important! You could argue all day, either that industry professionals have a better sense of the truth than detached theorists due to personal experience, or that theorists have a better sense of the truth due to a better sense of perspective-> This paper resolves the conflict between the approaches by merging them. Walla. Lovely!
The authors described and justified their methodology in excruciating detail. They left nothing vague. They diagrammed samples of the exact and highly detailed and structural way they had broken down qualitative data, conducted their analysis, formed categories- even the way they broke down any given sentence or determined the relevance of each noun and verb to the overall game- was covered in thorough detail. They made sure that not only was their research repeatable, but that it could be used again in other contexts, or to extend the original research forward, with absolutely no ambiguity or confusion. Perfect. Perfectissimo.
Then the authors described their findings. Their findings seem absolutely obvious to a tried-and-true gamer (the author's concluding sentences even suggested that the work had more value in teaching design, academia, and communicating with non-game-professionals, than in boosting the performance of professionals) and yet at the same time seeing them laid out in detail provided structure to what game designers could always sense, but never before explicitly justify. The paper provided a list of prescriptions and recommendations for ensuring the play-ability of an action game, which could then be used by a designer as a mental checklist (not an exhaustive checklist, but more of a bare-bones, "Did I overlook anything really important and easy to miss?" sort of thing.), or to argue a case with non-gamers about why certain features were crucial to a game's success.
Their results, as a compilation, are an exhaustive resource on the narrow subject they cover. They could be used for an exhaustive playability analysis of almost any action game on the market- then or now- and be used as a reference point for understanding a game's successes and failures.
What I Got Out of It
The game I'm designing is a bit of a hybrid; It's not exactly an action game, but it should pave the way for casual gamers to migrate into the action genre. Reading these recommendations not only helped me think about what to do in my game, but also to think about my game in the context of the action genre. More importantly, as I'm going to be expected to carry out a lot of research in the near future, the paper was absolutely wonderful about taking a methodology framework and applying it to games for the purposes of research. I can use this paper as a reference, an inspiration- heck, even a guideline (if I wanted)- for how to conduct my own research. Previous to reading it, I was very hesitant about how to go about collecting my own qualitative data concerning video games. Now I have a much better idea of where to start, and where to go.
I Give This Paper an A++. Well done, Authors. Well Done.
(I could have given them an A#, but it wouldn't have been as trite/clever/whatever.) They are better writers than I have read in many a moon! They're certainly better at technical writing than I am- I wander all over the place! Good Job, Authors. I enjoyed this reading.
Tuesday, April 24, 2012
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)