Comments on Foundations of Interaction Design

Thomas Petersen — Tue, 11 Sep 2007 07:32:38 GMT

I think with regards to for instance the MS mobile interface compared to I phone Wittgenstein sums up the difference:

“Today the difference between a good and a poor architect is that a poor architect succumbs to every temptation and the good one resists it”

This might be a detour from your conversation but I somehow got to think about this quote when I read the article and the discussion. I phone was a good idea to begin with and ended up being a great product because each link in the process where able to be true to the original vision instead of succumbing to the temptation of adding new stuff.

That is actually IMHO the most important factor, the ability to carry an idea the all the way through to completion without hesitating.

I always think in frequency of use. The higher the frequency, the lesser the narrative and vice versa. Therefore in more complex interfaces (take photoshop or 3D Max as an example) its not really the storyline of the GUI that is the key factor.

Terry Bleizeffer — Tue, 04 Sep 2007 13:43:45 GMT

David – I agree, I don’t think CLIs are inherently less abstract than GUIs. In fact, I might even go out on a limb and say that it’s probably the most common case that there is no real difference in abstraction level between the two, because usually both are based on the same model. Is describing your action textually more abstract or less abstract than the same action using pointing & clicking? I’m not sure… it might depend on the action.

But, in the product I work on, the CLI is definitely less abstract than the GUI. It’s the modern CLI equivalent of coding in binary! =) This is not by design, it’s actually a problem that we’re trying to solve, because our CLI is so close to our programming model that the learning curve it is very steep. In fact, we’re adding a layer of abstraction on top of the CLI (a “command framework”) so people can do some useful stuff without learning the full CLI language. So my statement above is less a generic statement that CLIs are less abstract than GUIs, and more a statement about trying to assist users in moving between abstractions.

Regarding the choreography debate, first, “The Fifth Element” is an underrated guilty pleasure! Second, let me see if I can make my point differently and see if we still disagree. Building on the movie analogies, the recently released “Stardust” was by most accounts a very good movie AND a commercial failure. Why? Apparently the studio’s marketing team couldn’t figure out how to sell the film. There were terrible trailers, bad ads, bad posters, etc. People couldn’t figure out what the movie was trying to be from the marketing campaign. Was it a kid’s movie? LOTR? An action movie? A love story? And mostly, IMO, there was no emotion attached to the trailers… people couldn’t predict how the movie would make them feel. This happens a lot, but usually it’s because the MOVIE doesn’t know the answer to those questions, so the marketing does what it can with a bad product. (Aside – actually I think the opposite is very common… a bad movie with great marketing) In this case, the movie knew, but marketing didn’t. And, I might add, the director wasn’t happy (even before the movie released) with the marketing… so that part obviously wasn’t his call. So the question is: who was in charge of the “holistic narrative” between moviegoers and “Stardust”? The answer is clearly “lots of different people”. And there was definitely no single choreographer… and the breakdown of one part of the whole basically doomed the movie.

Now, you might argue that one person should have been in charge (and I might agree), but a) it’s unrealistic in my experience, and b) if one person is in charge it won’t be a “worker bee”. There’s no IxDer in the world who I would trust with choreographing my product’s holistic narrative… and there’s no UXer or technical architect or information architect or marketeer or anyone else who I’d trust either. All those roles are too specialized to be in charge. They each need to add their special skills to the whole, including IxD.

Wrapping up, in my first comment I said, “To put it another way, if I knew a product’s ID and the design parts that were being choreographed, does it follow that I must know the holistic narrative? I think not.” Now my analogy is, “If I sat and watched “Stardust” without knowing anything else, would I know the holistic narrative? No, because the holistic narrative starts long before someone sits down in the theater.”

David Malouf — Mon, 03 Sep 2007 17:27:04 GMT

Ok, so I’m sitting here writing my slides for my course I’m teaching for SmartExperience.org (Interaction design of rich web applications) that starts this Wed. (6 2hr. classes). (Yes, that was an obvious placement advertisement.) and it occurred to me that in Terry’s comment above he was assumes that CLI is less abstract than a WIMP (or GUI) interface.

I think I have to disagree. While typing something out is definitely easier from a Fitts Law perspective so long as the number of keystrokes required is kept to a minimum, the act of describing your actions in non-direct linguistic forms is actually more abstract than the act of navigating & pointing-&-clicking. I’m sure there is some give and take in here as some elements are more abstract and some are less in both interaction models, but I think the assumption that CLI is less abstract is actually a false one from my subjective off-the-cuff analysis.

Maybe Aza can chime in here? I’ll poke him to the discussion.

David Malouf — Mon, 10 Sep 2007 23:02:59 GMT

Wow I’m so flattered by the incredibly thoughtful discussion going on here based on my article. I want people to know that these types of amazing analytical responses are exactly why I write for good zines like B&A. It gives me a thrill to be engaged like this. I acknowledge that I do not have all the answers (I also acknowledge thanx to my editor, I had 2500 word maximum, which is an extension from the usual for B&A).

Great comments from EVERYONE and why people think they are disagreeing with me, I think the nuances that make IxD so compelling for me are what people are getting at. It is so hard to get specific enough (especially in an article) to fill it all in.

Using the twiter markup that Terry started, I’m going to start at the bottom and jump around from there.

@Paul
Yes, I mean the components of the interaction design itself. “Goals & Motivations” are part of the context of the problem space, but do not make up the interaction. This is similar to how I separated out the “form” elements that Dan Saffer discusses in his book as foundational elements of IxD. All design has Gloals & Motivations of the user that they must acknowledge and they are integrated into the whole.

@Matt
Nothing to say here. I think this is a great extension and clarification of what I am thinking as well. Thanx for doing that.

@Jerry
I love this clarification that the cultural, sub-cultural and even personal psychology will have a dramatic effect. This is why it is so key to have great models of your personas (See About Face 3.0) that try to include cultural, cognative pieces. I think there has been great work about the social vs. the individual for example between US and non-US cultures on a continuum.

@Terry
Thanx for the CLI example. Aza Raskin is going to be speaking at IxDA Interaction 08 | Savannah in Feb 08 (interaction08.ixda.org) and while he isn’t speaking directly on one of his favorite topics, CLI, he will probably love to talk to anyone who is doing work or otherwise interested in CLIs.

Now to the meet. I think I agree and disagree w/ you about the choreography issue. I see what you mean about the collaborative nature, but someone needs to be driving the vision. If all the design disciplines are equal partners I feel that leads to a muddied vision. To me all the design disciplines are working together towards a goal of creating and communicating interactions (in this space anyway). So while I’m not trying to create a land grab here, I do see it that IxD stands in the conductor’s podium. Sometimes a conductor’s job is to make himself invisible, even make the composer invisible and let the virtuoso take center stage. This may mean let the ID or IA shine through, but to me someone has to lead this by putting the total IxD narrative in the right light. It is like a director who is able to really let an amazing Cinematographer go to town, or a production designer. I mean what would the “Fifth Element” be with Godier’s (sp?) amazing costume design and the other production artists? I think this happens a lot with Apple’s products which really make people feel that it is the visual design that is most important to their products (the total form factor), but that is totally just a gateway “bluff”. It is the ease of adoption through the enticement of that gorgeous interface that leads you to the real meat in their products, but that play that is being done is key to the total interaction design that is being presented. I would even say there are usability weaknesses in that strategy that lead to better user experience and interaction design overall.

Paul Bryan — Thu, 30 Aug 2007 12:04:02 GMT

Thanks for this thoughtful article, David. I agree with the foundations you listed, but was left wondering why you didn’t include a foundation for “goal,” i.e. why I undertook the design, and why anyone else would undertake the steps of the interaction. Fully understanding the context and mechanics of relevant goals seems fundamental to any interaction design, and constrains all of the other foundations you describe. Unless by foundations you mean the components of the interaction itself, or the philosophy of the art apart from the science.

/pb

Matthew C. Clarke — Mon, 03 Sep 2007 16:40:52 GMT

_But metaphors appear to succeed best when they are imprecise and the user has to fill in the gaps from their own understanding._

I think you can take that idea further. As you noted in different words, a metaphor is a map that captures certain correspondences between one domain and another. A metaphor only works if the user already understands one side of that correspondence. In terms of interaction design, the metaphor maps elements of a pre-existing mental model onto the internal computer model.

Going deeper, it is essential that the metaphor maps *some* features but not *all* of them. The balance between which elements are mapped and which aren’t is crucial. The elements where there *is* a correspondence are those that give the metaphor its evocative power; but it is the elements where there is no correspondence that highlight the usefulness of the interaction.

For instance, the Trash Can metaphor is so helpful to understanding because throwing something into a physical trash can corresponds to the operation of dragging a file to the on-screen image of a trash can. Similarly for taking something back out of the trash prior to emptying it. But there is nothing in the on-screen behaviour that corresponds to uncrumpling the paper once you’ve retrieved it from the trash, nor to the dirt stains on the paper. (I heard this example from someone else, most likely Donald Norman.)

If the application of a metaphor was completely accurate, there would be no advantage in the computerised interaction. The computerised interaction needs to reproduce the features of the metaphor that people want, but the value of computerising the task depends precisely in those features of the metaphor that are *not* reproduced.

Matt.

Terry Bleizeffer — Mon, 03 Sep 2007 16:40:58 GMT

Regarding, abstraction and CLIs, we use a technique in our administration GUI that allows users to view the CLI equivalent of the action they are performing, which allows them to move from the more abstract GUI model to the less abstract CLI model. This is important because we know from research that our users tend to start first with the GUI to learn the concepts then transition to the CLI for power and control. Rather than fight this, we try to enable it.

Regarding abstraction in general, the problem I see is more practical than theoretical… good abstractions are really frickin’ hard to design. And bad abstractions are often worse than no abstraction. How many times have you been using a product with an abstraction intending to help you, then the abstraction breaks down in one place and BAM you have to consume all of the underlying complexity to make progress? Development tools do this all the time – you get a nice WYSIWYG builder that works 90% of the time, but to accomplish the other 10% means learning everything that the WYSIWYG builder was attempting to hide. On the other hand, I’ve had techies tell me that we should expect all of our users to know our product’s installation file structure, and if they don’t they have no business using our product. So abstractions are hard, but the alternative is too horrible to consider. =)

@laurie – I particularly liked that section as well, for the same reason. I think it’s rarely the case that time on task is a useful metric, and focusing on time on task can lead to bad design. People would rather spend 30 mins on a task where they always know where they are and what they’re going to do next and exactly when they’re done, then spend 15 mins blindly trying random techniques that may or may not be working.

@David – I enjoyed the article, but I disagree with one small part of it. In the very last sentence you say, “In the end, interaction design is the choreography and orchestration of these form-based design disciplines to create that holistic narrative between human(s) and the products and systems around us.”

There’s a lot of nuance in the world of “design”, and I think it’s worthwhile to break “design” up into pieces to understand them individually as a learning technique. Where does information architecture end and user experience begin? Where does visual design end and interaction design begin? These questions might not have clear answers, but trying to tease the pieces apart makes it easier to understand how each contributes to the whole. But interaction design, IMO, does NOT sit at the top and choreograph the “holistic narrative”. It’s just one of many pieces contributing to it. To put it another way, if I knew a product’s ID and the design parts that were being choreographed, does it follow that I must know the “holistic narrative”? I think not.

This is probably semantic quibbling, but I bring it up because I think there’s a tendency for people to try to break “design” into pieces to better understand them… then forget that a) it’s the overlap between the pieces that are most interesting, and b) none of the pieces define the whole. I’m not saying that you’ve forgotten this, I suspect the sentence was just worded so that it made a broader point than you intended to make.

Jamie Owen — Mon, 03 Sep 2007 16:41:02 GMT

Thanks for this article, David—it’s encouraging to be reminded that the human experience is at the heart of the design-centered disciplines you listed. Often the details of our workday obligations obscure that perspective (for me, at least).

Much like differing cultures have recognizable characteristics unique to their dance and their music, the “choreography and orchestration” of their interaction should also be designed as to their unique cultural characteristics. In short, the elements of the foundations are different culture to culture.

I think your orientation to foundations needs to be considered separately for each cultural audience of interactors we are designing for. And this may not necessarily be across national boundaries. Even the differing levels in a given society need to be considered.

You spent some time discussing “abstract,” for example. Different groups have different ideas of what abstract is—or have different levels of comfort with the abstract. An easy illustration of this is Asian cultures’ and Western cultures’ thinking patterns and how elements onscreen match these patterns (thinking patterns can also involve “pace” as well). And different cultures have differing ways of looking at time, color, language, and semiotics, too.

Your discussion of metaphor and your mention of aesthetic are tied together when considering multiculturalism within the interaction. Bluntly, unfamiliar metaphors violate a cultural aesthetic. The user may then grant less agency to the interaction out of resentment or confusion, rendering the design ineffective. This may be especially true when one of the two cultures is more powerful or somehow has an advantage over the other. For instance, as we become more globalized, we Westerners need to consider this agency as our human capital stores are more and more diverse (okay, I’ll say it: outsourcing). Indeed, we can’t slow down the bus of capitalism in order to accommodate each and every user group. But if we want members of those other cultures to be viable resources at our technological level, we need to meet them half way with that technology. At least related to my comments here, that halfway point means responsibly infusing their cultural aesthetic into the interaction.

As you’ve said, in order to behave, the tech-based products and systems need to respond to human stimuli—with an amazing cultural array of humans using the technology, “behave” can mean an array of different things.

laurie kalmanson — Mon, 03 Sep 2007 16:41:06 GMT

david—great piece

my favorite part: “Narratives have pacing. We experience that most clearly when we watch a movie. A great movie will have you coming out of a theatre having never looked at your watch. Pace is also a part of interaction design, but in some cases a good experience may have you looking at your watch–hopefully not out of boredom but because you need to know what time it is to complete the goals of the interaction.

that part especially is awesome and important because it exactly the smashes the paradigm of usability testing that consists of asking people to stand on their heads and timing them and putting the results in a spreadsheet … which tells you only that jane did it for 10 seconds and john did it for nine … never addressing whether they wanted to in the first place or whether they enjoyed it, etc.

it’s similar to those airport studies re baggage claim: it’s not how long it takes from the gate to your suitcase, it’s how it feels while you’re doing it

very nicely done.

David Malouf — Mon, 27 Aug 2007 20:01:54 GMT

Oh! I agree that different contexts will require different levels of abstraction. Teleperception may be as abstracted as we get, but may lead to amazing interfaces for example.
I’m not sure about graduating to CLI. I’ve tried to make Enso (Humanized.com) part of my life and just couldn’t make it more useful than my current mouse-based gesturing systems that I’m so used to. But I like the steering wheel example.
Another way is the two lever steering of a tank where you direct the tracks to go forward or back and you steer by increasing or decreasing speed of the wheels on the left or right side to go in the proper direction, like using a wheel chair or rowing a boat/canoe/raft/kayak. To me that has more abstraction but also leads to more efficient and proper interaction.

But for digital systems, I do find in general so far that lowering the abstraction layer is better so long as that abstraction layer is designed well. Ergo MS Windows Mobile while capable of touch-screen interfaces is not nearly as good at it as the iPhone. It just wasn’t designed well to do it.

Pauric Pauric — Thu, 27 Sep 2007 21:04:25 GMT

Dave, on Abstraction;

While not countering what you’ve said I was left with the impression you believe its better to reduce abstraction. I’m not sure that should be a goal in itself, I would say its better to push out the abstraction to the right level for the given interaction.

For example, the very first cars used something akin to a boat tiller for steering. It had poor mechanical advantage so a steering wheel was invented/implemented which added a layer of abstraction. Similarly, if we were to blindly reduce the abstraction in an interface it would look like a display panel from the Matrix. Or, we’d all be assembler programmers (o; I like to think that there are three parties when it comes to abstraction; the user, the system and the ‘tasks’. Its the designer’s job to triangulate the design to meet the requirements and constraints of those three.

Also, I feel the level of abstraction needed is based on the user’s understanding of the system’s operation/capabilites as well as their experience in their domain. As that understanding increases then the abstraction can be reduced. My users often graduate from web to CLI when they achieve a level of experience and search for better flow.

Its a complex topic and I’d really appreciate your thoughts on how to arrive at a balanced abstraction.

Great article btw – thanks, pauric