design

About

Syndication

Categories

Archives

John Zimmerman on Idea Generation and User-Centered Design

design

August 19, 2004, 10:04 PM

John Zimmerman, one of the three resident Design professors in the HCII, came to our capstone project class a few weeks ago (you can tell I'm behind...) to talk about ways to create user-centered design ideas. He espoused several interesting views that in many ways are fundamentally different from the more data-centric ways we've learned in the MHCI program.

John talked about several strategies you can follow to create innovative and appropriate designs:

• Draw from user intents, not from tasks, needs, or problems. What John means by "intents" seems to be the same thing Cooper means by "goals"; they are the underlying purpose of the user's desires and actions that remain constant even in the face of changing environments and technologies (unlike tasks, which vary). Understanding your user's real intents will free you to look at new ways of fulfilling them without straying from the path of user-centered design.
• Visit analogies and metaphors. In the course of designing, a common means of generating new ideas is to come up with metaphors, or solutions that are somehow similar to the ones you're considering. John suggested that you not just invent such metaphors, but actually get out of your office space and visit them. For example, a project team developing a document organization system for an operating system came up with the metaphor of tombstones in a graveyard. They went to a graveyard and examined the metaphor in its real setting to help flesh out the metaphor.
• Design for extreme users. Instead of imagining normal, middle-of-the-road people such as those commonly captured in personas, invent interfaces for the edge cases. If you're designing an MP3 downloader, think of the user who only downloads one song every five years and the one who downloads 50 a day. Alternately, there's the designing for extreme users technique (that I've mentioned before), which calls for looking for unusual types of users in addition to edge behaviors. John says he uses this technique to generate new ideas when he's stuck; obviously the interface that's appropriate only for an extreme edge case user would not be appropriate for the final design.
• Channel your personas. Actually those are my words, not John's, and I use them slightly tongue-in-cheek. John believes Cooper's concept of personas is almost right, but not quite. It's not enough to define a specific user and design an interface for them. John belives it isn't possible for a designer to design for anyone other than himself. However, it is possible to become the user; you can think like they do then design for yourself, rather than thinking like yourself and trying to design for them. If you're in a team, one person could assume the role of a persona while the others ask him or her questions.
• Live with the work. Put your designs up on the walls of your project space, so that they're always visible. Yet another benefit of radical colocation.
• Sketch on the way. Always be engaged in the act of design. Start doing low-fidelity sketches from the first day of the project; don't wait until you have all the user needs "right" before starting to think about the product itself. Most of these sketches may be discarded, but they will keep you focused on how what you're seeing influences the design effort.
• Design for the presentation. John feels strongly about this, although it is controversial. He suggests focusing on the final presentation of your work (whatever that might be) from day one, and avoiding any work that isn't feeding into that final presentation. His rational is that if you don't keep focused on the final results, you'll waste time looking at details that aren't important for the current stage of your project. If they won't be in the presentation, nobody will see them, and by the time they're relevant, they'll be obsolete. Basically you want to do the right work at the right time (very XP-ish in this regard) by keeping focused on what your audience's current problems are and what will excite them.
• Generate scenarios or stories of use. Oftentimes, individual sketches can't capture enough information to express an interaction design. Scenarios of use can fill in the details by describing the entire course of the interaction. Stories are often the best low-fidelity way to prototype an interaction design.
• Get yourself in the right mindset. To create new ideas, you have to learn how not to think. Though you have probably accumulated a sophisticated understanding of your users' goals, tasks, workflows, processes, etc., you need to be able to let this go at times and let your intuition guide your design thinking. Too much understanding of how things are can impede your ability to think about how things can be. It's also important to foster a team environment where it's ok to come up with less-than-brilliant ideas, since only by seriously considering the less good (if not downright silly) ideas can you get to the ones that are gold. To do this, you need to be able to trust your teammates; if you don't, you won't feel comfortable expressing half-baked ideas and this will impede creativity.
• Say "Yes, and..." During brainstorming and ideation, it's important not to start critiquing and shooting down ideas too early. Instead, build on your teammates ideas to take them to the next level. If someone shoots out a half-baked idea, don't think "what a crappy design idea", think "how can I take this further"? Brainstorming should be fun, not competitive.
• Stand up. You're less creative if you're sitting down. This might be a personal preference, but I certainly find I'm at my best when I'm pacing the floor; somehow the physical activity jolts my mental activity into overdrive.

Finally, John had a couple of things to say about user research. He warned us that our interpretations of the underlying goals and needs we uncover during user observations are generally going to be wrong. On the other hand, users' perceptions of their goals and needs are also wrong. Effective interpretation of user research lies on reconciling these two to arrive at something right. To do this, you need to do more than just observe; you have to show users the concepts you've created and get them to react. You can talk forever about abstract goals and get nowhere, but the instant you put a real, working interaction design (or some low-fi version thereof) in front of a user, she'll immediately be able to say "Yes! This is exactly what I need!" or tell you what's missing.

Understanding needs must be complimented by making things. User research and interaction design need to walk hand-in-hand throughout the product life cycle.

[ Permanent Location ]

Newsapple

design, internet

June 29, 2004, 03:18 PM

I came across a video of the next version of Safari's news aggregator capabilities (via Andy, via Dave). I was struck by one thing; damn, but it looks a lot like Newsable! Right down to the sort and archive (or "recent articles") options. Of course, I can't really tell that much about its full feature repertoire from peering at the short and small video, but that's the impression I got about the core interaction, anyway.

I'll admit, it's improbable that Apple really got the idea from me (though it wouldn't be the first time ;), but it is encouraging to see that what I came up with was very similar to their design. Seems I must have been on the right track, at least.

On the other hand, this does cast Newsable's future into a certain amount of doubt, since I'm not sure I want to compete with the likes of Apple. Chad and I had some ideas for new directions we could take Newsable (not gonna tell you what they are; Apple might steal them), so maybe we'll have a chance to work on that someday. In the meantime, though, maybe it's time to start thinking about that WYSIWYG blogging tool I've been meaning to write...

[ Permanent Location ]

Role-Oriented Workspaces

design

June 24, 2004, 10:20 PM

Like many knowledge workers, I find myself playing many different roles throughout the average day. Some of these roles are part of my personal life, many are part of my professional life, and an increasing number of them involve my computer in some form or fashion. For example, I'm a research assistant on the U&SA project, the project manager for our capstone project team, a soon-to-be unemployed user-centered designer looking for a job, and of course the author and maintainer of this here weblog, just to name a few. I've mentioned some thoughts on how to deal with role overload before, but now I'm thinking of ways that my computer could help me out with this problem. What I really need is a role-aware operating system.

Unix windowing systems have supported multiple desktops for a long time. For power users, this is a useful feature since it allows you to organize the windows that hold your documents and applications in some sort of task-oriented fashion. But this is only part of the way towards supporting different roles. Certain programs may need to behave differently depending on what role I've currently assumed; for instance, my instant messaging and email clients may need to log in to different accounts depending on whether I'm in a "work" role or a "home" role (and perhaps should automatically put up appropriate away messages when I'm switched off of a role). Certain preferences settings may need to be different. And so on.

The latest version of Mac OS X, Panther, supports this notion better by providing a fast way to switch between multiple logged-in user accounts. But this may be too much separation; the tricky part of implementing a role-aware operation system is hitting the proper balance between separation of different roles and integration of globally useful options. After all, this is the same person and his activities will often not fall neatly into one role or another. If the system puts up too many barriers between roles by making it hard to get information from one role to another, this paradigm won't be useful.

At any rate, I think this is fertile ground for design exploration.

[ Permanent Location ]

Design, Usability, and Innovation

design, usability

April 18, 2004, 08:54 AM

A few weeks ago, I went to a talk given by Hugh Dubberly on models for design (Dan has a very nice summary, as usual). During the talk, Hugh made a point about design and innovation that's stuck with me; he remarked You don't get innovation from the design process. You get quality from the design process. At the time, that struck me as quite true.

Since then, however, I've had second thoughts. Let's consider an "innovation" (an overloaded word) to refer to "some technology-related change that has a significant impact on the ways people behave, generally for the better". I think that captures it reasonably well for my current purposes. Usually when we think of innovations, we think of some brand new ideas that spark new technological developments, like televisions or automobiles. And its true that the design process won't get you these; great new ideas are elusive things and so far no one has found a process to repeatably elicit them (though there are some brainstorming techniques that can help).

But there are times when innovations are not spawned by brand new ideas. There are times when the innovation involves taking an existing technology and making it accessible to a new (probably wider) audience. Or in taking a technology that used to be complex and cumbersome to use and making it quick and simple. Suddenly, the technology is accessible and it becomes an innovation.

The GUI desktop metaphor is a classic example. Affordable computers were available before PARC's innovation got commercialized, but only hobbyists bought them, because they were just too tough for the average person to use. With a well-designed interface, however, personal computers became a reality and an innovation was born.

iChat AV is a more modern (if also more modest) example. Voice-over-IM has existed for a long time in AIM, but nobody used it. All Apple did was make it dead simple to use. Suddenly it becomes useful to the masses, and we have innovation.

Style sheets and the single-sourcing paradigm might be a design innovation waiting to happen. Style sheets are useful to some but inaccessible to most due to the complexity of dealing with the badly designed interfaces for creating and applying them. If someone were to create a more usable interface, we may have innovation.

This is, I believe, the role that design plays in innovation. Not in consistently generating world-changing ideas (these come from a multitude of disciplines) but in turning these ideas into something simple enough to affect the lives of thousands.

[ Permanent Location ]

Marketing and User Research

design, usability

April 16, 2004, 11:01 PM

I've been thinking recently about the relationship between market research and user research.

Market research is conducted by marketing departments, who are mainly concerned with figuring out what sorts of products people are willing to buy and what sorts of people are willing to buy them. I am very ignorant of marketing research techniques, but my current understanding is that they tend to involve conducting surveys and possibly focus groups with the intent of nailing down a market demographic that the company can sell some new product to. Marketing may also collect information on what features and attributes of this product are important to swaying this demographics' buying decisions.

User research is conducted by user-centered designers, who are mainly concerned with producing the interface and interaction design of the new product. As Beyer and Holtzblatt point out in Contextual Design, the kind of data necessary to drive product design is different from the kind of data collected by marketing; market research alone cannot drive research-informed product designs. UCDs require more detailed information about what the people behind the statistics are like, what their goals are, how they are currently performing their tasks, etc. B&H have already made this argument eloquently so I won't bother rehashing it here.

All this isn't to say that marketing's data is useless to UCDs, however. In fact, a reasonably thorough market analysis is absolutely necessary to have ready before design research begins. If marketing hasn't narrowed down the target user population, design won't know where to start looking to collect their data. They may wind up taking a scattershot approach and (at best) waste time talking to the wrong types of people or (at worst) design a product from data on the wrong users.

Just as marketing's data can't substitute for design data, design shouldn't be expected to collect market data. Because design research involves more detail-oriented studies, these studies cannot uncover a broad picture of the market needs on a large scale. A mistake I've seen among novice design researchers is to spend time sending out surveys to uncover a market for the product when this information was basically provided to them by the marketing team. This is a waste of time, not to mention an inappropriate application of skill sets. Design should be focused on how the real people behind the demographic numbers marketing generated are working, communicating, and feeling, for this is the information they need to create great products.

[ Permanent Location ]

NEC's Future Designs

aesthetics, design

April 04, 2004, 02:26 PM

Jodi sent me a link to some product concepts developed by designers at NEC. A couple of them are kind of similar to two of my IID projects from last semester; the "tag" device reminds me of my scheduling snake (look at the first picture on the page especially), and the flacon is vaguely similar to the "Keep in Touch" application I did with Elizabeth and Chun-Yi. Not that I'm claiming NEC are culling my weblog for ideas or anything, but it's sorta neat to see that the technology that will make designs like these possible is actually in the works, and that professional designers coming up with concepts that are similar to the ones we're coming up with here.

I feel all designy.

[ Permanent Location ]

Life Lessons for Designers

design, processes & methodologies

March 26, 2004, 10:16 AM

Found via Dan, this article titled "The Top Ten Things They Never Taught Me in Design School" is interesting reading for those of us who are starting careers in one of the subdisciplines of design (or hoping to, anyway). Some of these ring true for me already, partially due to my (admittedly marginal) professional experience but also because of my experiences here at CMU (so some of them can be taught in design school, albeit indirectly). For example, I'll buy the "95% of any creative profession is shit work", especially after playing project manager for our capstone project. And this is important to come to terms with, because you probably won't be too happy or successful as a designer if you can't learn to take the bad (think convincing management that your design is important, writing up user testing reports, fighting with developers over technical compromises, etc) with the good (sitting down to do some creative design work).

Others I can certainly see as important, but I recognize that I need to get better at, like prioritizing and not over-thinking problems. And a few sound pretty familiar from my experience as a software developer, like "Start with what you know; then remove the unknowns".

It's good to remember, every now and again, that things work differently in the real world than they do in the ivory tower of academia.

[ Permanent Location ]

Moving Outside the Device

design, systems

March 19, 2004, 03:31 PM

I've been the proud owner of an Apple iPod for a while now. Although I'm happy with my purchase, I do have some issues with the little device. These issues can be summed up in a sentence: it doesn't really talk to any of my other devices. Not that its alone. My devices in general are a rather antisocial bunch.

I generally listen to my iPod on my walk to and from work. When I get home, I remove it from my pocket and plug it into the computer to recharge the batteries. Assuming I haven't pushed "pause", why not have the song I was listening to immediately start up in iTunes? I generally want to at least finish listening to the song that was currently playing when I arrived home. But my iPod only talks to my computer to synchronize my music collection. Which is wonderful functionality, but since they're talking to each other already, why not go a little bit further?

Likewise, when I get into my car I often want to listen to my music collection; I have a cd player but choosing and transporting all those little plastic discs is a pain. Since my whole collection is on my iPod, why not provide a car radio that I can slip the device into (Kenneth calls this the "iPod ker-chunk slot") so that bringing my music with me is dead simple?

This is what distinguishes experience design from product design; experience designers consider the interfaces and interactions that appear throughout the whole system the customer is a part of. It's not enough to create products that provide point solutions but don't integrate with the rest of the customer's world; the smart consumer wants his problems solved by his purchases, and these problems span his interaction with any particular device.

The good news is that I think Apple, at least, gets this philosophy. It remains to be seen where they'll go with it, and who will follow.

[ Permanent Location ]

Feline-Centered Design

design, funny

March 15, 2004, 06:37 PM

Tycho from Penny Arcade has a rant up today about the failings of his automatic cat litter box. One of his complaints is that the box doesn't even appear to have been designed to fit a normal-sized house cat. It's interesting to hear a customer's perspective on why it's important to user test your products, even when some of your user population isn't human...

[ Permanent Location ]

Sorting Environments

design, usability

March 14, 2004, 09:28 PM

My friend Jeff Howard was showing me a research project he'd been working on for his miLife project a couple weeks ago, and now he's posted about it. He's basically conducting a card sorting exercise, except the cards contain pictures of various kinds of environments like conferences halls, bus interiors, scenic natural vistas, etc. His team is asking users to arrange the cards along a continuum of which environments they feel more or less mobile in. I believe they're also asking users to arrange the environments along another continuum of how remotely connected to others they feel and how connected they wish to feel. Note that Jeff's online prototype doesn't work as well due to the small size of the cards; the actual physical cards are larger.

It's an interesting spin on the typical card sorting procedure; the pictures may evoke a more emotional response from users which is more appropriate for this particular study than the short words used in navigation hierarchy studies. It also helps give the users more context than a typical interview question such as "name five places you feel mobile in" would, while avoiding the cost of having to find users actually sitting around in all these environments.

[ Permanent Location ]

Nielsen: Qualitative Is Better Than Quantitative

design, psychology

March 11, 2004, 03:44 PM

Jacob Nielsen has posted an alertbox column claiming that qualitative user studies are preferable to quantitative user studies in most circumstances. His reasoning is that quantitative studies, while useful for producing metrics that can guide decision making and resolve design arguments, are too difficult to conduct properly (thus leading to biased results) and tend to produce results that are so narrow as to be useless for guiding design.

My friend "Q" (she posts anonymously, which is why I'm not disclosing her identity) takes issue with Nielsen's proclamation. She tends to favor quantitative research, and points out that it's possible to to botch qualitative results as well, and that a good research program should include both quantitative findings and qualitative observations.

I agree that both kinds of studies need to be done carefully and by people with some training in the area. I also agree that it's good to be flexible and consider many types of studies depending on your research goals. However, I can see Nielsen's point; remember that he is not writing for psychologists or social science researchers, he is writing for practitioners in the design and usability fields. Most of these people do not have significant training in statistics, experiment design, or psychology theory and are unlikely to successfully design a valid quantitative experiment. Moreover, my experience with designing quantitative studies is in line with Nielsen's observations; it took me the better part of last semester to design a study intended to provide evidence that personas helped lend focus to remote design teams in open source software (note I said "provide evidence" not "prove"). And by the end, the study was so narrow in its focus that it wasn't at all clear that it could stand up as bulletproof evidence that remote design teams should always employ personas.

Of course, as Q points out, it's possible to get bad qualitative results as well. But I've found that its fairly easy for relatively untrained individuals to uncover useful design facts about their target user population merely by watching a few members of that population do their work, or by talking to them in an interview, or by giving them some tasks to perform with a prototype interface design. Of course, sometimes you do find users that exhibit outlier behavior, but often, as Nielsen says, it's easy enough to identify such behavior by forming hypotheses beforehand and reasoning about how the behavior you're seeing fits in with your understanding of the world.

Bottom line is, even in enlightened companies a user-centered designer is likely to have only a little time (a few weeks, maybe) to run user studies. To make the most of that time, it's usually best for this practitioner to focus on broad, qualitative, fuzzy data to gain a general picture of the problem, rather than focusing in and losing all that useful information that could be guiding design just to get a few numbers.

[ Permanent Location ]

Newsable Redesign Mockups and a Request for Feedback

design, usability

March 08, 2004, 10:07 PM

I'm working on giving Newsable a facelift soon, both to improve the interaction and visual design. I've posted some mockups of the new key screens; if you're the sort of person who likes to speak words about other people's work, then here's your chance to speak some words about mine. My goals with this release are to make the visual design a little more pleasing and to improve the interaction for people who are subscribed to a large number of feeds. Also, I hope to convince Kenneth that the three-pane format isn't the be all and end all of aggregator design.

I'm also working on the design of a community system that will help facilitate a usable open source software process. The design is based on the research I did last semester in CSCW. If this sounds intriguing to you, stay tuned for more.

[ Permanent Location ]

How to Make an Oldsk00l Text Adventure Game

design

March 06, 2004, 05:12 PM

I came across an interesting article on the history and craft of text adventure games (or "interactive stories" if you want to be high-falutin'). It's fascinating stuff in it's own right, especially if you're interested in game design, but there's also some nifty little nuggets of design wisdom lying about, as there are with any well-written design case studies and instruction pieces. For instance, there's some thoughts on using design research for inspiration, a suggestion to start coding early so as to not get caught up in developing a perfect design and losing all your gumption, and the admonishment to think of the game from the point-of-view of the gamer, rather than that of the designer, if you want your game to really be any fun.

Whoever I got this from, I'm sorry I forgot you. I guess I'm just as bad as the next weblogger at crediting my sources...

[ Permanent Location ]

Making Web Log Analysis Tools Better

design, information, internet

March 05, 2004, 12:22 AM

We're starting our final project in Mapping and Diagramming, which is self-defined. I've decided to focus on designing visualizations of web log data (not to be confused with weblogs, although webloggers are my primary user group), since I've always been of the opinion that the visualizations generated by most current tools tend to suck. So far I've come up with a few sketches and a description of the project.

Some things I want to explore include:

• Better maps of what paths people took through the website (including most frequented paths).
• Information on how long people spent on each page.
• New ways to diagram other important web issues, like page bandwidth consumption, where people come from (referrers), etc.
• Interaction designs for mechanisms to show how these usage trends change over time.

And possibly others as well. I'd like to check out more existing web analysis tools as well as look over some of the relevant research that's been done on the subject, so if anyone has some good pointers, let me know.

Oh, and Dan is doing something wacky with linking together the music people buy, or something.

[ Permanent Location ]

Information Design In Practice: Agnew Moyer Smith

design, information

February 25, 2004, 11:57 PM

Karen, our Mapping and Diagramming teacher, took us on a field trip yesterday to Agnew Moyer Smith, an information design consultancy in Pittsburgh's Southside. Don Moyer, Karen's husband and a partner in the firm, gave us a tour of the facilities and talked to us about a few of his current projects as examples of how he practices information design. Agnew Moyer Smith specializes in making complex technical topics clear and accessible to non-experts, something I'm particularly interested in.

Don spent the most time on a project he'd been working on to develop an information design piece that clearly explains how RFID tags can be used to improve supply chain management. He started out by reviewing an existing piece on supply chain management that AMS had produced for a previous client. This enabled him to set the stage for his own research by working from a similar document whose quality he trusted. He also began to look for sources of information on the domain, investigating a technical paper on RFID, some articles about it in the popular press, and his client's own initial attempts at explaining the process. Don warned against gettting caught up in too much research; he could have probably found hundreds of articles on the subject and although he may have learned a little bit of important information from every one of them, he would have spent days and days going through them all. It's best, he said, to find the book on the topic written for 8-year-olds; that way someone else has already done all the hard work of pulling all the information together and making it understandable. If such a book doesn't exist, however, then you'll have to make do with the most clear and comprehensive sources you can find.

Next, he started collecting together a list of all the nouns (things, actors, etc.) that existed in his problem domain. Then he started listing all the verbs that each of these actors could perform. Interestingly enough, this is the same approach software engineers take when modeling a problem domain for developing an object-oriented software design.

Don prepared a brief of the project for his client to ensure that they were both on the same page as far as the project's requirements went (in theory a brief like this is prepared by the client, but Don says that has never happened in all the years he's been working. The brief, if one exists, is prepared by the designer, just as requirements are developed by software engineers and not handed to them by clients). This brief contained:

1. A short objective for the project.
2. A description of the intended audience of the communication piece.
3. The information that the client wants to know before completing the communication piece.
4. The information the client already knows (or thinks he knows) about the subject.
5. A list of the main messages or "story elements" that the final communication piece must clearly portray.

After getting the client's approval on the brief, Don started developing sketches of the process as well as a notation language for the nouns and verbs he had identified earlier. He then started assembling the spread itself. Don prefers to develop information spreads before powerpoint presentations or other types of information design; he finds that the page works well to force constraints on the design project that ensure clarity and effectiveness of results that might be lacking in a more permissive medium like a presentation or video. This is very much in line with my own rants on the value of constraints.

Once Don reached a solution he was happy with, he moved the project along. Although he would have liked to explore more solution possibilities, he recognizes that making a decision in the development phase early enough to leave room for sufficient refinement is important.

Next, Don wrote the prose for the piece in the form of numbered steps; he believes that it's important for designers to be able to write their own clear, concise copy. He then merged the text with his sketches, and called in a colleague to conduct a critique of his work. His colleage came into the crit cold and played at being a user, pointing out areas where he didn't understand what was being communicated. Don remarked that its common practice in AMS to post designs up in the kitchen or on boards around the space to get comments from the other employees as they wander around the floor.

Finally Don handed off his project to an illustrator to come up with some final iterations. Don described the finished project as "not just a picture, but a story". Thus the need for spending eight weeks on it.

Afterwards, Don showed us around the very impressive AMS space, which completely blows anything at CMU out of the water. The space was very much tailored to the work; projectors were configured to be easily connected to any laptop, bookshelves with design-related books abounded, small workspaces could be reserved by teams so they'd have a permanent location to store work relating to their project. Interestingly, there were no personal private spaces at AMS; everyone had an open desk. Even more interestingly, Don himself had the same setup; his desk didn't really look much different from that of any other employee. No clearly visible hierarchy in this organization. There were also many common areas to encourage conversation and collaboration, although the atmosphere also created enough quiet in the working areas for employees to get things accomplished without interruption. There were closed off conference rooms as well as small booths for private meetings and telephone calls.

Finally, Karen showed us some small booklets that Don produced apparently just for fun about a variety of topics that he wanted to know more about. Don's motives were mixed, however, since he also sent copies of these booklets around to important contacts in the hope that they would bring more work. In many respects, this reminded me of the motivations of open source software contributors.

It was a great experience to see a practicing designer at work. I wish we got more field trips in this graduate school thing.

Dan went along as well; his commentary is also available.

[ Permanent Location ]

Users as Co-designers

design

February 24, 2004, 01:52 AM

Dan reports on a talk given by Liz Sanders on design research and, specifically, generative research, which sounds a lot like participatory design to me. This take on design research views the designer more as a facilitator who works to bring out the creativity and expressiveness of a product's or system's users (or potential users) to generate new ideas for its design. I have discussed this idea in the context of open source software development some in the past.

Needless to say this redefinition of the role of the designer is controversial. Dan gives his personal opinion (a rare thing, for his posts); he is strongly opposed to the idea of involving users in this manner. And radically participatory design is a hard idea to come to terms with; the designer must relinquish a lot of control over the design itself and the design process to embrace it. But let's think a little about where the true problems lie.

First off, the question is not "should users be involved in the design process?". Anyone who professes to practice human-centered design believes they should be; the question is in what capacity. On the low-end, designers keep tight control over the product; they may bring in users for a few interviews during the exploratory research phase or to run user tests during the refinement stage, but never care to ask a user if he has any design ideas. On the high-end, designers pass the buck and ask the users to do the entire design for them; this is the approach Extreme Programming essentially takes. And there's a whole range of ideas that fall in between these two extremes. But what is the right approach to take?

The problem with the high extreme is clear: users are not trained as designers and thus don't have the background in human abilities and limitations, design skills and theories, and plain old experience with what works and what doesn't that is so essential to creating great designs. Moreover, any individual user is caught up in her own way of working; she might be able to design decent solutions for herself, but there may be many other types of users of the product or system in question and she's unlikely to be able to put herself in their shoes (or even know who they are). All these things are truisms in the usability and interaction design fields.

But there's a problem with the low-end as well, and that is that designers don't have a monopoly on good ideas. There are many software designs on the market that were likely created by designers, but which could definitely stand to gain from listening to user feedback (some of Apple's work comes to mind...). I suspect it is not at all uncommon that a user will be working with an application, get frustrated, and come up with a really great idea of how the application could have been designed differently to better support his task. Too bad the designers will never hear of it.

Part of this is due to the universal creativity Liz alludes to, but much of it also comes from the simple fact that users know their work far, far, far better than any designer ever will, no matter how much research he does. This puts the user in a position to have design insights that no non-user could never have. Remember that the essential interaction is between the user and the product or system being designed. The designer is a third party; he may scrutinize this interaction to death, but that's still very different from being a part of it.

In The Cathedral and the Bazaar, Eric Raymond gives programmers advice such as "Treat your users as co-developers" and "The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better." Many minds can come up with more and better ideas than one mind can; open source developers have known this for a long time and social science research supports it. This is one of those areas where human-centered design could stand to learn from open source.

I believe that part of the resistance to participatory design among designers springs from the old notion of "genius"; that there's some magic inspiration that the Great have and the common do not that causes the Great to produce amazing works of art, design, math, programming, etc., etc. You're either born with it or must go through lengthy rituals to obtain it, but if you don't got it, you're screwed.

I don't believe in genius, really. Yes, it is best to have one mind that is ultimately responsible for the final product; nobody likes designs produced by a committee. But one mind is flawed and limited when it works alone. It must be willing to reach out to others in whatever ways are appropriate to overcome these limitations.

But designers need not fret about losing their place in society (a good thing, since I count myself among their number...). There will always be a need for those experts who've been trained in the lore of the profession and who've learned from the trials of producing designs. They must be facilitators, integrators, inquirers, and many other things besides, including creators and idea generators. They are valuable now and their value will only increase as their profession matures and expands. But to do this, they must not shut out avenues of potential growth.

I realize I still haven't answered my own question: what is the right amount of user involvement in the design process? The pat answer is "it depends on the design problem" (bet you've heard that one before). But it's more complex of course; the designer must weigh the value of user input, the difficulty of integrating user ideas and identifying good ones, the availability and willingness of creative users, and so on. But most importantly, the designer must realize when he needs to step back and not be the sole designer; when a user's idea may be more valuable than his own. Genius or not, the truly great creator is marked by his willingness to cede control over his creation in service to bringing it closer to perfection.

[ Permanent Location ]

Ready, Fire, Aim: Parallelizing Design and User Research

design, processes & methodologies, usability

February 18, 2004, 11:48 PM

For our capstone project, we're reaching the point in our process where we agreed to begin thinking about design. As I mentioned earlier, we want to overlap our design and research efforts to avoid getting caught up in wasting lots of time doing up-front research that doesn't turn out to be useful for our design efforts.

Bob calls this approach "Ready, Fire, Aim". The basic idea is to spend some time preparing yourselves by exploring the domain, reviewing literature, talking to domain experts, etc., but then quickly pick a focus and start down a design direction. These early designs may turn out to be totally off-base, but at least they will serve to point out the holes in the team's understanding of the users and suggest fruitful directions for additional research.

I remember a similar concept appearing in programming practice. The Pragmatic Programmers recommend an approach to architecture design they call "tracer bullets". The idea is to attempt to construct a functional end-to-end skeleton system to serve as an initial prototype of the proposed architectural design. Although you may throw this away, you'll learn where the flaws in your understanding of the problem domain lie so that you can design a better architecture and fire your next tracer.

The challenge we'll face, I expect, lies in keeping a clear vision of the team's current understanding of the users and their needs. This is likely to change with the designs as we uncover holes in our knowledge and fill them in. Our plan at the moment is to encode this understanding in our personas and task lists, hopefully using these as living documents as the design process progresses. Perhaps this will be sufficient, perhaps not. It will be interesting to see what this process produces and whether it will be successful.

[ Permanent Location ]

The Art of Being Critical: How to Give Design Critiques

design, processes & methodologies

February 16, 2004, 08:13 PM

One skill that is very important for a designer of any stripe to have, but which I've found is rarely explicitly taught, is how to give and receive effective criticism in a design critique. As a result, I find when someone asks me for feedback on a design I often don't know quite what to say, and when I ask others for feedback sometimes that feedback isn't as helpful as it could be. This can be a big problem, since often this form of feedback is all a designer gets, especially on those many projects that aren't important enough to warrent user testing. So to start to address this problem, I'm outlining some thoughts on what should and should not go into an effective piece of design criticism, whether this criticism is given during a formal crit session or in response to a friend asking "whaddya think of my poster?" over lunch the day before an assignment is due.

First off, it's important to remember to check your ego at the door, to criticise the work and not the person, blah blah blah. We all know that already (even if we don't always live it). What else is there to say?

When offering criticism, I'd first ask "what is my initial reaction to the work?" How does it make me feel? Confident? Playful? Annoyed? Confused? Where does my eye go first? What information is most prominent? What do I think the designer was trying to accomplish with this work? Anyone, even those with no design experience, can give useful feedback along these lines. And sometimes its these first impressions that are most helpful.

Next, make sure you're clear on the designer's goals with respect to the work. Don't guess; ask him. It's easy to suggest changes that aren't appropriate not because they aren't great ideas for some purpose, but because they aren't so hot for the intended purpose. Design is an inherently normative act, and thus it is always performed in service to some set of goals. You might disagree with the author's goals, but then at least you're clear on what it is you need to argue about. Alternatively, the designer might not be clear on what his goals are. This is a problem. Maybe you can help him figure that out before proceeding.

Once you're clear on the goals, you can start to apply that design expertise by comparing and contrasting the design to a set of principles and best practices, as well as an understanding of the needs of the intended audience. It's best to describe both problems and good aspects, so that the designer understands not only what needs to change but also what he must avoid damaging with changes. However, don't fall into the trap of applying principles without proper justification. All principles have reasons behind them, and those reasons don't always apply. I once knew a guy who insisted that "you should never provide help unless the user asks for help". A good principle, probably born out of the Clippy fiasco, but he believed it so religiously that many of his interface designs would fail to provide sufficient feedback for users to evaluate their actions under the theory that it was "providing help the user didn't ask for" (some screens he left entirely blank, with no explanation of their lack of content). Novice designers often apply their shiny new design principles haphazardly, and as a result may do a worse job than they would have were they ignorant.

Try to understand design tradeoffs; make a note of parts that could be improved but also say whether you believe the problems are serious or just small refinements. All design must be signed off on at some point, and its useful for the designer to know whether you think his solution is pretty good as it is or needs much more work.

Finally, don't get upset if the designer challenges your suggestions. He might be too in love with his work to take criticism, yes, but he might also just be trying to better understand your concerns so he can decide how best to improve his work. Give him the benefit of the doubt and assume it's the latter.

When receiving criticism, it's best to be open but inquisitive. Listen to all design suggestions but don't always take them at face value; you may need to probe to get at the reasons for the concern. It can also be good to get a second independent opinion if you're not convinced; see if both your reviewers come up with the same issues independently but if they don't, ask them about it specifically. Try to avoid biasing them one way or the other.

Perhaps after waiting for initial impressions, make sure you've made your goals clear. Your reviewers can't give useful feedback if they don't understand what you're trying to do.

Finally, remember that critiques are analytical analysis methods, not empirical ones. You must judge critique comments, both as a designer and a reviewer, by the quality of their arguments, and to do so you must first understand the argument. Both parties must be able to divorce themselves from the context in order to do so, but it takes a present mind as well as an absent ego to actually affect useful design change. Remember that pushing pixels around on the page doesn't always equal progress.

Good critiques can transform bad designs into excellent ones, but they aren't trivial to run. It's a skill that takes practice, just like anything else.

Scott Berkun, a man who is probably far more qualified to pontificate on this subject than I, wrote an article about how to run a design critique that may be worth checking out as well.

[ Permanent Location ]

Velcro Modeling

design

February 14, 2004, 12:46 PM

In Sketching and Modeling class last Thursday, Bruce Hannington, one of our professors, talked about a technique called velcro modeling.

Velcro modeling is used by industrial designers to construct flexible models of products. The idea is to model the basic form (or perhaps several possible forms) in foam and cover the model with velcro. Next, get a collection of objects that can serve as widgets (buttons, knobs, dials, etc.) and attach velcro to them as well. Now you'll be able to easily reconfigure the product model into a variety of different possible representations.

Designers can use this technique during participatory design sessions to allow sample users to model products in ways that seem intuitive and pleasurable to them. By observing and assisting users in these sessions, designers can get a better sense of how their customers might think about the device and its functionality. Techniques like this one are designed to make it easy for users to get their ideas out into a visual, three-dimensional medium for effective communication to the design team. Since users are rarely expert modelers, such assistance is necessary.

I wonder, however, what a designer is supposed to do when analyzing the results of such a session. Obviously the naive approach of taking the users' designs as the ideal solution won't work. But perhaps designers could look across a wide range of the solutions users came up with for patterns in the placement of widgets, the intents behind the organization of different kinds of functionality, etc., and use these to inform their own ideation and the final product design.

[ Permanent Location ]

Camera Studies

design, processes & methodologies

February 05, 2004, 11:15 PM

Sonia Wendorf, the resident industrial designer on our capstone project team, has introduced us to the concept of "camera studies" and is currently designing one for our own data collection purposes.

A camera study is a user research technique where the research team gives participants in the target user group disposable cameras and asks them to photograph important events, objects, and places they encounter during their day, as well as possibly writing down quick notes describing what they're doing and why they took that particular photograph. Alternately, the researchers may just ask the participants to take one photograph about every hour to collect more time-based data. The researchers then develop the film and review the pictures to gain an understanding of what goes on during an average day in the life of their users. If necessary, they may do an artifact walkthrough with the users after viewing the photographs to gain a more in-depth understanding.

The purpose of the study is to gain a visual understanding of the user's activities and habits during their average day so that the design team can get a sense of their lifestyle. And because the researcher need not actually accompany the users during the data collection process, this technique can glean information from a broader range of users than, say, ethnographic observations can. One could see the results of such an inquiry feeding quite nicely into a set of realistic personas for a project.

The advantage of this approach is that it helps the design team see the world through the participant's eyes rather than just their own; the participant is filtering the information by choosing what to photograph. Furthermore, since the technique allows for running many users in parallel, the design team can get data on many more users which allows for richer data with greater variety. The downside is that the data collected won't be as richly detailed as the data an experienced ethnographer could collect during an extended observation session. So although the technique may be quite helpful for getting an overall impression of a participant's lifestyle, it's less useful for, say, understanding how that participant fits into the larger corporate organization or how the software they use impacts their job performance.

Anyway, it's an interesting technique to add to the toolbox. As an aside, Dan has a post up on a few more from Maya Design.

[ Permanent Location ]

Divvying Up Research

design, usability

February 04, 2004, 11:07 PM

We've started our exploratory user and problem domain research phase for our capstone project. One of the hard things about managing a sizable research project is figuring out how to divide up the labor; research (and design) doesn't lend itself well to task division since all design team members really need to have an understanding of all research conducted so that they can develop appropriate design solutions. Yet if the entire team must be involved in all research activities, then this 1) introduces serious coordination overhead and 2) limits the amount of research the team can conduct since so little can occur in parallel. What to do?

The approach we are taking is to divide up the overall research task into five areas we consider important and assigning leadership of each area to a particular team member. The five areas are:

1. Goals and attitudes of the teachers
2. Goals and attitudes of the students
3. Advantages and limitations of existing competing products
4. Fitting the product into the user's lifestyle
5. Fitting the product into the classroom process

This approach seems to be working reasonably well so far in that every team member seems clear on what his or her responsibilities are and has been able to pick up the task, break it down into action items, and run with it. However, we don't want the group to get too divided; there's a risk that we'll all just go our separate ways without any clear idea of how these subtasks are fitting into the larger goal of understanding the design problem so that we can develop effective solutions. To mitigate this risk, we're going to try overlapping our tasks so that we can all participate in many activities and make a point of reviewing our findings in our meetings.

A second risk during the research phase lies in doing lots of research without knowing what you're getting out of it, then finding at the end that the questions you asked weren't relevant to your design problem whereas there were many questions you needed answers to that you never asked. To avoid research that goes nowhere, we're aiming to ensure that all research activities fit into a set of documents to guide our design:

1. A list of personas from our two target user groups (teachers and students)
2. A set of visionary scenarios describing how our product will be used
3. A list of tasks that the interface must support (the user-centered equivalent of a software engineering functional specification)

We also plan to begin active design ideation after only about three weeks of "pure" research activities. Hopefully, this will help us avoid following research directions that are not actively informing our design.

[ Permanent Location ]

A Map of my Daily Walk

design, information

January 28, 2004, 10:58 PM

For my Mapping and Diagramming class I created a map of my walking route from the front door of my house to Margaret Morrison A11, the room where our class is held. Karen asked us to imagine that an old friend (and not just any friend, a particular friend) had come into town to visit and we needed to leave directions at our house so that they could find their way to CMU to have lunch with us. I chose to design my map for my friends Kim and Alaina.

I'm fairly pleased with the results. The form of my walking route in this schematic line representation is interesting and the elements of the piece fit together rather nicely. I tend to favor a minimalist approach to visual design perhaps because I still have too little confidence in my instincts to add much "decoration". But I think it worked for me with this piece; the simplicity made it easier to focus on attractiveness and understandability.

It struck me that this piece came together fairly easily because the users and their tasks were so focused and narrow. We were designing for one person, and all we had to do was get them from our houses to school. The design solution flowed almost naturally. This leads me to believe that one approach worth trying with more complex problems is to split them up into their component tasks and then design solutions for each task. You can then integrate the "sub-designs" into a larger metaphor that satisfies all tasks, taking into account the relevant tradeoffs and priorities. This has the side benefit of creating easily dividable work for the members of a design team.

[ Permanent Location ]

Ratings and Online Forum Design

design, internet, society & sociology

January 25, 2004, 01:54 PM

Many large online forums such as Slashdot and Kuro5hin support collaborative filtering mechanisms for user-supplied content. The general purpose of these mechanisms is to help make the content people do want to read visible and to hide the content people don't want to read. In both communities mentioned above and many others besides, this takes the form of "moderation", where some users are given the authority to judge whether content supplied by other users is "good". As an aside, Paul Resnick, my former CSCW professor, has a CHI paper coming out on the topic of Slashdot moderation.

Moderation is a feature that tries to deal with many problems at once. The "quality" of a comment or story is subjective and may be based on many factors, and one person's notion of quality may or may not impact another's desire to read the content. Some of these factors may include:

• Spam is generally frowned upon by everyone, and easily identified by everyone. The filtering system need only mark content as "spam or not spam".
• Trolling is harder to detect, and feelings on it are a little more mixed. One person's troll is another person's devil's advocate. Also many people accused of trolling are simply espousing an unpopular opinion, which many forums may wish to actively encourage. So the solution here is less clear; there may need to be more consensus about a comment or story before it gets marked as a troll. And even then the appropriate solution may not be to filter out the content, but merely to mark it as a troll as a warning to other users.
• Information accuracy is theoretically objective but in practice is hard to determine. Truthfulness may be better determined through comments presenting supporting or contradicting evidence than moderation.
• Information interest and relevance may be supported well by moderation, depending on the diversity of the community and how specialized its interests are. A diverse community may have many conflicting opinions among its readership as to what is interesting and relevant, whereas a more specialized community may enjoy more consensus. Community designers need to take into account the type of community they are designing for when judging how (or whether) to address this issue.
• Unpopular opinions can be squelched through collaborative filtering, and again community designers must consider the type of community they wish to create and whether their design goals include encouraging or discouraging heated debate.

The point of all this is not to (necessarily) recommend a more complex moderation system (moderation systems are probably overly complex as it is) but rather to suggest that filtering community content is a complex issue that needs more thought put into it to come up with an appropriate yet simple solution.

The major difficulty with designing collaborative filtering systems is that you must keep the needs of two very different types of users in mind: the reader and the filterer (and possibly the poster of the filtered content as well). The reader wants to see the most interesting content without having to wade through a bunch of crap, but the filterer needs the proper incentives to contribute to the filtering system, and often there is little or no direct benefit to him. How much you can demand from your filterers depends on the type of community; it's worth remembering that the majority of users are social loafers and free riders in any online community (although these terms seem overly harshly judgmental in this context). Its for this reason that I'm always suspicious of collaborative filtering as a panacea; many designers are excited by its potential but, I believe, often ignore the subtle complexities of the design problems it introduces.

[ Permanent Location ]

Of Maps and Diagrams

design, information

January 24, 2004, 11:45 PM

I'm taking a course called "Mapping and Diagramming" this semester from the Design department, taught by Karen Moyer, whom some may remember from my postings on CDF. This time, however, I'm learning about the design of (you guessed it) maps and diagrams, which Karen describes as essentially that subset of information design that deals with high-density information artifacts. I've always found maps and diagrams fascinating in and of themselves, quite apart from any information they convey, so this is a neat course to have the opportunity to take.

So far we've talked a lot about analyzing maps as information objects, and the field is more complex than you may think. Many think of maps as merely representing factual information. The design of a map doesn't seem quite so hard since the information already exists in the world; all the designer must do is record it accurately and in a reasonably aesthetic representation. But nothing could be further from the truth. All maps are selective in the information they represent, whether that information is geographical, political, or something else. Many maps outright lie with respect to certain kinds of information to more accurately or prominently display others (Karen showed us a geodesic dome of the world where all the continents were accurately sized, but the oceans were completely off; the purpose of the map was to allow comparison of the continent sizes while retaining the spherical form of the earth). Some maps may even make a political argument through the information they choose to analyze; Charles Minard's famous map of Napolean's Russian campaign is an example.

The definition of a "map" we're using is also broader than one may think; kayaking eskimos use a piece of wood carved in the shape of the coastline to navigate by. A series of photographs of the intersections of a highway is another example.

The essential goal of a well-designed map is (usually) to present a large amount of information that is intuitively understandable to its audience at a glance. Richard Saul Wurman's book Understanding is a nice collection of year 2000 statistics on the USA presented with this design goal in mind. Information design of this quality should be regularly produced by the government in a healthy democracy rather than relying on the good will of a cabal of famous designers (Wurman and his compatriots lost money on the project).

A final note: Karen mentioned a group of urban planners who had members of the community they were seeking to redesign draw maps of the areas in which they lived to find out what places were most important, dangerous, etc. to the inhabitants. An interesting user-research technique.

[ Permanent Location ]

The Case of Powerpoint

design, information

January 06, 2004, 12:02 AM

Kevin has a nice summary of several of the Powerpoint-is-bad memes that are out there on the internet. Going over these again got me thinking about how one cause of this problem might not be any particular design flaw of Powerpoint's, but rather an extension of the tool into areas it was never meant to enter. Powerpoint is reasonably good at putting together visual aids for lectures and talks, and as long as it's kept to that purpose it tends to shine (Neema, who is an ardent defender of Powerpoint, proved this with his excellent presentation, "A Spiritual Journey", on his 9-month adventure across Europe/Asia/Africa). The problem arises when people use Powerpoint as their sole venue for information presentation. As Tufte points out, the slideshow format is inappropriate for many communication purposes.

However, there are many who use Powerpoint not only as a means of presenting visuals for a talk, but also as a way of publishing take-away materials for the audience and even for storing databases of information so that it can be quickly pulled together into a presentation format. On the one hand, this is a perfectly reasonable strategy for busy people who don't have the time to maintain their information in a more appropriate tool, then convert all the relevant bits into Powerpoint slides. On the other, this leads to all the problems Tufte rails against for the reasons he defends far more eloquently than I can hope to do here.

Perhaps the answer lies in developing tools that support more robust single-sourcing techniques, both for authoring and publication. Such tools should not only make it easy to store content generically and squish it into a variety of presentation templates, but should afford using the appropriate templates for each information presentation purpose. But who will provide us with a vision of what such a tool might look like? It'd be an interesting challenge to take on.

[ Permanent Location ]

A Note on Terminology

design, language, usability

December 26, 2003, 12:31 AM

As I was writing my post yesterday, I wanted to add a note on my usage of a few key terms here on this weblog, to clarify any possible confusions that might arise.

When I use the term design in reference to software systems, I am sometimes referring to interface design, i.e. the form and function of the portion of the software system that the user of the product sees and interacts with, and sometimes referring to internal design, the structure and specifications of the logical components that power the behavior of this interface. Although I recognize that this is generally a useful distinction to make, I tend to view these two disciplines as different aspects of the same activity. There is no question that the two influence one another. Because these two concepts are blurred in my mind, the word I use for them is fairly blurry as well. For the most part this is intentional.

Secondly, I tend to use the term usability rather more broadly than others do (or so I've found). It's convention in the field to make a distinction between "useful, usable, and desirable" as quality characteristics of software systems (and many other systems, as well). Useful refers to whether the software does what the user needs it to, usable refers to whether he can learn and remember how to use the software, and use it efficiently, and desirable refers to whether he wants to use the software. I often find this distinction silly, since there's so much overlap between these three concepts, and thus I tend to lump them all under the moniker "usable", i.e., to what extent can people use it? I've already argued that all software quality attributes reduce to usability. Now I feel like I need to argue that all usability attributes reduce to usability (which strikes me as a bit silly).

Finally, I have no good word to refer to the group of people who are members of the broad profession that aims to design products and systems for use by human beings. The general term for this discipline is often "human (or user) centered design" but the term "human-centered designer" often isn't seen as applying to user researchers, UI programmers, etc. who aren't necessarily designing an interface. But no other word will do. "Usability person" tends to get rejected by the designers. There are a plethora of more specific terms (interaction designer, information architect, interaction architect, UI designer, interface designer, user researcher, usability specialist, "gooey" (from Yahoo), user tester, usability engineer, usability professional, or generate your own) My friend Dana made up the word "usable" but nobody seems too fond of that either. So I might use any sufficiently general-sounding term to refer to the whole lot of them, until one emerges that everyone can agree on.

I don't believe that any of these issues are idiosyncratic to me, but rather reveal some inherent ambiguities in the way we talk about these things. However, this post should be taken as more of a clarification than a complaint. Ambiguity in terminology is confusing, but inevitable. Human language is riddled with ambiguity, which is part of what makes it such a beautiful and powerful thing. Some of the ambiguities I've pointed out above are (in my view) necessary, and I have faith that the others will sort themselves out in time.

[ Permanent Location ]

A Systemic Problem with Software

design, software development, systems

December 24, 2003, 11:33 AM

One of the core themes you'll find running through this weblog is an approach to analyzing problems from a systemic perspective, that is, an approach that examines the structure of the larger systems these problems exist to gain a deeper understanding of their causes. Recently I've been thinking about systemic problems in software design, and I wanted to articulate the one that's especially jumped out at me.

First off, lets assume a world in which all our dreams have come true. Human-centered design is the norm rather than the exception. Efficient production and distribution models have arisen for software design and development, and the market is perfectly in tune with the needs of its end-users. Sadly, the following problem would still plague us.

Here's the crux of it:

1. Designing good software requires maintaining a strong focus on a small, well-defined user group. Cooper makes this argument, and it's pretty well-known to anyone who has done serious interface design work. Different people have different needs, and any interface that tries to be too general, that tries to do everything for everybody, will only wind up being mediocre (at best) for many, and completely unusable for the rest. Feature creep and the complex, inelegant interaction designs that inherently accompany it will see to that. This is partially why Word and Windows suffer from so many usability problems; they are trying to satisfy too many disparate user groups.
2. But people need to work together, so their software must work together too. Users need to exchange documents, send each other messages, work collaboratively on the same artifacts, etc. If they software they use doesn't support this, it cannot fulfill their goals.
3. If people have different software, this creates an interoperability problem. Different software systems, especially those made by different companies, are notorious for causing problems with interoperability, from the old issues with opening Wordperfect documents in Word to modern problems with viewing web pages in Safari that were created for Internet Explorer.
4. There will always be tension between focused design for usability and generalized design for interoperability. Often, the result of this situation is that natural monopolies get created in the software market, such as Microsoft. One company produces a "one size fits all" solution that everyone uses to avoid the problems with interoperability, but which fails to fully satisfy anyone's needs.

So what can be done about these problems? One option is to explicitly design software to interoperate with other software, which I've discussed before. But it's hard to design two pieces of software so that they communicate together effectively, even when you have full control over both of them. And designing for connectivity with all the software your customers might potentially be using quickly creates an exponential complexity problem.

The obvious solution is to define software standards and design to conform to them. However, we know that usability is not screen-deep, so these standards may put limits on the usability of the final products. Ideally, the standards should be developed while following a user-centered design process as well, but here we come back to our original problem; standards by definition must take the needs of many user groups into account, which is inherently difficult to design for. What usually happens is that standards arise from the experience of many product development efforts, and attempts at standardization that occur too early fail as vendors ignore them in favor of adding proprietary capabilities to their software to fulfill their customer's needs.

I don't see any obvious way out of this messy process, dictated by the structure of software design and development. My guess is that firms must do the best they can in the particular situations they find themselves in, and work to enhance the standardization process so that less time is wasted discarding inappropriate standards.

[ Permanent Location ]

A Usable Open Source Software Community

design, society & sociology, software development, usability

December 18, 2003, 10:42 PM

I've written a lot before on the subject of bringing usability to open source software. I've been silent on the topic recently, but not idle; I've been working diligently all semester long with my friend Dana Gelman for our CSCW course on a project to design an open source community that has the tools, techniques, and participants to develop products that can effectively target end-users.

Our core recommendation is that existing open source communities that develop applications targeting end-users (for our purposes, "end-users" will be shorthand for "users that are not like the developers") should invite usability professionals and interaction designers to participate in the development efforts. This is harder than it sounds, however, since existing, developer-centric communities will have to change the way they work to make room for these new people with new skills. To begin to paint a picture of what this new, integrated community might look like, we have developed eight specific recommendations for any OSS community that targets end-users.

1. Involve usables in the core development team. Our literature search has shown that most OSS projects have a small team of one or more developers that do the bulk of the work. On large projects, this team is responsible for decisions relating to the high-level architecture and organization of the code. We propose bringing interface designers into this team to take responsibility for the user experience, including defining and maintaining the core metaphors, ensuring interface consistency, and other high-level duties. These participants will also need to interact closely with the core developers to determine implementation tradeoffs, which is why they're part of the same core team.
2. Incorporate personas. I've already argued extensively for this recommendation, so I won't say much more of it here, except to note that to be effective, the personas must be used and valued (in particular, they should be frequently referenced by name) in design conversations throughout the community.
3. Build small, heterogeneous teams of developers and usability people. Small teams are more productive, and can focus on the details of an interface design with a minimum of overhead.
4. Modify the joiner script to require newcomers to justify design decisions with the personas. Open source communities have an implicit cultural barrier to entry called the "joiner script" that sets a standard that new members must live up to in order to become contributors to the project (think of it as a very long interview process). We recommend not admitting contributors (both developers and usability people) who are unwilling to justify design changes and feature requests in terms of the personas' needs.
5. Use synchronous communication (chat) for design meetings. Synchronous communication is more efficient at building shared understanding, which is essential for making effective design decisions.
6. Transmit design decisions back to the public list. The previous recommendation introduces a problem, however. People who are outside the immediate circle of the design team (contributors working on other parts of the project, contributor hopefuls, users, etc) also need to be kept in the loop about the design decisions that are made and the rational for them. For this reason, someone needs to be willing to summarize the synchronous design conversation and post it to the asynchronous communication medium in use by the project (e.g., a mailing list or discussion board) so these other followers can get access to it.
7. Provide a shared visual information space. We recommend using a shared, visual information space (like a shared whiteboard application) in parallel with synchronous chat for design meetings. Design is a very visual process, so having the easily accessible graphical space to work on rather than trying to describe all interface changes linguistically is necessary.
8. Modify bug tracking tools to better support collecting usability issues. Bug tracking tools are often used to record change requests as well as bugs in open source projects. On large projects, however, we found that they often break down as large numbers of UI problems pile in and contributors must spend time sorting through them. We propose developing more efficient bug tracking tools that are capable of handling UI issues as well as code bugs. We have not yet defined the form such a system must take, since this is really another semester project in and of itself.

Dana and I have put together a final report that contains more comprehensive descriptions and extensive arguments for these changes, ties our assertions back to the literature, and describes an experiment we are proposing to test one aspect of our solution (how personas change the design conversation in an integrated open source and usability community). I haven't made this paper publicly available (yet) since we're hoping to publish portions of it at CHI or CSCW and I don't want to run afoul of prior publication rules. But if you're really interested, drop me an email and I might send you a copy.

[ Permanent Location ]

On Ideas and a Community of Ideas

design, society & sociology

December 16, 2003, 10:49 AM

I've been busy with the end of the semester recently, which is why I haven't been posting much. This, of course, means I've generated a huge backlog of things to say. Now that classes are behind me, I'm going to try to get some of them out in the open, so if the next few days seem rather verbosely scattered, that's why.

Let's start relatively concrete. I was talking to Matt a few days back about ideas and the ways we come up with them, and the relative value of coming up with ideas versus putting in the time and energy to actually execute them. We agreed that most of the real work and the real value is in the execution of ideas; if one person comes up with an idea but another puts in the required work to see it brought to fruition, then the second person is the one with the stronger claim (a fact that is recognized by copyright law). But ideas are funny things; sometimes good ones will hit you out of the blue with amazing ease, but frequently if you try to sit down and deliberately come up with one it won't be there when you need it. Ideation is easy to do but really hard to focus and control, and a good idea that comes at the wrong time or in the wrong place is next to useless.

My theory on coming up with ideas is that getting the right idea is a matter of having the right kind of brain with the right kind of information in it, which enables you to make the appropriate neural connection to get the idea you want (I further believe that ideas don't come out of nowhere; they are composite thoughts that arise from mushing together apparently disconnected facts, values, and beliefs). The long and the short of this is that having the "right" idea is a matter of having the right person with the right knowledge at the right time.

We designers can up our chances of being that person through extensive domain research and brainstorming techniques, but we cannot ever step into another person's head, and sometimes that's what's needed to get at the right idea. But if we can't do it, who can?

The user community, of course. But often user ideas are never heard by designers, since there are no effective feedback channels from the end-users to those who develop their products. What we need is a forum for collecting such ideas and encouraging the best ones to rise to the surface. For this purpose, I propose an online community built to leverage this broad swath of brains who could possibly make these connections.

There are many barriers, however. How would the community designer encourage contribution of ideas? And once users are contributing, how would the community evaluate the ideas to know which are suitable for recommendation to the designers (who should, of course, exercise their own judgment in deciding how and whether to apply them)? It seems a fertile ground for exploration. The only community I know of that's attempted it was the Dilbert Lazy Inventor site (which is off the web now I think), and that struck me as more of a toy than a serious site.

Although I haven't emphasized it before, this idea strikes me as very much in line with my thoughts on increasing end-user participation in open source software development. It's nice to find those rare occasions when all your interests converge.

[ Permanent Location ]

Echo: The Emotional IM Companion

design, personal

December 12, 2003, 03:18 PM

For my fourth and final project for VIID, I worked with Dan Saffer and Jeff Howard on a system to enhance emotional communication over instant messaging (IM) and potentially other text-based mediums. Our target audience was teenagers, since they tend to be technically sophisticated early adopters, and we were interested in developing a novel interaction design. Our solution is a small avatar that sits on top of your computer monitor. The avatar has a camera inside it and monitors your emotional state through your gestures, your facial expressions, and the text you send via IM, then reports that mood back to you as well as to designated friends. We call it "Echo" because it echoes your emotional state back at you. Check out our final presentation for a summary of our research and a scenario of use. Then play around with a demo of Echo's emotional states. And for the truly curious, some specification sheets succinctly describing Echo's properties are available as well as our presentation of initial research and ideation.

During the first phase, we did some user research and developed the following design goals:

1. Enhance emotional communication through compelling, fun interactions
2. Use lightweight, natural interactions
3. Support privacy
4. Don’t interfere with the benefits of the chat medium

With these in mind, we went about trying to develop a concept for Echo. We struggled a lot during ideation for this project; surprisingly, we found that teens are actually pretty good at communicating emotions over the impoverished chat medium and most of the ideas we came up with failed to meet one of our design goals in some way or another. We developed the Echo concept after Ian suggested an onscreen tamagotchi that would somehow communicate your emotional state.

If I had more time to refine Echo, I'd probably focus more on discovering what emotions our users want to communicate, and to what extent these emotions can be "guessed" at by technology. There's a delicate balance in this design between producing a system that requires too much user interaction and thus becomes a bother versus producing a system that guesses too much and therefore risks getting the user's emotions wrong and possibly communicating information the users don't want to disclose. Echo is a novel and compelling design, but also a fairly risky one, which is an interesting observation to ponder.

Thanks to Jeff and Dan for working on the project with me. They're both creative guys and clear thinkers, which lead to interesting and stimulating design meetings and brainstorming sessions.

This concludes my series of IID projects (starting with my scheduling snake, continuing with the Keep in Touch app, the followed by the social robotic walker). I may have more reflections to post later, but this particular foray into new territory has officially come to completion.

[ Permanent Location ]

Communicating Interaction

design, writing & communication

December 10, 2003, 11:10 PM

We just completed the last leg of VIID right now, having worked late into the night finishing up our last assignment (on which more will be forthcoming soon). As part of my final reflections on the class, I'd like to talk a little bit about ways to communicate interaction designs, which has been a major component of the class that we haven't talked enough about.

One of the most important (arguably the most important) parts of an interaction designer's job involves clearly and unambiguously communicating her design solutions. She must communicate to a variety of different audiences for a variety of different reasons, including:

• Other designers for getting helpful feedback in a critique. If she can't communicate clearly to her peers, then their suggestions may be muddled or inappropriate and she'll lose the many benefits of having more eyes scrutinizing her design.
• Decision makers (usually managers) for getting buy-in and go ahead with ideas. Decision makers generally want to understand the design solution she's offering before committing resources to refining, testing, or implementing it.
• Engineers for communicating what must be built. The engineers also need enough knowledge of the design rational to make micro-decisions relating to changes in the design based on development constraints.
• End users for user tests and feedback. The designer must communicate the experience well enough to collect useful data from test users, as well as to accurately gauge their reactions to the product.

The simplest way to communicate a design, and the one novice designers usually favor, is describing the attributes of the design in prose, either through talking or writing about the interactions as a flat list of features. Generally speaking, however, this isn't effective. Experience and interaction designs are inherently nonlinguistic in nature, and thus all parties need to translate back and forth between their understanding of the experience and the words they use to describe it. Even the best rhetoricians would have great difficultly expressing a nontrivial design with sufficient clarity and precision for all these purposes using words alone. So novice designers may try adding other media, such as pictures, videos, and possibly partially functional prototypes. They're on the right track, but an effective design communication can't just be a mishmash of disconnected design fragments. The designer must invest careful thought and effort into deciding the most appropriate way to communicate each piece so that they come together as a whole.

To fully understand an experience design, people must, well, experience the design. This experience needs to be as close to the final, designed experience as possible to ensure no ambiguities creep in. Keep in mind that people are very good at filling in missing details, but that they may not fill in those details in the same way the designer is. Thus, each unspecified detail is a potential point of confusion, a potential branch where the designer and the experiencer may be envisioning completely different designs. So ideally, the design should be communicated with a high-fidelity functional prototype that approximates the final, envisioned interaction experience as closely as possible.

Of course, building high-fidelity functional prototypes is very time consuming and designers need to communicate very frequently, so there's often no time to build such an artifact. What's a designer to do?

She could produce a prototype, but sacrifice the fidelity in various ways in order to make construction more feasible. When stripping away fidelity, however, she must carefully consider what communication she's losing, and whether these are critical to her communication goals. For example, a series of screen mockups done in Photoshop or another graphics tool may succeed in giving a good sense of the visual layout of the interface, but give little to no sense of how the experience of interacting with it will feel. Likewise, hand-constructed paper model prototypes may give a rough sense of the interaction but may not communicate the visual experience. Sometimes, the designer may wish to intentionally not communicate aspects of the design; if she wants to present a rough design idea and receive feedback on the concept and general structure, she may choose to use wireframes or sketches rather than full interface designs to prevent her audience from focusing on aspects of the design like color and typography which must be present, but may not be the current focus of concern.

If producing a prototype of the appropriate fidelity is not feasible, then our designer has an alternative. She may choose to develop a scenario of use (or possibly several) that depicts a typical user (perhaps one of her personas, if she's defined any) interacting with the product. This may be as simple as textual descriptions of the actions combined with the relevant screen sequences or as complex as a product demonstration movie that appears to depict an actor really using the product. Scenarios are the next best thing to experiencing the interaction design directly through prototypes; they don't let the audience really feel the experience themselves but they do allow them to observe someone else's experience. This approach may appear to be no different to the "naive" ones mentioned earlier, but in fact it is generally much more effective than a list of features or a description of disconnected interactions. Scenarios leverage the power of storytelling to effectively communicate designed experiences.

Of course, all of this advice needs to be mediated with a healthy understanding of the designer's audience and their goals. Communications will need to be tailored to the needs of the receivers; engineering will probably want to see detailed product specifications, whereas management will be more interested in projected revenues and cost justifications, for example. But the techniques in this entry can serve as general best practices to build upon for communicating any interaction design to anyone.

[ Permanent Location ]

Augmented Reality Graffiti

design, society & sociology

December 03, 2003, 11:23 AM

Cary sent me a link to a website complaining about the iPod's allegedly short-lived battery life. Here's to hoping my iPod holds out longer; no matter how great the design is, I can't afford to buy a 300$ music player every year and a half.

The section of the video where the creator is spraypainting the apple advertisements with the message "iPod's Unreplaceable Battery Lasts Only 18 Months" got me thinking about technological measures for adding greater public deliberation to advertising, specifically using augmented reality (AR). Augmented reality is an interface genre that involves creating technology that can recognize something about the state of the world and then overlay some additional information on top of the user's experience of the world. For example, a (conceptually) simple example would be a pair of glasses with a small embedded camera that can recognize the faces of people you're talking to, look them up in a database, then display their full names underneath their face (or so it appears; the glasses would project the name directly into your eyes), which would greatly help out those of us who are bad at remembering names of people we don't know very well.

Now take this thought, and imagine a system where viewers of an advertisement could append commentary about the product or the company to the physical poster, television spot, or whatever that would then be available to all other viewers of the advertisement as a sort of "virtual graffiti". This gives us the benefits of the website author's approach to commentary without actually being illegal or even ethically questionable (although it also might lack the thrill of committing minor civil disobedience).

This approach is already taken by some websites, which have the advantage of not needing augmented reality since they exist in an entirely virtual space. Kuro5hin, for example, allows users to append comments to the text advertisements on the site to foster discussion about the product or service or company being advertised (although the advertiser has the ability to disable this feature). One problem with such systems which hasn't really been solved even in virtual spaces is how to empower readers to filter through a potentially large volume or comments, many of them useless, and how to get an at-a-glance "big picture" of all this commentary. In other systems, the problem may be encouraging contribution, since people may be less willing to take the time to contribute their recommendations or complaints if their feelings aren't strong or their readership is small.

I also confess to having no clear idea how far off in the future such an augmented reality system is. We had an interesting talk at the SSS on augmented reality given by a couple of guys from the ETC who were investigating the possibilities for AR in games. But I did get the impression that most of the technology was pretty nascent. Still, now is a great time for designers to start investigating the potential interactions afforded by AR so we'll be ready for it when it comes.

[ Permanent Location ]

The Design of a New Machine

design

November 30, 2003, 04:46 PM

There's an article in the New York Times titled "The Guts of a New Machine" that discusses the rise of the iPod and Apple's approach to design innovation with the product. The author takes the position that the iPod has been winning in the digital music player market largely because of a close attention to sound user experience design. Some highlights:

Steve Jobs discusses the difference between visual design and interaction design:

It is, in short, an icon. A handful of familiar cliches have made the rounds to explain this -- it's about ease of use, it's about Apple's great sense of design. But what does that really mean? ''Most people make the mistake of thinking design is what it looks like,'' says Steve Jobs, Apple's C.E.O. ''People think it's this veneer -- that the designers are handed this box and told, 'Make it look good!' That's not what we think design is. It's not just what it looks like and feels like. Design is how it works.''

Jonathan Ive, Apple's VP of Industrial Design, emphasizes the importance of design process and downplays "magic moment" innovations:

When it came to pinning Ive down on questions of how specific aspects of the product came to be, he stressed not epiphanies but process. Asked about the scroll wheel, he did not mention the Bang & Olufsen BeoCom phones that use a similar radial dial; rather, he talked about the way that his design group collaborates constantly with engineers and manufacturers. ''It's not serial,'' he insisted. ''It's not one person passing something on to the next.''

The author discusses innovation in the marketplace, pointing out that often the companies that innovate get punished when the "followers" come along and refine their ideas into something a little bit better or cheaper, but not more innovative:

You can think of innovation as a continuum, and this phase is one end of it. The dreams and experiments that happen outside of -- and in a state of indifference toward -- the marketplace. At the other end of the continuum are the fast followers, those who are very attuned to the marketplace, but are not particularly innovative. They let someone else do the risky business of wild leaps, then swoop in behind with an offering that funnels some aspect of the innovation into a more marketable (cheaper? watered down? easier to obtain?) package -- and dominates.

Steve Jobs stresses the iPod's focus on user experience design:

As he described it, the iPod did not begin with a specific technological breakthrough, but with a sense, in early 2001, that Apple could give this market something better than any rival could. So the starting point wasn't a chip or a design; the starting point was the question, What's the user experience?

Of course, all of this is moot if you believe, as many cynics do, that the iPod is largely the result of a successful marketing campaign rather than sound product design. If so, we'll see what the future holds; many other companies have talented, well-funded marketing departments. But I rather doubt that will be Apple's downfall (if anything is); I predict the iPod will only lose out if another company manages to effectively clone it, which will only expand it's impact and influence (although this may be small comfort to Jobs and Apple).

Developing questions on whether our free market adequately encourages innovation are left as an exercise for the reader (for now, at least).

[ Permanent Location ]

A Naked User Interface

design, software development

November 27, 2003, 01:40 PM

Dave Thomas, one of the Pragmatic Programmers, has an interesting ramble on his weblog that covers a variety of topics of interest to user-centered designers. His analysis of Raymond's discussion of X windows and its lack of imposition of a standard look-and-feel versus the Windows / Mac approach of imposing lots of constraints and standards on interface design is quite interesting in its own right. I'll leave it as an excercise for the reader to reflect on whether the X windows framework is truly independent of human factors and interface design, as Raymond claims (given my writings on the impact of software architecture on usability, you might be able to guess where my feelings lie...).

What I want to focus on, however, is Dave's discussion at the end of "Naked Objects". Naked Objects are a pattern for structuring a software application that has huge implications for interface design but which hasn't gotten much press in the interface design community. As some of you may already know, most software code is structured in terms of objects, software modules that aggregate data structures and the procedures that operate on those data structures. Some of these objects appear directly in the domain the software is being developed to support; for example, a web storefront system will probably include objects like "Product", "Customer", and "Order". Other objects are more esoteric and relate more to technical implementation considerations than the domain itself, but for our purposes we can ignore these and concentrate on the "domain objects".

In a Naked Objects system, the "user interface" of the application as it is commonly conceived is stripped away; instead the system provides a minimal UI that allows users to create, destroy, and manipulate domain objects directly. Now I know many of you are thinking this sounds crazy, but there are a few advantages:

• Exposing the object model to the users ensures a match between the development team's metaphors and the users' metaphors, which provides a shared language for both stakeholders. I've advocated this in the context of XP, but it's important regardless of the development methodology. This has the additional benefit of allowing for user feedback on the domain model as well as on the interface design; most interfaces hide away the domain model which prevents users from commenting on it except in the context of abstract engineering diagrams.
• In a way, Naked Objects is the ultimate minimalist user interface. The designer provides only the bare essentials, fleshing out the tasks is left up to the users themselves.
• Since the user experience design is intimately tied to the internal software design, this approach ensures close collaboration between the interface designers and the software developers, something that doesn't happen often enough in practice.
• Naked Objects eliminates lots of user interface code, which leads to lower cost (less code must be developed, requiring less expensive developer time) and higher reliability and maintainability (less code is easier to test and modify).
• Naked Objects potentially allow for much greater user control over the system than conventional interfaces. In a Naked Objects system, the user defines the ways the objects work together to accomplish her tasks; the tasks aren't "pre-canned" for her by the interface designer. This also allows her to work in ways that the designers did not forsee or intend. Note that this is the basic problem confronted by designers of interfaces that support creativity.
• This level of user control transforms the user from a follower of a proscribed process into a solver of problems. This is the difference between mechanism and policy that Dave's post focuses on. In some domains, this may lead to greater user satisfaction since people prefer to actively solve problems rather than mechanically follow algorithmic task flows.
• It's potentially easy to create both a Naked Objects and a conventional interface for the same application, to provide more power for experts while still giving guidance to novices. Dave mentions the difference between the Mac Aqua interface and Darwin's command line shell as a similar approach.

One might wonder if a Naked Objects system really requires an interface designer, since it appears to have so little "interface" to design. I'd guess that it would, however, both to ensure that the interactions used to create and connect objects are simple and intuitive and to ensure that the naming and behavior of the objects themselves are appropriate. So given that designers are necessary, what techniques would they use to design such systems? And what systems might a Naked Objects approach be appropriate for? My guess is that experts would benefit more than novices, since Naked Objects gives very little task guidance and assumes a great deal of familiarity with the domain. As I mentioned above, perhaps interfaces that support creative tasks are a good candidate. In a way, the direct manipulation paradigm found in Photoshop and other graphics packages is a similar approach.

I'd encourage designers to seriously consider these questions, for I think this approach is interesting and may be more applicable than it initially appears. It also shows that sometimes interesting interface ideas come out of the software development community as well as the usability / interaction design community.

[ Permanent Location ]

Zen and the Art of Interface Design

design

November 23, 2003, 12:37 AM

I've recently been reading "Zen and the Art of Motorcycle Maintenance", a fascinating, deeply insightful novel that delves into such philosophical areas as the nature of thought, reason and emotion, the role of technology, and the definition of quality. Midway through the book, the narrator is discussing a set of assembly instructions that begin with "Assembly of Japanese bicycle require great peace of mind".

Peace of mind isn't at all superficial, really," I expound. "It's the whole thing.... What we call workability of the machine is just an objectification of this peace of mind. The ultimate test's always your own serenity. If you don't have this when you start and maintain it while you're working, you're likely to build your personal problems right into the machine itself.... The test of the machine is the satisfaction it gives you. There isn't any other test. If the machine produces tranquillity it's right. If it disturbs you it's wrong until either the machine or your mind is changed. The test of the machine's always your own mind. There isn't any other test.

If that doesn't speak to the aims of human-centered design, then I don't know what does.

[ Permanent Location ]

Competing Definitions of Design

design, language, philosophy

November 18, 2003, 07:54 PM

Dan has a post up about Dick Buchanan's definition of design:

"Design is the human power to conceive, plan, and realize products that serve human beings in the accomplishment of any individual or collective purpose."

Just for fun, let's compare and contrast this with my own stab at defining design:

"a deliberate action prompted by an understanding of the state of the world intended to transform the world into an improved state."

First off, Dick's definition explicitly mentions humans, whereas mine leaves the actors undefined. I think for all practical intents and purposes this is an unimportant distinction.

Secondly, Dick's incorporates a three-stage process into the definition; to design you must "conceive, plan, and realize". Mine doesn't discuss any of the activities that make up design. Perhaps it should.

Next, his specifically mentions products as the output of design. I prefer leaving this undefined, for some design processes have as their output a refined policy or organizational structure, or perhaps a new process for performing some task. These things aren't products unless you define "product" much more broadly than most people do.

Next, my definition calls out "understanding the world" as an essential component of design, whereas Dick's does not. Perhaps this is too prescriptive, since lots of design gets done without any formal attempt to understand the context in which it must fit. I'd argue that designers still require some (possibly incorrect) understanding to move forward with, which often may be based solely on their own assumptions.

Finally, my definition specifies that design attempts to improve the world (in the mind of the designers, anyway), whereas Dick's gives as the aim of design "accomplishment of any individual or collective purpose".

Dick is certainly correct that definitions cannot provide closure on all the important philosophical issues in the field. But it's still interesting to hear what words people choose to define the terms they use everyday. It often unveils subtle, but important, differences in people's understanding of the meaning behind those terms.

[ Permanent Location ]

Flexible Designs and the Role of the Designer

design, usability

November 18, 2003, 11:58 AM

My good friend Kerry has a post up on an art exhibit on rethinking the role of design in everyday life. The exhibit includes a project called Felt 12x12, which is essentially a collection of felt squares that the consumer can combine to be anything he wants. This got me thinking about the roles of the consumer and the designer and how much influence each should have over the product.

When designing a piece of technology, especially software technology, one thing you have to decide is the extent to which the end user should be able to configure the product. If you make the product completely rigid and allow for no reconfiguration, then you risk alienating the vast majority of your users who have special needs, plus you lose one of the main advantages of digital computers, their flexibility. On the other hand, if you make the product too configurable, you'll wind up with a jumbled mass of options that are hard to use and hard to maintain (from a programmer's perspective), most of which are rarely needed by the majority of your user base.

I've discussed the problem of designing for end-user customization before, in the context of open source interfaces. As I mentioned then, the HCI and Interaction Design literature tends to emphasize that it is the designer's job to make decisions about the form and function of the product; she should do all the work so that the user doesn't have to think. But the literature tends to approach this from a very narrow perspective; the study from Nielsen only looked into the effects of allowing users to reconfigure the interface's appearance on their time to complete a task. There are many other potential benefits of allowing some user customization, such as improving user satisfaction and supporting tasks the interface wasn't designed for. How much of this truism is the way things must be, and how much of it is self-interest on the part of designers?

What is the role of the designer in society? Is she always tasked with constructing fully-formed user experiences and "canned" design solutions, or must she often instead work to produce "a framework, within which consumers can define shape and form for themselves"? When constructing such a framework, the user's tasks by definition are poorly defined, similar to the problems confronted in designing interfaces to support creativity. Most of our methods rely on these tasks being well defined. Will our methods help us rise to this challenge, or must we develop new methods that better support configurability?

[ Permanent Location ]

Discussing Disconnects

design, processes & methodologies, software development, usability

November 15, 2003, 07:08 PM

At the SSS two days ago, I led a discussion on how we can bridge the gap between interaction designers, usability professionals, and software engineers working together on real-world development teams (as I promised I would). I started out with a quick presentation describing the personalities and goals of both "players" (designers and developers) through some rough personas, then opened the session up for discussion on what techniques might help in getting these two players to work together effectively.

Here's a list of the possibilities that were thrown out for consideration. If anyone out there in readerland was at the discussion and notices something I missed, please do add it in a comment.

1. Emphasize more up-front design so design and engineering need not work in parallel. The idea is that this will reduce the amount that the two players need to communicate, thus reducing conflicts and making the process more efficient. It was also pointed out, however, that although spending time on up-front design is good, it doesn't solve all the problems. The final design, no matter how good, will still need to change quite a bit based on engineering's input and concerns, thus reintroducing the communication problem.
2. Design must bring engineering onboard. Those who came from an engineering background emphasized the need for design to justify and "sell" their design solutions to the engineering team. The idea is that although engineering trusts design to be good at their job, they will be more effective participants in the overall development process if they understand what the important usability issues are and why the related design decisions were made.
3. Design and development must "live" together. Basically, the two players should work closely throughout the entire process; there should be no "throw it over the wall" style information exchanges. I've suggested this before in the context of XP, going so far as to recommend that the two players work together in the same room.
4. Designers should contribute to development work. Many designers have enough technical abilities to contribute to parts of the user interface development process. In addition to speeding things along, this gives engineering a better sense that the designers are true members of the team. Cooper and Reimann suggest that one individual cannot fill the role of a designer and developer, due to the fundamentally different mindsets, but everyone in the group thought it was possible to strike a happy medium. In order to facilitate this technique, the software architecture must separate the user interface modules from the rest of the application using a separation pattern such as Model-View-Controller (which still won't handle all concerns, of course).
5. Designers should have engineers sit in on user tests. Watching users struggle with bad designs is often cited as a good way to motivate people who aren't willing to buy in to user-centered design. If this is the situation designers face, this is a technique they can try to bring engineers on board. Randy Pausch, ever famous for mistreating his engineering team, requires them to sit on their hands while watching people use their interface, and demands they keep silent unless they are willing to precede their comments with an apology for designing such a horrible interface. This might be a bit extremist for most industry teams to swallow, however...
6. Both players need case studies on how to effectively work together and how not to ineffectively work together. Design and engineering (and management) can learn from examples. Even experienced industry veterans may not associate usability failures with market failures, since these two events are often separated by a long period of time, and humans are bad at associating effects that occur long after their causes. Of course, someone must put together a collection of these case studies before designers and engineers can learn from them.

Perhaps the most interesting part of the conversation, however, was the discussion of the benefits of "creative tension", or those times when design and engineering don't get along yet wind up with a solution that is better than what they would have come up with if they had. Haven brought up the case of the Harley-Davidson VROD, a case study where there were several examples of the designers putting their foots down and demanding that engineering figure out a way to implement their design, as well as examples of the engineers demanding that the designers come up with workable designs. In the end, this resulted in a better product than Harley-Davidson would have come up with had the two sides come up with a compromise solution.

This raises the question of whether it is necessarily every desirable for design and engineering to get along smoothly, or whether a certain amount of tension and controlled chaos is sometimes necessary to produce a quality solution.

[ Permanent Location ]

Storytime and Pretty Pictures: Data That Informs Design

design, processes & methodologies

November 11, 2003, 11:47 PM

One of the things I'm interested in is studying how to guide design through empirical research, "science-guided design" you might call it. The problem with classical research methods is that although they are effective at uncovering truth, they are too general and reductivist to guide design by themselves. To fill this void, methods have arisen in both usability engineering and interaction design that are intended to help development teams distill fieldwork findings into forms that help designers creatively develop interfaces that satisfy user needs as well as test their interface assumptions against their understanding of the state of the world. Although there are many techniques to fill this role, all of them fall into two general forms. Very roughly, these two forms are "telling stories" and "drawing diagrams".

The "telling stories" approach involves distilling interview and observation data into descriptions of the target users and scenarios of them performing their tasks with the system. The most well-known technique that employs this approach is Goal-Directed Design, developed by Alan Cooper. Cooper's technique involves developing personas, or detailed descriptions of "prototypical" users that incorporate their personalities, goals, skills, etc. Cooper emphasizes that the persona descriptions must be realistic and believable; the team must envision these imaginary people as if they were real users of the system whose needs must be satisfied. Other techniques, such as Scenario-Based Design, take a similar approach but focus more on developing stories of users interacting with the system. But all techniques that follow this approach focus on developing natural language stories about the people who must use (and therefore are a part of) the system.

There are several advantages to this approach:

• Stories make it easier to understand the real human costs and benefits for a solution. Abstract numbers are important for understanding aggregate effects, but they are notorious for hiding away the true events that effect the lives of the people behind those numbers. The "telling stories" approach helps provide this level of detail. This is especially essential for designing desirable products, since desirability is very much a function of individual users' emotional responses to the product.
• Detailed descriptions of users brings focus to design. It helps you define clearly "Here are the people we are designing for. We must always check our designs to ensure that we're convinced they'll make these people happy and meet their goals." You can't do this with vague notions of what "the users" want, and its very hard to do this with purely numerical data (how can we know if we're meeting the goals of all these numbers?).
• Stories are easier to understand. Describing a scenario to people outside the design team (such as management or clients) is generally a much more effective and compelling way to present a problem or a design solution than specifications, diagrams, or screenshots. Explaining and selling your designs is very important, so representing your research data in this fashion helps leverage this fact.
• Stories are "fuzzy". This may or may not be an advantage depending on who you are dealing with. Designers, artists, and end-users may appreciate this quality of these techniques. Engineers, scientists, and (some) managers may not. Know your audience.
• Scenarios can be translated to system responsibilities. If you distill your stories down into specific scenarios, then these scenarios can be distilled, in collaboration with engineering, into system responsibilities that guide implementation efforts. For instance, in the popular UML notation, system requirements are represented as use cases, which are natural derivatives of scenarios of system use.

The "drawing diagrams" approach involves representing data collected during interviews and observations as diagrams and structured prose that describes pictorially the events, interactions, environments, etc. that you encountered. The method that defines this approach best is Contextual Design, which calls for distilling inquiry data into the "five faces of work" — five diagramming notations that describe the work flow, culture, physical layout, artifact usage, and sequence of tasks for every user observed. Beyer and Holtzblatt, the developers of Contextual Design, emphasize that these documents capture the relevant information about the world to guide design, and provide an entire methodology for transforming these diagrams into an actual interface design. Unlike Goal-Directed Design, this process guides you through each step of the interface development life cycle.

There are more techniques that employ diagramming than Contextual Design, however. Matt introduced me to causal flow analysis and systems thinking last spring, two techniques that employ diagramming notations to map out complex reasoning paths and identify patterns and breakdowns in organizational systems, respectively. Although their purposes vary, all these techniques employ diagrams for the same purpose — to focus attention on the aspects of the data that the methodology designers decided was important and needed to be explicitly represented.

There are a number of advantages to using diagrams:

• Diagrams help you understand the whole system. Pictures like this give a more holistic view of the state of the world than stories do, since stories tend to focus on individual people. Natural language often falls apart when you try to use it to describe abstract concepts like organizational systems or the structure of communication in a work environment. A good diagramming notation is much more effective for communicating this information at a glance.
• Diagrams get at data and structures that aren't obvious from descriptive prose. Many important concepts are hidden in plain language, if they appear at all. For example, oftentimes an argument may sound convincing when you read it in prose, but when you draw a causal flow analysis or apply another argument mapping technique, you quickly see the holes. Diagrams help for cases like these by highlighting the relevant parts of the prose and de-emphasizing others.
• Diagrams help you design how your changes will fit into the whole system. It's important to understand that any new system must fit into the larger systems that compose our reality. Diagrams make it easy to guess the results of changes in the systems they represent, since this generally only requires altering the diagram to include the new system.
• Diagrams are perceived as "rigorous". Again, whether this is desirable or not depends on who you are communicating with, but diagramming techniques are generally perceived as more rigorous than storytelling techniques. This tends to go over well with engineers and scientists, and possibly management.

I believe that both of these approaches are important for understanding different aspects of a design problem. Thus, when faced with a choice of which data analysis methods to use, the appropriate question should not be which is better in the abstract, but rather which is more tuned to solving the particular problem the team is facing (often, in fact, the correct answer may be to mix the two and use different techniques for different aspects of the problem).

Finally, I firmly believe that this work has a broader applicability than just interface design. Many, many fields could benefit from decision-making processes that are informed by empirical work. Why, for example, does Congress not charter fieldwork teams to investigate the needs of low-income households before altering welfare laws? Why do we not turn these design processes to systems built of humans, as well as systems built of software or raw materials? The need is there, and the techniques are emerging. I hope the right time for this movement is coming soon.

[ Permanent Location ]

The Principles of Design Research

design, usability

November 08, 2003, 10:18 PM

Last Thursday, Dan posted a nice meta-summary of user research techniques.

The principles he describes are all embodied in HCI's most prominent user research method, Contextual Inquiry (CI). Basically, CIs are ethnographic observations combined with impromptu interviews, wherein the researcher watches the user work and asks questions to get at the purposes behind the behaviors, similar to the way an apprentice would work with a master craftsman. I've conducted a number of CIs since I came here, and I've found them to be incredibly valuable for data collection regardless of the overarching design methodology you plan to employ (i.e., you can benefit from doing CIs even if you aren't going through a full-blown Contextual Design process).

But back to Dan's post. I'll second the recommendation that it's best to work in pairs, especially if you are observing a task that might involve lots of interesting things happening at once, for instance, if multiple users are interacting with each other. I'll also second the prohibition on using video or audio recordings to capture the data (no matter who might tell you otherwise). Although it may seem like a good idea to have an exact recording of the inquiry on file for later reference, in practice it just unnecessarily complicates matters. If it isn't outright prohibited by the participant's organization due to security concerns, then at the very least it will make your participant feel less comfortable and thus may change their behavior, it may make it harder to recruit participants, and it may cause your participant to feel you are impinging on their hospitality, no matter how many promises you make that you won't share the data with anyone else. Chances are, you'll just pop the tape in a file cabinet after the interview and never take it out again anyway. Finally, note taking forces you to be more involved in the inquiry; you can't just sit back and zone out with the knowledge that the camera will catch everything (which is tempting because, let's face it, watching your participant spell check their document isn't exactly like seeing The Matrix Revolutions).

What Dan doesn't cover is preparing a set of focus questions before the inquiry. Running out to collect data without having a clear idea what you're looking for is likely to cause you to waste your time on the first few inquiries. Once you start to look, you'll be surprised how much data is out there in even the most routine tasks; you won't be able to capture the right data if you don't have some kind of filter in place. Deciding on that filter beforehand is critical if you want your research to effectively guide your design.

[ Permanent Location ]

Navigation Assistance for the Elderly

design

November 05, 2003, 10:39 PM

Yesterday, we presented our final designs for the third assignment in VIID; a socially-aware robotic walker for the elderly (you might recall my first assignment, a scheduling application, and my second, an interface for keeping in touch with friends, from earlier posts). Our charge was to take an existing product (a prototype for a robotics-enhanced walker to aid the elderly with navigation tasks) and redesign its interface to better fulfill its user's needs. I worked with Irina Shklovski, a PhD student in HCI, and Yuan-Chou Chung, an industrial designer in the Interaction Design program.

After doing some analysis of the potential markets for such a product, we chose to target elderly Alzheimer's patients as our user group. We conducted a wide range of user research (warning: ginormous 7.6MB PDF file), but this time, I insisted on distilling it into a persona for our target user, as well as a visionary scenario for communicating the final design. I think this helped immensely with conveying how our solution would really behave in the life of a typical user. You can see if you agree by reading the scenario and then viewing our design presentation (the presentation is best viewed by continually "playing" every time it stops, usually from selecting "play" from the right-click menu, but you can also use the controls at the top to skip around). If you just can't get enough, you can also check out a data sheet on some of the walker's behavior.

This presentation speaks for itself a little better than the previous two did, I believe, so I won't belabor it here. As far as lessons learned goes, if I had it to do over again, I'd spend less time arguing over design details and trying to get every last essential feature into the prototype, and more time testing and refining the design based on feedback. I've also learned that I need to refine my skills with low-fidelity prototyping and testing. However, this project did give me a good feel for how the user-centered design process really applies to a more classic interface design problem. I'm looking forward to trying out this newfound knowledge on the capstone project course next semester.

Special thanks to my group members, Irina and Chung, for an excellent job. In particular, thanks to Irina for her help in culling design principles from the human factors and psychology research, and thanks to Chung for an absolutely amazing job with putting together the final prototype and presentations.

[ Permanent Location ]

Weblog Home Page Design Idea

design, internet

November 05, 2003, 04:51 PM

Mark Pilgrim has an interesting redesign of his own weblog's home page that he posted recently. I'm not sure if I agree with the page as it stands, but it's given me a few ideas for roBlog that maybe I'll try to flesh out and implement when (if) I get a chance. I'm interested in trying out some design solutions for roBlog that get away from the standard "linear news" format and move more towards visualizing it as a personal knowledge management system.

[ Permanent Location ]

A Deep Foundation of Disciplines

design, philosophy, teaching & learning

November 02, 2003, 01:56 PM

Last week, Dan posted about his Graduate Design Seminar class (as is his wont on peaceful a fall evening), specifically covering the nature of arts and the nature of products. I recommend reading them if you haven't already.

While reflecting on the profound ideas plainly put in Dan's point-by-point, notebook-ish style, I started to consider the role of philosophy in education. Dick Buchanan, who by all accounts is a man of amazing intellect and profundity of thought, seems to have crafted this class to give the design graduate students a solid foundation in how their discipline fits into the intellectual frameworks of society.

This got me thinking again about the role of higher education and what distinguishes a university education from a trade school education. Perhaps part of the preparation for becoming a skilled professional involves understanding the philosophical underpinnings of your discipline and how it fits in with the rest of society, both intellectually, historically and culturally; it's not enough to just learn the skills to get by. And if these underpinnings are still poorly understood, perhaps because your discipline is young, then you should at least be aware of the open issues and what the current level of understanding is. Many programs ignore this aspect of education; I was never taught the foundations of computing in this fashion, for instance. Yet perhaps learning these truths before practicing your trade is premature anyway, since you won't have the experience to connect them up with to make them meaningful to you. More thinking is necessary, obviously.

I've been half-trying to avoid reading Dan's posts about Design Seminar recently, although not because they aren't good. Every time I do, I feel like a penniless, hungry child looking in a bakery window; I can see the wondrous pastries and smell their delectable smells, but I'm helplessly tormented by the knowledge that I'll never get a taste. Kerry says I should stay here at CMU an extra semester next fall just to take Design Seminar. I'm tempted, sorely tempted...

[ Permanent Location ]

The Glider and Design

design

October 29, 2003, 11:00 PM

Eric Raymond has proposed an emblem to represent hacker culture:

The image depicts the "Glider" pattern from the Game of Life. The glider is notable because it is the simplest pattern that moves.

I'm not thrilled with the idea of a "hacker emblem", but perhaps that's just because I don't particularly identify myself with the hacker culture. I like the logo, though, because of the glider's effectiveness and elegant simplicity. It's a nice visual representation of the concept of minimalist design, or "the simplest thing that could possibly work" (often invoked in the form of the KISS principle). I don't know about everyone else, but I often have problems following this directive, so keeping its representation around as a reminder strikes me as a good idea.

[ Permanent Location ]

Information on Personas and an Argument for Design

design, processes & methodologies, usability

October 25, 2003, 09:29 PM

There's a good, thorough overview of personas on Information Today. The article gives a great digest of Cooper's description of personas in Inmates, although once again I could ask for a little more guidance on how a researcher is supposed to collect the data to back up a good persona. There's talk of careful collection of qualitative data, but the process of translating those findings into personas is still pretty mysterious.

What I particularly liked, however, was this small story that illustrates the need for user-centered design:

One of the best arguments for using personas comes from some misguided design efforts at Microsoft. When the software giant geared up to redesign its well-known Microsoft Office Suite for a 1997 release, the research team soon discovered that many of the features users wanted already existed. In fact, four out of five of the features users requested for Office 97 came with Office 95. The outcome of Microsoft's design approach is just what Cooper warns against. In trying to support the diverse tasks of many conceivably different software users, Microsoft cobbled together a product that was bloated with capabilities and ended up satisfying few users.

Many people in marketing, development, and management will argue that piling features into a new product is far more important than designing usable interfaces and compelling interactions. And early on in the product's life cycle when the features are few and the interface relatively simple, this may be true, at least if your users are fairly computer-saavy. But once a few layers of those nifty new features have been slapped on to the product, you'll quickly start to find your users asking for capabilities that already exist. Bottom line is, you wasted your time with all those shiny new features, because your interface is so poorly designed that nobody even knows they're there.

[ Permanent Location ]

Rethinking File Transfers

design, internet

October 24, 2003, 12:20 AM

Joel is posting about tokens, a new way of transferring large files and/or complex folder structures:

It's hard to believe that here it is, what, 2002? No, I think it's 2003, and when you want to send a really big file or a folder full of little files to someone, you generally wind up messing around with ftp servers and whatnot.

Well, no longer. "A token is like a shortcut or alias that you can send via e-mail or instant message. With just one click you can create a token, and no matter how large the files you want to send are, the token representing them will be very small - just a few KB. Anyone you send a token to can then download the free Creo Token Redeemer software, and with one click redeem the token and download the files. It works for anything - a single file, an entire folder, a huge movie."

What's interesting about this idea, whether or not it takes off, is that it's a new interaction design for a very old problem that has enjoyed virtually no improvement for decades. It's always great to see fresh new solutions for hoary old kludges that, for some reason, everyone's implicitly agreed just can't be improved (even if they are obviously in need of improvement).

[ Permanent Location ]

Is Usability Destroying Innovation?

design, processes & methodologies, usability

October 23, 2003, 11:45 PM

Dan has a post pointing to an article in the Guardian on innovation and user-centered design. The article's short so it's worth the quick read, but in brief it claims that user-centered design has become dominated by usability practitioners, that usability is a conservative approach and inhibits innovation, and thus it should be de-emphasized to encourage greater innovation in products (well, that last part is implicit but it's certainly there).

On the one hand, the core point of this article is quite accurate. It's important to produce innovative designs so that you aren't just incrementally improving the same old (bad) design concepts. And if you take a narrow view of usability (namely, that it only exists to find errors in the design of existing interfaces through analytical (heuristic evaluation, cognitive walkthrough) and empirical (usability testing) techniques) then this is the whole story.

But this is not the whole story. The user research techniques that form the core toolkit of any usability professional worth her salt include much more than testing. To be specific, we use lightweight ethnographic techniques like contextual inquiries and user interviews to study the way users work in the abstract so that appropriate design solutions can be found. This type of research can drive design, indeed it must drive design if the final product is to be usable, useful, or desirable.

The article also appears fairly ignorant of established usability practices. In particular, it states: "Too much user focus may be a barrier to innovation. Research is likely to tell us that users desire an improvement on something they already understand. Ask them if they would use a proposed innovation and they will say no - and then adopt it when they have seen its utility demonstrated." Very true, but this has been well known to usability professionals for over a decade. Studies by Nielsen (and others before him) firmly established that directly asking users what they want will yield bogus data. Any decent usability professional knows this and would not trust the answers to such questions. Design must be constrained by the users' observed needs, not the user's expressed ideas.

In summary, my main concern with this article is not that I disagree with its premise but that I'm unsure what the takeaway message is. If the takeaway is that user-centered design must begin earlier in the process through user research and interaction design, then I'm firmly in agreement. But if the takeaway is that designers must be left to design without being constrained by user needs that are well understood through sound research, then I'm worried, because then we're dropping the whole "user-centered" part of "user-centered design". The user is not like me; I don't trust my own or anyone else's "educated guesses" about what someone else will want in a product or interface design.

Finally, I'm concerned at the distinction between "usability" and "design" that is drawn in this article as well as in the industry as a whole. I don't really believe that the two are cleanly separable, any more than I believe that software architecture design is cleanly separate from programming, for example. In my not-so-humble opinion, user-centered designers must, at least to an extent, be good at both user research and interaction design, and specialists in both fields must work closely together to be effective. We of all people should know that we ought to be putting the user first in all that we do. And in this instance, the user doesn't care what fancy titles we pin on ourselves. The user cares about getting a great product that makes his life better. And we need all these skills (mixed with sound engineering too, I might add) if we hope to give it to him.

[ Permanent Location ]

The Design and Development Disconnects

design, software development, usability

October 14, 2003, 10:14 PM

I've been thinking a lot recently about the communication between software developers and usability/design people, for my usability and software architecture work, my open-source and usability work, and for an SSS topic I proposed. Here's a preliminary list I came up with of development & usability problems that might inhibit good design.

First off, one central point to make up front is that in most cases, everyone on the team; usability professionals, designers, and developers; wants the final product to be usable. Very few people set out to create a system that is useless to their target users.

That said, the system might wind up less-than-usable because of one or more of the following reasons:

1. A design may call for solving impossible problems. There are a few classes of problems in Computer Science that are genuinely unsolvable for all practical purposes; "Traveling Salesman"-style problems with exponential time complexities are examples, as well as incomputable problems like the Halting Problem. These are pretty rare in everyday system design, however, so chances are a design will be at least theoretically implementable.
2. A design may call for implementations that are possible, but infeasible. These types of designs may be theoretically implementable, but they would take far too long to implement and/or too many resources given the current state of the art. This changes with time, of course; once-upon-a-time building a WIMP-style interface would have been infeasible for most projects; with modern toolkits it is fairly trivial.
3. Implementing certain design features may necessitate sacrificing others. Some design features take longer than others. Given that the project must be completed in a fixed time frame, in order to get these features in as designed, other features may need to be sacrificed. XP's Planning Game provides a mechanism for communicating these tradeoffs based on experience-based estimates and encourages informed decision-making on the part of management and design.
4. Implementing certain design features may necessitate sacrificing other software quality attributes that are important to the project. Examples of quality attributes include performance, modifiability, and reliability. Sometimes, certain design features may require an implementation that performs slower than design alternatives, for example. Designers must be educated on how these quality attribute tradeoffs influence their designs, and Software Engineers must understand how these quality attributes influence the user experience, which is ultimately the most important consideration.
5. Architectural decisions made early on in the development lifecycle may preclude the implementation of certain design features. Generally speaking, this is a time tradeoff that didn't need to be made had these design features been considered earlier in the process. The solution, of course, is to ensure these features get considered early enough for them to be feasible. Our U&SA technique attempts to tackle this issue.
6. Design and development may have different priorities. Design tends to focus on the features that are most necessary for their users, based on their research and testing. Development tends to focus on the features that are the riskiest to implement, generally preferring to tackle those first to make the project more manageable. These two groups must come to a consensus; the developers must understand that the most technically sophisticated features aren't always the most important to users, and design must understand that development's technical priorities must be respected if the project is to get completed on time and under budget.
7. Design and development may experience simple miscommunications. Design may think they are proposing a particular interface design solution, but development might hear something different. The way it works out, of course, is that development's version actually gets implemented in the final product. The solution to this problem might lie in more rigorous specification techniques or formal sign-off procedures, but I tend to lean towards Agile Software Development's philosophy of simply having Design and Development work together more closely, ideally in the same room, all the time.

[ Permanent Location ]

Using Research to Guide Design

design, processes & methodologies, society & sociology

October 13, 2003, 11:15 AM

As I've mentioned before, I'm taking CSCW: Designing Online Communities this semester and one of the stated goals of the class is to figure out a way to translate the knowledge gleaned through social science experiments into a set of principles that can guide the design of online communities. The way we've been approaching this so far has been to distill out a set of stylized social science facts and then brainstorm features that would conform to these principles (generally by altering the design of an existing system, MovieLens).

My preliminary thought on this approach, however, is that this is the wrong way to go about applying social science to design. The problem is that brainstorming features from social science facts doesn't take account of the holistic nature of design; the principles are very specific and reductionist and thus the feature ideas you tend to get may violate some principles while supporting others, or just be bad ideas for other reasons. Some of the stylized facts are even contradictory, at least at this abstracted phase (e.g., disclosing personal details about yourself makes you like the people you disclose them too, but spending too much time with people you have an intense relationship with makes you like them less). They also might not fit into the conceptual structure of the design, or the culture of the particular community.

This is not to say that the whole idea is fundamentally flawed, just that I believe we should take a slightly different approach. Instead of using social science to guide design explicitly, we should use our stylized social science facts and distilled design principles as heuristics that can be applied in a post-design analytical usability evaluation, similar to Heuristic Evaluations. Although these principles may influence community designers, just as Nielsen's heuristics influence user interface designers, they are primarily intended as a checklist. Nobody comes up with interface designs merely by pondering Nielsen's heuristics, so we shouldn't expect that of community design either.

[ Permanent Location ]

Keep In Touch

aesthetics, design

October 05, 2003, 09:03 PM

As a follow-up to my wicked-cool scheduling application design, I've been working for the past few weeks on a new assignment, this time a design for a situationally-appropriate interface for helping people keep track of long-distance friends, lovers, and family. Jodi teamed me up with Elizabeth Windram, a very talented graphic designer, and Chun-Yi "Grace" Chen, a skilled industrial designer / product illustrator.

The basic challenge was to produce an application that could help remind users of the people they needed to get in contact with while also not demanding their full attention (i.e. popping up a dialog box that proclaimed "YOU HAVEN'T CALLED YOUR MOM IN 10 DAYS!" was unacceptable). The interface also had to involve components that could 1) be understood at a glance, 2) be understood entirely aurally, and 3) be understood without the use of vision or hearing.

We never came up with a name for our design solution, so for the purposes of this post I'll call it "Keep In Touch". You can view our design presentation if you have Flash Player (warning: ginormous 13.5MB SWF file).

The Flash movie was intended to be supported by our verbal discussion, of course, so I'll try to cover what might not be clear from just watching the SWF. Our goals for this design were:

1. Not to demand the user's full attention (dictated to us by Jodi).
2. Take advantage of more of the user's senses than just sight (also dictated by Jodi).
3. Encourage, not force, the user to contact their friends and family.
4. Give the user enough context about what was going on in their friends lives that they would actually have a reason for contacting them.
5. Help the user avoid spending too much time talking to friends, so that they can also get other things accomplished.

Our solution is basically a screen saver that displays a collage of pictures of your friends whom you need to contact. Along with the pictures are a few images that are intended to give some context about what is going on in your friend's life right now. For example, the girl in the movie with the airplane next to her picture may be planning a trip abroad. At the same time, the system plays songs that are intended to remind you of the person who ranks highest on your "get in contact with" list (for instance, the song might be a favorite of the individual in question, or it may be one you often listened to with that person).

The second component of our system is an intelligent mouse that warms up to alert you to the fact that you need to get in touch with someone. It also plays the person's song, to remind you of who its alerting you about and to provide a link between the tactile and visual components of the interface. Additionally, the mouse tracks how much time you spend talking to someone (on AIM, for instance) and produces small bumps that give a rough measure of how long its been. This is intended to help you manage how much time you spend with each friend in a subtle, unintrusive way. The mouse is cordless and portable, so that you can carry it around with you and receive reminders when you're away from your computer.

The system determines who you need to get in touch with using a complex and largely-unspecified algorithm, but here's a few of the things it takes into consideration:

• How long it has been since you last contacted the person (determined through monitoring email, phone calls, IMs, etc.)
• What an "appropriate" amount of time would be before contacting the person. For example, you can and should allow much more time to elapse before contacting distant business acquaintances than you should for close friends.
• Whether an important event, such as a birthday or wedding, is occurring in your friend's life.
• Whether your friend is in a situation where they might want or need you to contact them (if they are feeling depressed, for instance). These last few might be determined by monitoring your friend's weblog or online photo journal, and thus our interface might be considered a futuristic news aggregator (Newsable 8.0! :)

So that's "Keep In Touch" in brief. All in all, I think we did a bang-up job on the project. Special thanks to Elizabeth and Grace for their great ideas, their awesome visual design skills (this project would be 10 times uglier if I'd had to do it myself) and for generally being great group members.

As usual, Dan has some great content demoing his project, BreakAway, if you want to read about more awesome products that you can't buy.

[ Permanent Location ]

Small Groups for Design Critiques

design, processes & methodologies

September 25, 2003, 11:09 PM

In VIID today, we divided up into small groups to discuss our design sketches for the second project with members of the class who were not on our project teams. I wound up in a group with just Kerry, although Jodi and Bilge both dropped by during the session to offer their comments on both of our designs.

This turned out to be a pretty effective format for refining and improving our design ideas. My group got a lot of great feedback that has really helped us pull together the several disparate design solutions that we'd been kicking around before. We came out of that session with much more direction than we'd had going into it, which is something I can rarely honestly say about a class meeting.

Dana and I are discussing the possibility of attempting to bring this format into Newsable as another solution to the open source and usability problem. We hope to set up an appropriate online virtual environment for developers and usability professionals / designers (we're calling this group "usables", which I assure you was entirely Dana's idea) to brainstorm, test, and critique new suggestions and designs. We hope this will form the kind of small groups with small group size, high task valence, and high senses of group identity that previous social science research has found to greatly increase quality contribution.

It's an amazing experience to be working with Dana. So far she's brought much more focus to the project than I've had all summer as well as some great new ideas that I would never have come up with on my own.

[ Permanent Location ]

Redesigning Scheduling

aesthetics, design

September 22, 2003, 11:58 PM

Our first assignment in Visual Interface and Interaction Design (a.k.a. "Jodi's class") was due last week. This was my first attempt at real, live interaction design (well, my first intentional attempt), so I'm documenting it here for posterity or something.

Our assignment was to design a new type of "scheduling application". The first thing I learned was that Jodi's concept of an "application" is much broader than mine. Most of the examples she showed us were entire products and not just software running on a standard computer. The implicit message was that, to an interaction designer, it is the experience of the user that counts, not the form of the design solution. Jodi placed no constraints on this form; software versus hardware wasn't an issue.

Instead of a fully fleshed-out product specification, Jodi wanted a refined concept for the application that could demonstrate how a user would schedule an appointment, remove an appointment, and handle double-booked appointments using the interface. As part of our familiarization stage, we developed the product taxonomies and mood boards that I mentioned earlier. I found the taxonomies useful insofar as they helped me really focus on how the form of a product impacts the way we use it. They got me thinking about affordances again, which I hadn't really focused on since reading Norman's book so many (four) years ago. I didn't get into the mood boards quite so much, but I did take from them some general thoughts on how human senses and emotions might relate to my interface, as we'll see.

I set aside all this work for a bit when I came up with the initial concept, however. To do that, I reflected on the scenario I articulated in my Visions of a Distributed Future post; I thought of a world, not too far removed from becoming reality, where physical location is less important, we are far more mobile, and where work and play blend together into a single concept of "living". What would a scheduler look like in this world? Despite the advances in mobility, people still can't be in two places at once, so it would have to be heavily time-focused. I threw up some thoughts on my whiteboard:

Around this time I decided to focus on a particular type of user. Since I had no data on what other people want, I focused on creating a scheduling app for people like me; i.e. students / lowly technical staff. I drew a picture of how I conceive of time on a day-to-day, operational basis (its on the left of the whiteboard); essentially, time consists of "now", a past that I care little about since its already over with, and a future that is segmented into slots that I can fill with meetings or other engagements. This concept, combined with the drawing of a fancy armband I doodled next to it, essentially turned into my initial design. It struck me that it resembled a snake, and I started thinking up some ideas for how it might work.

The next morning, I built a low fidelity prototype of the concept so Jodi could critique it:

As you can see, I strapped this monstrosity to my arm and walked around with it for the better part of the day. Strange thing was, this actually really helped me come up with refined ideas for the product; having the snake really sitting there on my arm gave me a new sense of what it might be able to do were it really functional.

For the second iteration, I developed a higher fidelity prototype using modeling clay and a real watch:

The interaction design didn't change much, but this prototype helped communicate the vision for the scheduling application more clearly (I hope). To describe the functionality of the inert prototype, I put together a small product spec sheet and a scenario-based description of how the product handles the functions Jodi asked us to demonstrate. Looking over these might give you a better sense of how the snake works than the photographs alone do.

The knurling and basic product design came largely from my exploration of the taxonomies. The anthropomorphic reactions of the snake came (in part) from reflecting on the concepts that appeared in my mood boards. The general design concept came from the distributed future scenario, although I realized as I was finishing the product that it was really a fairly realistic device even for the near future. It's odd, but I felt that considering an "out there" scenario helped me come up with some interesting ideas even for a product that didn't wind up being as futuristic as I initially thought it would be.

I wish I had the chance to explore more options with this product; once I came up with the general form of the solution I kind of stopped exploring. However, our second project has already begun, and for it we're required to go through a much wider exploration phase. I'm also still a little unsure how much I used the familiarization artifacts (the mood boards and the taxonomies) in my final design. They were helpful, but maybe not helpful enough to justify the large amount of time I spent on them.

If I'd had the time to refine further, I would have liked to produce an even higher fidelity inert prototype (that was thinner, for one, and possibly made of metal rather than modeling clay) as well as an interactive flash movie that demonstrated how the interaction with the snake's screens would work. But all projects have a deadline, and this one's is past.

Dan discusses his design on his weblog if you just can't get enough.

[ Permanent Location ]

Of Moods, Taxonomies, and Exploration in Design

aesthetics, design

September 09, 2003, 10:55 PM

For the last week and a half or so, I've been hard at work for my Visual Interface and Interaction Design (VIID) class developing two sets of artifacts: four mechanical product taxonomies and seven "mood boards". In theory, all this work is supposed to lead to ideas for our first assignment: to develop vignettes for a new scheduling application. There are very few constraints, but Jodi seems to want us to explore radical ideas instead of sticking to old hat; for instance, last year Abby did a "schedule ball" that let you set appointments by turning its two halves in different ways. Another student made a piece of ribbon that represented time and that you could pull from its spool and mark with pins to represent appointments.

If you take a look at my taxonomies, you'll find we were asked to examine a few physical, mechanical products and describe how users interact with them, how the products' parts responded to this interaction, what sort of affordances they provided, etc. I found this really forced me to sit down and think about these common artifacts in a way I generally never do; I started to realize why we know (or don't know) how to use them fairly intuitively.

For my mood boards (warning: ginormous 9MB pdf), I took the seven words Jodi gave us, then brainstormed some other words that came to mind when I thought about those concepts. I picked four of these "attributes" for each board and searched for pictures that I thought exemplified their meanings. In the end, I found that three pictures wasn't really enough to capture the meanings of these broad concepts (duh), so instead I put in images that I felt gave enough of a sense of the contrasts within each attribute that I could reflect on the range of thoughts and emotions I associate with each.

So far going through the process of doing these exercises hasn't helped me to come up with any brilliant ideas for the actual scheduling application. Abby, however, assures me that this will come in time. The extent of my thinking so far is that I want to come up with some ideas for a scheduling application that might appear in my Distributed Future scenario, but whether that will pan out or not, I can't yet say.

[ Permanent Location ]

Note to Phone Manufacturers: Innovate!

design, writing & communication

September 03, 2003, 07:47 PM

Why is it that phone manufacturer's can't seem to create a phone that contains a single innovative, useful, and usable feature to save their lives? Even cell phones, which certainly have quite a bit of market variety (too much; I just spent ages trying to find the right one for me), don't seem to produce much real innovation. It's all well and good that the phone can synch with my address book (or so claims the box) but if I have to go through some godawful 12 step process to do it, the feature mind as well not be there. I want these features to save time, not waste it! And no, "let's stick the internet on our phone!" doesn't count as innovation.

How about adding in the ability to not ring if the caller is not identifiable? I was just interrupted from writing this very post by "Unknown Name, Unknown Number"; the fourth time tonight. Or perhaps speak the name of the caller using text-to-speech? My phone should be my ally in warding off the unwelcome telemarketers, not collaborating with them.

So come on, guys and gals. I know cell phones are new, but a little interaction design and usability would do wonders for them. And if you don't hurry up, Neema just might beat you to it...

[ Permanent Location ]

Dancing Bears

design, usability

August 29, 2003, 08:20 PM

Against my better judgement, I was flipping through the first half of "Inmates" a couple days ago. I came across an interesting concept Cooper describes as a "Dancing Bear":

In essence, a dancing bear is a product that is interesting and useful not because it works particularly well, but because it works at all. Cooper describes his car's keyless entry system as an example, which is horrendously difficult to use but still addictively useful because of the advantages of remote entry to his vehicle. In his words:

In spite of its weak and clumsy design, it is still a wonderful thing. It's like the fellow who leads a huge bear on a chain into the town square and, for a small donation, will make the bear dance. The townspeople gather to see the wonderous sight as the massive, lumbering beast shambles and shuffles from paw to paw. The bear is really a terrible dancer, and the wonder isn't that the bear dances well but that the bear dances at all.

...

The difficulty of devising a better interaction isn't what makes the problem so intractable. Instead, it is our almost universal willingness to accept bad interaction as an unavoidable cost.

There are many dancing bears on the technology market today, I'm afraid. Sometimes, after seeing a series of poorly designed products beat out well-designed alternatives just because they were "new and cool", it's easy for us user-centered designers to dispair; sometimes it seems like people just don't want usability! I think it can be encouraging to consider these products dancing bears; the problem is that right now information technology-enabled products are so new that many will buy them even if they are unusable simply because they don't know any better. As these products sink into society, however, the buying public will become more informed consumers. Then, our skills will really have a chance to prove their value.

[ Permanent Location ]

The Right Tool For the Right Type of Job

design, software development

August 28, 2003, 10:39 PM

I've recently found myself complaining a lot about how there are no good tools specifically designed for developing software prototypes for formative usability evaluations. Oh sure, there are products like Flash and Visual Basic that are often used for prototyping, but both of these tools were initially designed for other uses (web vector graphics animations and novice programming, respectively) and were later repurposed into prototyping tools. And yes, there are plenty of IDEs out there that claim to support Rapid Application Development (RAD), but I hope to show that these are insufficient since the design philosophies that created them are misguided.

First off I want to make a distinction. There are two types of software:

1. Production Software, or real systems intended for real use. Any software people use to accomplish real work or real play should be this type of software (sadly, this isn't always true in practice, as we'll see).
2. Prototype Software, or mockup systems that behave similarly to the final product but aren't as polished. By "polished", I mean that the developers have paid sufficient attention to good design and testing practices that the system doesn't crash very often, is secure against intrusion, works on all the supported platforms, etc. Prototypes are used both to explore technologies and to elicit user test data; by having users interact with the prototype you can examine how long it takes them to complete tasks, how much they struggle to learn how to accomplish their goals, how much they like the product, etc. Since these tests are run in a controlled environment, the quality attributes that are so important for production system use are much less important for prototypes.

There is actually a third type of software: small, specialized programs or "scripts" that are written quickly to fulfill a very narrowly defined automation need. Usually, these are written directly by users: a system administrator writes a shell script to purge user records, a programmer writes a Perl program to format his source code, a researcher puts together some code to analyze a large database of survey results. But, for the most part, these types of programs tend to have short life spans, are easy to write, and thus need little tool support to develop.

Most of the commercially available programmers' tools today are highly "schitzophrenic"; that is they were designed to try to satisfy the needs of developers of both types of software. Unfortunately (as we interaction designers and usability professionals could have predicted) these tools have ultimately failed to effectively satisfy either purpose. GUI Builders are great for prototyping, but produce unmaintainable messes when doing production development. Strong typing and other language-enforced constraints, on the other hand, save hours of debugging during production development, but just get in the way when putting together prototypes.

What we need is tools designed exclusively for prototyping and other, different tools designed exclusively for production. The prototyping tools will require features such as:

• Support for rapid development. These tools will need to take care of as many menial programming tasks as possible for the developer to make her more efficient. Features like wizards, code generators, and GUI builders are examples.
• Highly malleable interface capabilities. To facilitate trying out lots of different ideas, these tools must be flexible in the interface options they provide to the developers. The problem with lots of RAD tools is that they impose a strict framework on the developer that greatly limits interface design options (e.g., Visual Basic).
• Quick feedback. The developer must be able to see and interact with the results of interface and interaction design changes quickly, ideally at the push of a button.
• Easy rollback. The developer must be able to easily roll back to previous versions of the prototype in case changes don't work out. It would also be a good idea to keep a history of these changes, and possibly allow developers to associate commentary with them (such as why certain design changes didn't work out) to make documentation of the design process easier.
• Deemphasis on maintainability, portability, etc. These are unnecessary for prototypes, as I mentioned before.
• Easy and fast debugging. The developer needs to be able to get it working well enough for the next round of user tests quickly.

Prototyping tools may even be best when they explicitly do not afford building complete-looking systems, since this discourages the temptation to "just ship the prototype" that is so common when time and money is tight (which it always is). Perhaps prototyping tools should even include "sketchiness features", like Denim, to help visually communicate the incompleteness of the prototype product to decision makers.

Production development needs its own set of tools. They will require features such as:

• Facilitation or enforcement of best practices. This includes language features like strong typing, Eiffel-style design by contract, etc.
• Good refactoring tools. Production code changes too, but when it does, the integrity of the design must be maintained. Refactoring tools can help with this.
• Ways of visualizing code structure. This includes modeling languages like UML and architecture description languages. Graphical notations like these can help give high-level views of the software's structure, which is likely to be complex in production environments.
• Team features. Most software is written by teams of programmers, so the tools must facilitate group interaction. Version control is the most common and probably the most important example.
• Automated test building environments. Production tools should favor automated, repeatable test suites over step-by-step debuggers (although these, too, may have their place). Tests such as these help form release baselines on which all future development can be built.

This is, of course, just an initial list of thoughts based on my own readings and experience. Someone needs to work on these more to identify the real needs and appropriate solutions.

Are you listening, Andy??

[ Permanent Location ]

On the Inadequacy of Categories

design, information

August 24, 2003, 10:11 PM

As I just mentioned yesterday, a common technique for organizing information is to put this information into categories, thus making it easier for users to locate specific information as well as search for types of information based on predefined properties. Generally speaking, this works pretty well; libraries and other information-rich environments have always lived by their categorization schemes.

But then someone got the bright idea to allow ordinary users to define their own categories for their own information. This, I'd argue, doesn't work so well.

A case in point is the very weblog you're currently reading. Shortly after starting roBlog, I went through a fairly rigorous process to develop categories for my current and future posts. I was hoping these categories would be fairly exhaustive (most every future post would fall into one or more of them), fairly meaningful to my readers, fairly few (I didn't want a huge list of categories that was hard to scan), and fairly balanced (I didn't want all my posts clustered into one category).

I'm becoming more and more dissatisfied with the results. I'm finding that most of the posts are clustering into a few categories and even I can't always tell what category a particular post should fall under, so I can't imagine its intuitive for you guys and gals. One option is to simply create more specific and a wider variety of categories, but I'm concerned that this will soon cause the number of categories to balloon into something unmanagable.

In "Inmates", Cooper complains about file systems (which are generally hierarchical, but hierarchies are essentially nested categories); he feels it is unrealistic to expect users to effectively organize all their personal information through this paradigm. And I can certainly relate to this; I know many people, all of whom are highly intelligent and very computer-saavy, who constantly lose track of where they put things in the file system. But even more specialized applications have this problem; I've given up on trying to categorize my MP3s by genre; I'm never able to remember what I filed a particular song under and I rarely want to hear all songs in a given genre.

The basic problem, I believe, is the user-built categorization schemes expect users to know what kinds of questions they're going to want to ask when searching for their information before they actually need to ask them. Most users don't have sufficient experience in the domain to know their own behavior patterns. And most of those users that do won't have reflected sufficiently on their own practices to design effective categorization schemes anyway.

The upshot is that designing good categorization schemes often requires extensive training. Library Science is an entire field that focuses mainly on solving this very problem. For those of us that lack such training, its difficult to know how to categorize the information we work with for maximum productivity.

For my own categorization problem with roBlog, I'm considering taking a suggestion Micah made; he thought I should group posts by certain interesting topics (such as some of my professor's names) since this would gather information on those topics in one location for Google searchers and the like. I'm thinking that these topics wouldn't be exhaustive; they'd be more like the "features" sections that Micah has on his own weblog.

[ Permanent Location ]

Info Design's LATCH

design, information

August 23, 2003, 07:22 PM

This one's gonna be a quickie, but I wanted to throw it up while I was thinking about it.

During the last week of CDF on information design, our instructor, Bob Swineheart, remarked that there were five ways of organizing information items. The mneumonic is "LATCH":

1. Location
2. Alphabetical
3. Time
4. Category
5. Hierarchy

I've been thinking it over, and so far I haven't come up with organization scheme that doesn't in some way fit into one of the above. Thoughts?

Ok, now I'm heading over to Walnut Street to drink and party with the new MHCI students. Less bloggin', more boozin'! :)

[ Permanent Location ]

The Borg Queen Awakens

announcements, design, people

August 19, 2003, 08:08 PM

My good friend Kerry Bodine has started up a weblog, Styleborg, that focuses on wearable computing and fashion. If you're interested in the new field of wearables, or especially if you're interested in the very new field of fashionable wearables (does this even qualify as a "field" yet?) her weblog is definitely worth checking out.

Welcome to the blogosphere, my queen. You have been assimilated ;).

[ Permanent Location ]

Generalizing Design

design, processes & methodologies

August 10, 2003, 09:37 AM

Six weeks ago, I posted about the design process that we learned in CDF. Now, CDF is over (exempting the process book, which I'm struggling to compile right now). Over the course of the session, I've been reflecting on whether there's any such thing as "design" as a general concept and, if so, what it might be.

I've had some preliminary thoughts on this topic and even voiced a definition of "design" before, but I still considered the word mostly an open category; there's little similarity between all the activities called design, software design and visual design being prime examples. However, after broadening my horizons a bit more, I'm starting to form a vision of general themes that run through all these activities to bring them together into a coherent class of activities.

The Design Process

I'll start with some general thoughts on the design process. From my original post, we know that the design process is broken down into three parts: familiarization, development, and refinement. So we have:

However, we also know that this ideal model never works in practice. So in reality, we have:

The important thing to note about these pictures is that the theoretical process strictly divides each step, whereas the actual process (the one that works) is much more messy since it calls for moving on to the next step before you've really completed the previous step. Thus you're likely to end up oscillating between two (or even all three) of the steps, running them in parallel, tossing out work from later steps to refine earlier steps based on what you've learned, etc.

In all the design processes I've encountered, there is considerable disagreement in their respective fields over how much overlap there should be between techniques that fall into each distinct step of the process. When you're in the familiarization-development part of the process, you can't finish familiarizing yourself with the problem unless you start developing, since this helps you learn what you need to familiarize yourself with. There is simply too much information in the world to make familiarizing yourself with everything you "need" practical in a limited time frame; starting development gives you focus. But if you develop too much without doing enough familiarizing, you may discover (usually too late) that you've been developing the wrong solution to the problem (or the solution to the wrong problem) all along. Likewise, in the development-refinement stage you need to begin refining to discover whether your development is working or not. But if you refine too much and then realize you need to change your development, you'll have to throw out all your refinement work, which may be unacceptable late in the game. Additionally, too much emphasis on refinement can distract you from large, looming development problems that are much more important in the long run than the piddly little refinement issues.

The Design Problems

This general design process is independent of what you're designing; it should hold as true for designing cars as it does for designing cities. Additionally, there are a few problems inherent in this process that always tend to crop up in one form or another:

• Early decisions dictate future decisions. This means early decisions are hard to change late in the process since doing so entails throwing out lots and lots of later decisions (which translates to throwing out work, which translates to throwing away money in our capitalist system). An instance of this is the software architecture problem, about which I've spilled so much digital ink in the past.
• Wide exploration of the problem is necessary for coming up with the best ideas. The wider your exploration, the more possible ideas you'll come up with, thus improving the probability that a select few of these ideas will be good ones worth pursuing. In the small, this isn't always true; sometimes you'll stumble on a great new idea right off the bat. But its more likely that this idea merely seems good, and upon considering several more you'll find better ones or at least realize why the first one wouldn't have worked after all. More experienced designers can sometimes get to these ideas with shorter, more directed explorations, but even they realize that they can't take the first thought that pops into their heads as the One True Way.
• Feedback on all activities is essential, with tight feedback loops. Without feedback, there's no way to distinguish the good ideas from the bad and no way to know which designs are working and which aren't. Without tight loops, you'll run afoul of the early decisions problem I mentioned earlier since you won't realize your approach is problematic until it's too late to economically change it. Both are absolutely essential to keep the whole process from falling apart around you.

Examples of the Process in Practice

The design process gets instantiated in many fields, all of which follow the same basic steps and struggle with the same basic problems. I've already said a few words about how I think it relates to the everyday task of redesigning my living space, but now I'll try to apply it to my more professional interests.

In software development, the familiarization stage involves understanding the technologies the system will be constructed on through research and prototyping. The development stage involves constructing the software architecture and related decisions. The refinement stage involves developing a detailed design and writing and testing actual code. As I mentioned before, the software architecture problem appears because early design decisions dictate future decisions; changing the architecture late in the process involves throwing out and rewriting lots and lots of code. Unit and functional testing provides feedback to the developers in the refinement stage on whether their detailed designs and their realization in code are working (although often this feedback occurs too late to fix problems from the development stage). Ideally, the team uses refactoring to explore a wide range of ideas, both at the detailed (refinement) level and the architectural (development) level, but sadly, wide exploration and early testing of architectural decisions is rarely done, to the detriment of the profession.

In interface design, the familiarization stage involves discovering the real needs of your user population through observations, interviews, stakeholder meetings, competitor analysis of similiar products, etc. Development involves brainstorming ideas for the actual design, constructing information architectures (there's that word again), doing screen flows and other structuring activities, and building lo-fi mockups to test all this. Refinement involves building hi-fi mockups of individual screens and running them through the testing methods (cognitive walkthroughs, think-aloud tests, etc.) for feedback on whether your solutions are usable. Again, once you've settled on a basic design its hard to change since it involves throwing out so much work. This is especially true when its committed to actual code and thus runs afoul of the architecture problem, and its even more true when its in actual use, and modifying the interface may confuse and anger existing users. Of course, any usability professional knows how important feedback (in the form of usability testing) is, and any interaction designer will tell you how important it is to brainstorm and try out many ideas if you want to find one that actually works.

In communication design (what we've mostly been doing in CDF), familiarization involves understanding the audience and the message as well as the constraints on the communication. We did some of this in the final week of CDF on information design, where we redesigned the post office's mail forwarding form and did some analysis of focus group results, the information structure of the form itself, and the technical constraints of the problem. Development involves coming up with lots of ideas for solutions and realizing these ideas in rough sketches or possibly more polished proposed solutions. Refinement involves the thousands of little painstaking tweaks to perfect the visual presentation, the tediousness of which will keep me from ever becoming a visual designer :). Feedback in this field usually occurs at all stages through critiques with other designers. Sometimes user testing occurs as well (Bob, our professor for information design, remarked that the next stage after designing our forms would be to user test them), and I'd argue it should occur more often.

All of these more specific design processes follow the basic pattern, as I hope I've shown. The difference between them lies in the techniques used at each stage, the pliancy of the respective mediums, and, of course, the end goals; each process is aimed at producing a different sort of product. Though these differences are significant (I'm not claiming that, when you get right down to it, all design processes are the same), these similarities run through them all to pull out a unified picture of what it means to "design".

And there you have it. Rob's manifesto on the nature of design.

[ Permanent Location ]

The Invisible Designer

design, society & sociology, usability

August 06, 2003, 08:24 PM

Since I first became interested in interface design, one of my favorite sayings has been "The most irritating thing about being an aspiring usability professional is that there is so much need for us out there in the world and so little demand!" Today I found out that Alan Cooper elaborated on this thought better than I have been:

Sometimes being an interaction designer can be so frustrating! If, as a designer, you do something really, fundamentally, blockbuster correct, everybody looks at it and says "Of course! What other way would there be?" This is true even if the client has been staring, empty-handed and idea-free, at the problem for months or even years without a clue about solving the problem. It's also true even if our solution generates millions of dollars for the company. Most really breakthrough conceptual advances are opaque in foresight and transparent in hindsight. It is incredibly hard to see breakthroughs in design. You can be trained and prepared, spend hours studying the problem, and still not see the answer. Then someone else comes along and points out a key insight, and the vision clicks into place with the natural obviousness of the wheel. If you shout the solution from the rooftops, others will say "Of course the wheel is round, what other shape could it possibly be?" This makes it frustratingly hard to show off good design work.

Cooper attributes the problem to this inherent property of design: the "right" design seems obvious once you've arrived at it, but boy is it hell to get there. And I think this is a large part of the problem. Our brains are funny things; neural impulse patterns have to click just right with other neural impulse patterns to produce those breakthrough design ideas, and sometimes it requires intense immersion in data or research, high-energy brainstorming sessions, mapping mental associations to physical objects using a process like affinity diagramming, or a host of other mental exercises to arrive at this "click". But once you have the idea and can describe it to others, they don't have to go through all this strenuous mental activity and thus have the "Duh; it took you that long to come up with this?!" reaction.

But I think this isn't the only barrier. Another big problem usability professionals seem to face is the "everyone's an expert" symptom when it comes to interface design, so it's hard for the designer to sell his skills when non-designers are convinced you don't need special skills to create great results. Interface design is one of those fields that is easy to do badly but hard to do well, and unlike programming, it isn't immediately obvious when a design is bad to those who designed it. This is especially if you don't run user tests, and since this problem crops up most in organizations that are fairly immature with respect to usability, this is likely the case.

But even if the organization is fairly mature, usability still often falls by the wayside because, as Cooper argues, its benefits are often invisible. A well-designed interface may not have immediate, measurable impacts on product sales, may not be demanded by clients (well, they may want the software to be "easy to use", but most don't understand what this entails), and thus may not hit the company in its pocket book. And even if it is impacting sales, this effect is likely to occur only after some delay, as users get frustrated with the product and switch to competitor's offerings. And as we know from systems thinking, we humans are bad at connecting effects to causes when there is a significant delay between them.

So, what's an enterprising young designer to do if he wants to help tackle this problem?

[ Permanent Location ]

Quality, Quantity, Progress, and Design in the World

aesthetics, design, society & sociology

July 29, 2003, 12:51 AM

Once again, CDF has reset itself and we've procured a new teacher. This week its Craig Vogel, an industrial design teacher with a penchant for waxing philosophic on the nature of design and its place in society.

Craig described the design problem as a process of understanding the existing world and then envisioning the world in a new, preferred state. Progress, then, is moving from the first to the second. I've described something similar in my definition of design. Yet people have different definitions of "preferred", as I hinted at in my earlier post. Some argue that modern society's concept of a preferred state of the world, and perhaps even its understanding of the existing state, is short-sighted, misled, or even downright inhumane. Craig mentioned an environmentalist architect (whose name escapes me) who felt this way. I thought of an old roommate back in college, Eric, who passionately believed that architecture and urban planning could be conducted in harmony with the environment, leading to a better world for all, except that society didn't value these things and thus they never entered into these visions for a preferred state of the world. Maybe he's right, maybe we need to develop such a vision. Alexander had lots of ideas along those lines back in the seventies, maybe its time for more people to listen to him.

Next, Craig discussed qualitative versus quantitative methods. He argued that qualitative methods have been deemphasized, when not actually reviled, in modern society. Our society values quantitative methods and skills such as mathematics and "hard" science. Our educational system emphasizes these skills and even defines intelligence (the primary educational value) in terms of these skills, while paying small heed to more qualitative skills like art and design.

So far so good. Personally, I'm very interested in merging quantitative data gathering with qualitative design and decision making, since I strongly believe both have great value for different purposes and both are essential for a healthy society. Along these lines, Craig discussed the cultural divide between engineering and design, which perked up my ears since I see my work on U&SA as one facet of bridging an instance of this divide. However, although Craig preached for bringing the two perspectives together on equal footing, the rest of his talk, I felt, had a definite "design has got it right; engineering is so materialistic!" slant to it. Over dinner, Matt remarked that it seems every area of study he encounters preaches interdisciplinary unity at first, then turns around and argues why their particular discipline is the best and should ultimately be in charge.

All too often, such discussions turn into power games. Perhaps its due to our tribal ancestries, but we humans always seem to want "our people" to be the dominant ones, whether our people are defined by nationality, race, gender, or discipline. Too few of us genuinely see ourselves as truly multidisciplinary, as having a foot firmly planted in two or more such cultures at once. Yet the disciplines must cooperate, and to do so they must see the other's point of view. Sometimes I'm amazed that anything ever gets done...

Craig also discussed the MAYA principle of design, which stands for "Most Advanced Yet Acceptable". A powerful concept, that speaks to the need for progress to proceed in digestable portions. Too many sweeping changes, and you've developed a product, interface, or system that is unusable, aesthetically displeasing, or otherwise rejected by the populace. Sometimes we refer to products and ideas of this ilk as "ahead of their time" (if they're lucky). Which is very visionary and avant-guard and all, but such ideas, almost by definition, never pan out, never make a significant difference. Keeping this principle in mind is especially important for us intuitives, who are always seeing the possibilities of the future and risk losing touch with the here-and-now reality our fellow humans live in. Perhaps here is where the quantitative methods come in.

Craig contrasted the design of two cars, one of which he held up as a better example of design. He mentioned that buyers know there is a problem with the second car but can't necessarily articulate what the problem is. They're likely to say "it just looks ugly" or something similar. This reminds me of the maxim of HCI that "the user is not always right". The designer's job is to define, articulate, and respond to the problems the users "know" are there but can't quite grasp, let alone offer solutions for.

As we talked more and more about these two designs, I couldn't help but feel how ironic it was that, after all that initial high-minded anti-modernity talk, we wound up discussing cars. If ever there was an example of a poor definition of progress, I'd argue its embodied in the automobile. They're dangerous, bad for the environment, expensive (on both the personal and societal level), and yet our society keeps demanding more of them, with more features and better designs. And thus our designers fight with our engineers over how to make the cars pretty and cheap at the same time rather than confronting the larger issues. Do we even need these things at all? Why is the only alternative an overpriced fancy scooter?

Unfortunately, all people, even designers, work within frameworks. Cars are so much a part of the framework of American society that people either take them for granted or dispair at ever improving on them. And no matter how convinced you are that you're discipline should rule the world, you still should recognize that its culture lives within a larger culture that dictates a surprising array of its values in deviously subtle ways.

I guess no one has all the answers, be they engineers, designers, or HCI people. But hey, if there weren't all these important unanswered questions out there, there'd be nothing for people like me to write about.

[ Permanent Location ]

On the Value of Constraints

design, processes & methodologies

July 26, 2003, 11:33 PM

Over the course of this summer session, I've been working on a variety of projects, many of which involve skills I haven't yet developed and concepts I haven't yet fully grasped. During the course of all this, I've experienced a semiprofound revelation.

Despite what you might think, in the majority of cases constraints are a Good Thing™.

By constraints, I mean limitations on our actions, the finite quantities of resources we're given to solve problems, frameworks we are required to work within, etc. A common example is the time constraint; I often complain that I don't have enough time to properly complete an assignment or code, up some software component. I've generally conceived of such things as necessary evils that we must, sadly, deal with and take into account if we wish to get things done. In a perfect world, however, there would be no constraints. We'd have all the time in the world, all the people we need, all the raw materials we could wish for, to come up with the perfect solution.

I've changed my mind, for several reasons. In Communication Design Fundamentals, we've been given a number of different design problems, generally fairly open but with some constraints attached. For example, in the first week we developed a poster for a series of talks and used various typographic attributes (line spacing, stroke weight, etc.) to communicate the hierarchy of information. At first, we were limited to a single typographic "variable", later assignments opened it up to two or three. We quickly found that this freedom made things more difficult (although we certainly came up with better designs with two variables rather than one). Likewise, during Dan's week we started off arranging our quote using only positioning, then we got to play with stroke weights and size variation and whatnot, and sure enough it got harder (and some of the designs started to look "overdone"). Dan told us that in this class he was imposing the constraints on us, but in our work we would have to decide what constraints to impose on ourselves. An interesting proposition. I wonder if the qualities that make a designer (or an artist) great aren't so much "wild creativity" but a form of intelligently constrained creativity that knows where to direct its energy for maximum effectiveness.

This meme even gets reflected in the class itself; I've come to feel that I enjoy the course as much as I do because each professor has been forced to boil down their topic into something that can be taught in fifteen hours. This has lead to a nice mix of hands-on practice, minimal instruction, and a wide (but not stretched) view of the topic area. Great for an introductory course.

Likewise, I've been mucking around with Perl quite a bit lately, a language that is highly unconstrained and suffers as a result. There may be More Than One Way To Do It, but this intimidates novices and makes Perl code notoriously hard to read. As does everything, Perl has its advantages as well as its disadvantages, but a few more constraints may have resulted in a much cleaner design.

In the end, constraints help get things done. To return to the ever-present time constraint: if I was given the infinite time I desired, its likely I'd never finish anything (which happens all too often with personal projects for which I set no goals). In academia, a sector I've become all to familiar with recently, there are often few time constraints for day to day work. Many of the academics I know tend to wander aimlessly or squabble over relatively unimportant details. As a result, high-quality outcomes don't often come from university labs.

Another form of constraint comes in setting goals. In a way, goals are the self-imposed constraints Dan was talking about. Matt argues that every project needs to have a clear set of goals to guide it, otherwise no one will accomplish anything meaningful. Unless you commit to accomplishing measurable objectives within a given time frame, you'll wander aimlessly, wasting your money and your time.

[ Permanent Location ]

Redesigning My Space

aesthetics, design, life & times, personal

July 25, 2003, 04:07 PM

I've moved into a new apartment recently. I moved in two weekends ago and spent last weekend cleaning and redecorating. All my Pittsburgh friends will (hopefully) get to see it in person soon since I hope to have a housewarming party, but in the meantime (and for those who won't be able to attend), here's a few pictures I took.

Street View

Front Porch

Kitchen

Dining Room

Dining Room Wall

Living Room

My Center Of Operations (a.k.a. Desk)

Reading Area

Patio

Backyard

All these pictures are partially to make Micah happy, who has always frowned at me for having too much boring text on this weblog :).

As I was redecorating my apartment I couldn't help but think back to the design process we learned about on the first day of CDF. I went through the familiarization phase while looking for apartments and while moving all my junk, then the development phase when I decided where the major furniture would go, then finally the refinement phase when I positioned all the little things on the shelves and tables and desks. And sure enough, there were "architectural" issues; it would be prohibitively expensive for me to move to a new place just because I didn't like the way my stuff fit into it.

Looks like the basic pattern (along with its consequences) fits to even the most mundane design tasks.

[ Permanent Location ]

Expressive Type, Visual Structure, and Human-Centered Design

aesthetics, design, usability

July 21, 2003, 07:59 PM

This past week in CDF we studied Expressive Typography with Dan Boyarski, head of the School of Design and typographer extraordinaire. Our running assignment was to arrange a quote on a page in a way that expresses its meaning. For the first couple iterations we were constrained to just positioning the text, for the rest we could also change the font size and stroke weight.

First off, I was amazed at how much emotion and meaning you can communicate using only type (no color, no images, and no shapes other than letter-forms). I'd seen typographic presentations before, both static and kinetic (kinetic typography, or videos of moving type, is one of Dan's research interests), but viewing someone else's piece doesn't quite drive home the point as much as actually sitting down and doing one yourself. The sheer number of variables and choices was daunting, to say the least, when the position, size, and weight of every word (or even every letter) necessarily conveys meaning across even small visual differences. And this is just type. When I imagine trying to put together a piece using the full range of colors, shapes, drawings, pictures, time (if the piece is a video), etc. my head starts to swim. Yet from the design perspective, interaction design (what we do to design software systems and other interactive experiences) is all these and more; its like kinetic design minus the strict sense of control the linear flow of a video gives its creator, like a movie where the viewer rather than the director gets to choose the next set of frames to play every few seconds from potentially hundreds of options.

This "design perspective" is a fundamentally different way of thinking about the world. The visual designer learns to give their full attention to how something looks, to its visual representation. Programmers, philosophers, writers, and (usually) interface designers generally think quite differently; to them the underlying ideas are more important than the visual presentation of those ideas. Yet perhaps the visual designers have something here; after all, we know that the appearance of a web site is the most influential factor in determining whether users trust the content. And that's not all it affects.

We humans are visual creatures; sight is our primary sense and thus it is integral to the way we think. In many cases, people can suck in and process a lot more information when they can see it all laid out before them than they can if they have to view bits and pieces in sequence or, even worse, read a linguistic description of it. This jives with some of the studies I've done for Newsable; I found that all of my users were quite adept at visually scanning for interesting content, but they were much worse at describing what they were looking for. Likewise, Dan preached about the need for large walls in project rooms so designers can post their work up for easy comparisons. Visual comparisons of design artifacts are much easier when you can see all the artifacts you're comparing at once.

Another interesting lesson, both for this expressive type week and the more mundane hierarchy week, was how much the visual presentation dictates the structure people ascribe to the content. This is pretty clear when you compare my final version of the first assignment with the raw text; this shouldn't be new to anyone. But it was interesting to see that visual presentation isn't just important for sound information design; it even proved critical for the "fuzzier" quotes. Take a look at my classmate Jennifer's piece and you'll see what I mean; the quiet meditation of her quote comes out clearly in the small size of the text, its position in the bottom corner of the vast whitespace of the page, the natural grouping of the words through line breaks and indentation, etc. (The papyrus piece is © 2003 Jennifer Anderson. All rights reserved. Used with permission.)

This approach to visual design as a communication medium that enhances (or even completely changes) the meaning of the content is very much in line with the philosophies of information design and technical writing that I'm familiar with. So far, the professors we've had have talked a lot about communication and what message our designs are sending to the viewers. I've been impressed by how much attention these expert designers pay to the viewer (dare I say the user?) of the artifacts they produce (or are asking us to produce), because it means their basic values are very much in line with ours over in HCI. Dan even outright said "We believe in human-centered design". Insofar as this holds in practice for both camps, we'll always have a common base we can stand on to collaborate. Most designers don't do user tests, and most usability practitioners don't do critiques, but these are just differences in approach, and both approaches are valuable in their own ways. There seem to be many opportunities for synergy between these two cultures and bringing them together, as we're ostensibly doing here at CMU, is a tremendously good thing.

[ Permanent Location ]

Photography as a Communication Medium

aesthetics, design, writing & communication

July 17, 2003, 11:29 PM

I've been learning lots of interesting things in CDF recently; sadly, since I moved last weekend and lost my broadband internet access at home for a couple weeks, I haven't had time to post about all of them. So this is my best shot at trying to play catch up.

By the end of last week, we'd finished up the photography section of the class that Charlee was teaching. Our final assignment was to combine a photograph with text to create some communication piece (Charlee likes wide-open assignments). I did a public service announcement poster type message, which I thought turned out okay, although several other people in the class put together some things that were much better, in my opinion. It was amazing to see how good everyone's was after only a week of practice and critiques.

For mine, I actually started the project intending to communicate a different message. I wanted to take a picture of an interesting but run-down street and compare it with a quote from the philosopher of art Jerome Stolnitz about the aesthetic attitude that inspired me to write Aesthetic Mornings a few years ago. But I couldn't find the right subject or the full quote, so I wound up wandering around East Liberty (a relatively poor neighborhood here in northeastern Pittsburgh) for a couple hours taking pictures of various subjects, including this bottle. At first, I wasn't too fond of any of them, but after returning home and looking at it on my screen, I decided the bottle picture wasn't too shabby, especially in black and white. But I had no idea what text to put with it. I tried a number of semi-depressing captions (I was in that kind of mood at the time) but none seemed to fit. Then I hit on "Just Another Broken Window" (a reference, possibly too obscure, to the "zero tolerance" program adopted by New Jersey in the 70s), which I thought was neat especially since the visual presentation allows you to read it as "Just Broken Another Window" as well. And so it became a public service announcement, although I couldn't quite bring myself to turn it into a just a "pick up litter" message (it seemed too trivial for the weight of the photo), so I tried to work in a larger social message as well.

I guess the point of all this rambling is that the design process is messy. Sometimes it's hard to know ahead of time exactly what you're going to wind up with, and walking into it with too precise of an idea may just end up wasting you time or (even worse) leading you away from good alternative ideas.

On a bit of a tangent, while we were doing the crit (design critique session where everyone comments on everyone else's work and suggests improvements) for this assignment we got into a discussion of how photography can be used to evoke emotions and suggest certain responses to subjects, especially when combined with text. Andy remarked that it was amazing how easy it was to misrepresent a situation you are photographing, even though you're supposedly taking a completely accurate image of the real world. There are many design variables available to the photographer, the greatest of which is the shutter itself, the box around the world through which the viewer must look. Photographers can decide what portions of the truth to show their viewers and (sometimes quite literally) what light to present them in. Thus, it is just as possible for the photographer to introduce his interpretation of reality into his work as it is for a writer or a painter to introduce theirs. But in a way this is obvious to anyone who knows anything about journalism. The interesting (sometimes dangerous) fact about photography is that it seems so real; it looks as though it is a completely accurate, objective presentation of the world. I have a suspicion that most people don't think through all this when they see a photograph; they don't ask what "spin" the photographer was trying to put on his subject as they might ask about a prose article or a painting. This makes photography a powerful medium for communication and persuasion, both of true propositions and untrue ones. It's worth thinking about the next time you're reading the morning paper.

[ Permanent Location ]

The Design Process

design, processes & methodologies, teaching & learning

June 30, 2003, 04:11 PM

Today was my first day of Communication Design Fundamentals (CDF), the prerequisite studio-based design course for the HCI program here at CMU. We started off the course with an exercise in the design process where the teacher, Karen, gave us a pile of semirandom household implements and asked us to arrange them into an ordering so that someone who walked in the door could understand just by looking at them how they all related to each other. Apparently this is a common exercise for introducing students to the design process.

The design process Karen described goes like this:

1. Familiarization, where you work on understanding the domain and what the general relationships between objects in that domain are. For us, this involved figuring out what each implement does (difficult, since there were some weird items. No one got the Fijian cannibal's fork...) and grouping them into some general functional categories.
2. Development, where you start to define the general structures and groupings. We divided the "kitchen items" and "art items" into separate areas, organized the kitchen items into a circle and the art items into a grid, and divided into two teams to manage the arrangement of each.
3. Refinement, where you start to focus on the nitty-gritty details of the design. This is where we separated out the various piles of items we made into groups separated by whitespace and aggregated by function or appearance.

It struck me as we were going through all this how similiar it was to other design processes I'm familiar with, like the HCI user interface design process and the software system design process. In HCI, you start by studying your users and trying to understand their needs, their desires, their tasks, and their gripes, which is part of familiarizing yourself with the domain. My persona development process for open source software is an example of a technique used at this stage. Next you design the high-level information architecture and rough screen designs for the application, which is equivalent to the development stage. Finally you build higher-fidelity mockups that you can actually run user tests and analytical checks on, the HCI version of the refinement stage. In software development, you frequently familiarize yourself with the technologies (although this stage is often skipped, to the detriment of many projects), develop a high-level architectural design, and then refine this design into detailed class hierarchies and object interactions and finally down to actual source code. And as Karen pointed out for the design process, at each step you frequently must move to the next step to see if your design ideas will work or not. A strict "waterfall" approach to the design problem rarely works.

When we got to organizing the structure of our designs, one group had put items into a basic circular structure, the other had used a grid. Karen pointed out how design decisions such as these can determine the structure of your later decisions. Her off-the-cuff analogy described this as similar to cutting a pie; the first cut you make determines the positioning of all the future cuts. So when you make those early decisions, you need to make sure are careful and have your audience's needs in mind. This is quite similiar to the classic software architecture problem; the architecture of a software system encompasses those decisions made early on that determine what is easy to change and what is difficult. Its interesting to reflect on how much these apparently different design processes have in common.

As we were progressing through this exercise, Matt remarked that this was an example of experiential learning; Karen gave us a specific problem to work on first, then helped us generalize our experience to all of design. She didn't lecture per se, instead she interjected comments and suggestions as they we needed them to help solve the example problem. It was a neat approach; I'm excited about teaching in this style with Matt for our TCinC summer course, which starts tomorrow.

This session is shaping up to be a lot of work, but it looks like it will be interesting work and thus bearable. It's also great to hang with my fellow part-time HCI students who are all in CDF with me (sans Mathilde). I even get to see Neema again regularly, which is a rare treat. Good times all around.

[ Permanent Location ]

Anatomy of a News Aggregator

design, internet, patterns, software development

June 28, 2003, 05:44 PM

For the past couple of days, I've been working on the interface and architectural design for Newsable. Since I am a strong believer in the claim that the design decisions that determine whether an application is usable are not purely screen deep, but may reach far into the application's architecture, I wanted to get a rough idea of the interface design and information architecture of the application before deciding on the core components and patterns of the internal design and how they will interact. That said, I don't yet have digital copies of the screen designs, so I can't easily post them. Once I get some prototypes together I'll put them up along with a justification for my design decisions.

So on to the architecture. Newsable is divided into two parts, the Harvester (whom I'm code-naming "Cain") and the Publisher (whom I'm code-naming "Able"). This reflects the two main functions of a news aggregator; it must collect news stories from several potentially disparate sources and pull them all together into one location. Then it must catalog and organize these stories and, most importantly, provide an interface so the user can peruse them in the ways that are natural for her. And thus we have developed Newsable's core metaphor: Newsable is a gatherer who searches the various news sources looking for new stories, a librarian who catalogues these stories and manages their metadata, and finally a publisher that arranges this information into a form that is presentable to the reader.

First, we'll examine Newsable's preliminary object model. The details of this diagram are likely to change frequently, but it's worth examining now to take a look at the key terminology and metaphors in Newsable:

Newsable works with any number of users subscribing to any number of sources. A "source" is a single news producer. Note that a website may have multiple sources. Usually, a source will be a feed, but Newsable supports providing "alerts" to users that a web page has been updated since they last visited it in case the website doesn't yet publish their content in RSS. The content Newsable extracts from sources is "stories". A story is usually a news item, an article, a weblog entry, etc., but it may include stuff like weather reports, stock quotes, etc. So "story" may not be an entirely accurate term, but since most stories published through RSS really are stories I felt this was currently the best choice of terms.

Next, we'll take a look at Cain, Newsable's Harvester:

Here's Cain's basic algorithm:

1. Cain is triggered by the operating system's command scheduler; since The Labs is running Linux, this would be cron. I may add a means for the user to trigger Cain to run on the subset of feeds she is subscribed to, this means Able will have to have a way to send events to Cain, but this won't exist in version 0.1.
2. The scheduler triggers the Gatherer, which reads the list of feeds Newsable is currently subscribed to from the MySQL database (the database is wrapped in a Data Abstraction component that hides the details of the underlying SQL data source and performs object-relational mapping) and checks each feed to see if it has updated since the Gatherer last visited it (using a HTTP HEAD). If it has, the Gatherer fetches the feed content with GET, otherwise it ignores the feed.
3. Once it has all the new feed content, the Gatherer sends the list to the Librarian.
4. The Librarian is responsible for comparing the information in the feeds with the information in the database and updating as appropriate. But the Librarian can't read RSS itself, so it sends the feeds to the RSS Parser module.
5. The RSS Parser first attempts to determine the format of the feed (RSS 0.91, RSS 1.0, or RSS 2.0, or a broken variation of these. "Broken" means the feed is not well-formed XML. The "Broken" parsers will do their best to extract content anyway, probably using some horrendous kludge involving regular expressions. These probably won't exist in version 0.1). The RSS Parser then internally loads the appropriate specialized parser to extract the content from the feed, which it returns to the Librarian.
6. The Librarian checks the database to see which stories are new and which already exist. It adds the new stories and updates the feeds' last updated times.

I plan to extend the Gatherer to honor the "skip" elements in RSS feeds that indicate how long a harvester should wait until re-harvesting the feed. Moreover, there is a publish-subscribe mechanism built into RSS which I believe is intended to allow clients to request that the server send them updates as soon as they are posted. I don't think this is widely implemented, however. If I discover this is possible, then I'll add another component to register and listen for these events to allow Newsable to update itself immediately when new content appears in its feeds.

And that's Cain in a nutshell.

Finally we'll examine Able, Newsable's Publisher.

Able is more event-driven than Cain, so it's a bit harder to give an algorithmic explanation for. Able follows the Model-View-Controller pattern. The Controller is played by the Input Processor Script, a CGI script that interprets the HTTP GET and/or POST parameters, determines the operation the user wishes to perform, then calls the appropriate method on the Command Processor component, which collaborates with Newsable's data source to play the part of the Model. When the Command Processor has finished its computations, it returns its results to the Input Processor Script which selects an Output Template, playing the part of the View, to display these results in.

Much more remains to be said about Able, but the details of its design are likely to change as the needs identified by the personas evolve, so I'll leave it at that for now.

And there you have it. The guts of an up-and-coming news aggregator laid bare.

[ Permanent Location ]

Designing Against Frivolity

design, society & sociology

June 17, 2003, 07:51 PM

I happened to hop over to Slashdot today and found a nice polemic over on the Guardian about how frivolous technologies are dominating the market nowdays. The article is full of derisive, quasi-luddite quotes, like The Innovations catalogue exists as proof that there are people with less perception than a wrapped loaf who are inventing things; and more, even dimmer, who are prepared to buy them and So the fatuous becomes the essential, and we become more decadent, more hungry for diversion and suckered into buying things that will improve our lives negligibly, if at all, but it raises what I think are some real issues. Most consumer technology nowadays are fairly frivolous, which isn't to say some people aren't working on important scientific and technological advances, it's just that the market is dominated by video phones and other gadgets that are cool for a little while, but ultimately serve no meaningful purpose. But the reason these things keep getting produced is people eat it up.

Personally, I avoid spending money on impulse purchases. I find gadgets like the ones on ThinkGeek as cool as the next nerd, but every time my Id screams "I've got to have this!!" my Superego replies "Yeah, for maybe five minutes. After the novelty of owning a portable lie detector wears off, it will just lie around your apartment and take up space". When I do purchase gadgets, it tends to be in response to some need I've been experiencing for awhile. I didn't purchase my current computer until it was clear my last one wasn't hacking it performance-wise (Netscape took around a minute and a half to get going). I've never owned a cell phone or a PDA even though they've been available for years, but for the past several months I've been having problems remembering meetings, birthdays, etc., and I've been in several situations where I needed to reach or be reached by someone while I was out and about. So I've finally been thinking of getting a phone/pda combo like the Sidekick.

Unfortunately, many people don't seem to be very good at assessing their real needs and distinguishing these from mere passing fancies. Thus, the market is bloated with products that seem glamorous but improve people's lives only marginally if at all. The solution, of course, is to help educate people in how to assess these needs and work to change society to favor long-term improvements in quality of life to short term instant gratification. This isn't to say I don't believe in the importance of designing pleasurable products, I do. But I think there's a difference between products that truly make your life more pleasurable to live and those that serve as temporary curiosities, then just get in the way.

Perhaps, in the short term, designers can help by working for those companies that are producing products that genuinely improve people's quality of life, such as the wind-up radio mentioned in the Guardian article, even if this means working for less pay. In my view, the pay cut would be worth it to know I'm really contributing to the betterment of humanity, and not just pumping out the next fad.

[ Permanent Location ]

Natural Programming and Expanding Open Source

design, software development, usability

June 15, 2003, 11:48 AM

Sometimes when I come across something I want to write a weblog entry about but I don't have time to put together the full writeup (these things can take over an hour) I instead jot down a quasi-outline of the post so I can come back to it later. I have a couple of these kicking around right now and I wanted to get them off the table. This one comes from the same discussion with Jim about open source and usability that the efficient interfaces post originated from.

Jim brought up "natural programming" (programming environments designed to be so easy to use that ordinary users can program, if only in a limited domain) as a holy grail of open source usability. If everyday users can program, the reasoning goes, then users can design their own interfaces and feed those designs back into the development base, just as open-source developers do now. This comes from Eric von Hippel’s argument in "The Sources of Innovation" that most innovations come from end-users, not manufacturers. I balked at this, however. In HCI, its commonly accepted that its unwise for an interface designer to take all user suggestions at face value. Users are not designers; they are good at finding problems with the interface, but they tend to come up with point solutions and workarounds that fix these problems in the small but which, overall, contribute to a bloated, unusable, inefficient interface. This is why providing highly customizable interfaces doesn’t solve the usability problem. In "Usability Engineering", Nielsen quotes a study that compared user performance with two interfaces: one was designed by an experienced interface designer, the second the user was allowed to customize in any way he wanted. The study found that users were much more efficient at their tasks with the interface designed by the expert than the one they customized.

On the other hand, as I discussed in my efficient interfaces post, when you have a situation like in open source where the users (the programmers) really are the designers, sometimes superior designs do come out of users’ heads, at least with respect to certain usability goals like expert efficiency. This is certainly in line with the "eat your own dog food" maxim of software development. On the other other hand, many complaints about open source software center around the observation that most of the popular open source interfaces are copied and altered versions of existing commercial tools, rather than truly innovative designs (KDE and Gnome look a lot like Windows, Gaim is pretty similar to AIM, Linux is basically a reimplementation of AT&T’s Unix). Right now, open source interfaces are good at copying commercial interfaces, making them free, and streamlining them (to a certain extent), but not much else as far as usability is concerned.

So would natural programming help to bring users into open source and produce better interfaces, or do expert designers have to participate more to bring their unique knowledge and experience to the table? For my open source and usability project, I’m moving more towards the expert designer route, although I’m still very interested in investigating what the best way to bring average users into the community is. After all, it’s worth remembering that the study Nielsen refers to only measured how productive users were with the interfaces they designed. Historically, usability has been applied to the design of productivity applications almost exclusively. But not all software is for productivity, many software products aim to provide the user with an enjoyable or desirable experience, as Don Norman discussed at CHI. Perhaps interfaces of this variety would benefit from natural programming and high user customizability. After all, if users alter the interface to their tastes, perhaps we can assume they like it better that way. Hopefully the emotion and design people will do some studies looking for correlations between the amount of control a user can exercise over the interface design and the interface's desirability for the user.

In the short term, however, I'm not certain that natural programming is the way to go to solve the open source and usability problem. More on the approach I do plan to take should be coming soon.

[ Permanent Location ]

The Users We'll Never See

design, information, society & sociology, usability

June 03, 2003, 05:10 PM

About an hour ago, I felt a need to feed my Chipwich addiction, so I invited Kerry to go to Entropy with me. On the way back, she needed to stop by the Hub to get some registration and class scheduling issues worked out. Since I had nothing imminently pressing to do, I waited for her.

While sitting in the Hub waiting area, surrounded by brochures, magazines, important-looking forms, computers, and the various other trappings of a functioning administrative center, I started to reflect on how much information was out there in the world, and how much of it had to be dealt with. That's the thing about information; it always seems to need processing and organizing and analyzing and basically loads and loads of attention. Information can be rather childish in that sense.

I was reminded of Herb Simon's quote: "In the future, the scarce resource will be human attention". I reflected for a bit about how right he was.

But wait a minute, a little voice in my head remarked. Exactly how right was he? Sure the information-overload problem is a big deal for people at CMU, and probably is for information workers everywhere. But is everyone like us?

My father owns a house in rural West Virginia (Monroe County, for those of you familiar with the area). Life's quite different out there. People aren't so busy, for one thing; they don't appear to be so bothered by all this information. The information is there; there are construction projects and farm vehicles and weather patterns and plant DNA (scads of information lies in the DNA of even a simple organism) and who knows what else. But this information doesn't seem to be so concerned with getting your attention. It could care less about being processed.

My point is not that this "simple" life is ideal or perfect; it isn't. My point is not even that it's better; "better" is a matter of opinion and generally doesn't mean much in any absolute sense. Hell, I happen to like city life; I wouldn't move to the country if I was given a million bucks to do it. Rather, my point is that old Herb was not thinking about these people when he made up that quote. And how could he? He was here at CMU, where everyone is information-overloaded. Of course he saw the future in those terms; he was extrapolating from the present, just as any rational person would.

As human beings, our conceptions of the world and its problems are necessarily a product of where we are situated in society, both physically and status-wise, and who we choose to associate with. Dan Sieworek, Scott Hudson, and many other researchers here at CMU, are taking Herb's quote seriously with projects like Aura and Situationally-Appropriate Interaction to try to solve this information-attention problem of the future. But whose problem is this, really? It's their own problem, ultimately, and the problem of the people they associate with and the people who fund them.

As user-centered designers, we can only design based on our conceptions of the world. We can only perceive and design for the slice of reality we find ourselves in, and for most of us, this slice is quite limited.

Around this point, I was interrupted from my meditations by the secretaries loud discussion about whether picture files are supposed to end in ".jpg" or ".jpeg". They spent a good five minutes trying to figure out the correct answer (of course, both extensions will work fine for most modern programs). I smiled. File extensions are one of those known usability problems that no one can get seem to rid of. Usability advocates routinely complain about how design decisions such as this one are made by programmers who don't understand the mentality of the users they are designing for. But in the large scale, in the "redesign society" sense that researchers and the upper echelons of industry and government confront daily, does anyone really know who they are designing for? Does even the most skilled user-centered designer have any meaningful grasp on who the users are when the user base includes the population of entire countries (or the entire planet)? In this scenario, even we user-centered designers may be no better than the archetypal isolated programmer in a cubical we so frequently revile.

Sometimes I wonder if at least a subset of the designers of the world need to step out of their bounds sometimes. Some of us should go out into the world to observe the people whose lifestyles and values clash with the ones we are familiar with. Perhaps this would help us get a larger view of the world we are so eager to change, essential if we are to do more good than harm.

This idea has some background in design research; last semester we read a paper from DIS 2000 that advocated designing for "extreme characters" as an exercise to help break out of the mould of the existing interface design frameworks. But this is just a thought experiment; the extreme characters described in the paper are (by admission) caricatures of real people. A designer can't truly know what the elements of society outside his spheres of experience are like without seeing them for himself.

Now if we really were able to see the people of the world, the "end-users" of our world-changing visions, as who they are, and not just who we assume them to be, well, how mind-blowing would that be?

[ Permanent Location ]

Comparing Complexities: Interface Designs and Code

design, software development, usability

May 30, 2003, 11:21 AM

I was reading Jacob Nielsen's Alertbox yesterday, and noticed he made an analogy I've frequently used myself; he compared interface design to software development to demonstrate the folly in assuming that good designers shouldn't have to user test their interfaces. The argument goes that you wouldn't make the claim that "good software developers should be able to write perfect code on the first try, so why should they have to waste time writing and running tests", would you? Interface design is just as complicated as software development, so why would you assume good interface designers should be able to pull perfect interfaces out of their butts without testing and iterating on the design?

This got me thinking about whether it would be possible to make this argument stronger by semi-objectively comparing interface design complexity with code complexity. Obviously the standard code-complexity metrics (lines of code, function points, etc.) don't apply to interfaces. But what we really want to measure here is "how many things could you potentially screw up?", i.e., could fail in testing. I'll call these things "complexity points" for lack of a better term.

For code, an example of complexity points in a function might be "null pointer passed in and dereferenced" or "array accessed out of bounds", basically, any state that would violate the preconditions, post conditions, or invariants if you were using Design by Contract. For interface design, example complexity points might be violations of Nielsen's heuristics, failures in a Cognitive Walkthrough (interface elements that aren't visible, labels that don't describe the function, etc.) or potential violations of a Think-Aloud critical incident. Obviously no objective procedure could hope to turn up all the complexity points either in source code or interface designs (it'd be great for humanity if we could, although all the software developers and interface designers in the world would get replaced by computers), but perhaps there is some way of approximating the complexity point count for interfaces and source code for the sake of making a rough argument.

As a side note, I'd read Jacob's column more often if he had an RSS feed...

[ Permanent Location ]

Prescriptive Interfaces Explained

design, processes & methodologies, usability

May 27, 2003, 02:16 PM

A couple days ago I mentioned that I was interested in "normative interfaces" as part of the single-sourcing paradigm idea. I've thought it through some more and decided I liked "Prescriptive Interfaces" better as a monkier (best practices frequently aren't very normative since they're often not the norm...) and that I'd like to expand on some of the points I made in that post.

In a way, the term "prescriptive interface" is a tautology; all interfaces are technically prescriptive since they necessarily predefine some method of interaction with the system. The interface defines what commands the system understands and what form it can present information in, and thus any interface dictates some method or range of methods the user must use to perform their tasks and accomplish their goals. Techniques like CI/CD help us design interfaces that prescribe methods of interaction the user is already familiar with through their existing work, while improving on the existing methods by fixing the breakdowns identified by the design team.

The interesting question, however, is how do we design interfaces that encourage users to work in the smartest way possible, as defined by the techniques developed by long-time experts in the field who have applied them successfully in many different situations. In the software engineering world, these are known as "best practices". One best practice in software development is unit testing your code. One best practice in technical writing is writing an outline before starting the document, as I mentioned before. One best practice in HCI is low-fi prototyping your interfaces to elicit real user test data as early as possible.

A prescriptive interface, then, is an interface designed to encourage the use of best practices, to make it easy (or at least easier) to solve the problem in the "right" way. One example of an interface that did this well is the original Apple GUI toolkit. At the time, there were no high-level GUI toolkits available so programmers wrote the code to implement all their own widgets, thus the buttons, text boxes, menus, etc. in every application looked different, which proved confusingly inconsistent to the user. Apple's genius was in providing a toolkit that not only enforced a consistent look and feel on their platform, but actually made the application programmer's job easier as well. This encouraged programmers to use Apple's toolkit instead of rolling their own, and thus Apple wound up with a remarkably consistent-looking and usable platform for the day. An example of an interface design that does this poorly is Microsoft Word's styles support. Writing a document using styles is hard; the user must first know that styles exist and what they are for, then must go into the styles dialog to edit these styles to make them look the way they want, consistently apply them where they are appropriate, etc. The interface makes it much easier to just hit the "Bold" button up in the toolbar to define a heading than to try to do it with styles.

Ideally, prescriptive interfaces should make it easier to solve problems the right way than it is to solve them the wrong way. Failing that, they should try to make the right way as convenient as possible, and may even consciously make the wrong way just a little bit more difficult. If done right, this approach has potential benefits for both novice and expert users. The interface helps novices learn the best practice approaches to solving their problems in the context of doing their work, which is much more effective than formal training. The interface helps experts by making the best practices they already know much easier to follow; even though I know styles are an overall better approach I frequently don't use them in Word simply because it's such a pain in the butt.

So now that you're convinced that prescriptive interfaces are a good idea (I hope), the question becomes, "How do we design these things?" Here's my thoughts on a rough process:

1. Identify the best practice approach to solving the problem. This may require reviewing relevant academic or trade literature in the domain, but I would guess that the most important practice would be to ensure you have one or more domain experts on the design team who have experience applying the best practices and can advise your design accordingly.
2. Research how users currently solve the problem in their day to day work by using a requirements collection method like Contextual Inquiry. Merely understanding how users ought to work is useless if you don't understand how they really do work and why.
3. Design your interface to define clear transitions and adaptations between how users currently work and the best practice solutions. The interface may need to have a sizable teaching component; collaboration with the learning technologies people may help with this part. Unfortunately I don't have much more guidance to provide here; this is definitely the hard and unexplored part of this technique.
4. Allow users to circumvent your best practice processes, but discourage this as much as possible. Be mindful that your ideal solutions may not fit all situations, but make sure the users don't decide to deviate from the best practices idly.
5. As always, do lots of user testing to make sure it works! Testing is particularly important when you're trying to impose a new way of working. Your assumptions will probably be wrong at first; they'll need to be tested and refined even more than normal interface designs before the concepts are nailed down. Low fidelity testing is probably particularly important since drastic changes in the design may be necessary to fix the breakdowns.

So those are my thoughts as they stand. In conclusion, the goal of prescriptive interface design is to produce products that afford best practices within their domain just as they afford proper use of themselves. A good prescriptive interface builds the experience of experts into the system itself so that even novices can experience that benefits of expert-level productivity "out of the box".

[ Permanent Location ]

Single-Sourcing, Outliners, and Normative Interfaces

design, processes & methodologies, usability

May 25, 2003, 09:18 PM

I've posted before about the single source paradigm and the separation of presentation from semantic content. I've been working with Word's outline mode a lot recently and have started to see how using an inherently structural view like an outline to edit content could be the key to providing a usable presentation-agnostic content management system like I described before.

When you create an outline for a document, a presentation, etc. you are basically considering only the structural and semantic aspects of the work. Your purpose is just to lay out the content and get a sense of how your thoughts decompose into supporting points, how your arguments fit together, etc. After you've finalized the outline, you'll worry about making sure the document flows well and looks good by defining the appearance of headings, putting in figures and messing around with how the text flows around them, changing the pagination, etc.

The important part about this process is that the entire time you're focused only on the structure of the work, deferring the definition of the presentation until later. And this is an example of a natural human workflow that people engaged in long before they had computers, so it makes a nice metaphor for the computer-supported single-content paradigm. So the question becomes, can we design interfaces that build on this metaphor to encourage semantic definition of documents, rather than only providing a WYSIWYG style interface that encourages tying content to presentation? And can this metaphor be extended even to such vastly different presentation decisions like whether to publish a printable document, a web page, or a slideshow presentation?

When I brought this up to Micah, he mentioned that Dave Winer, the creator of Radio Userland, has been interested in outliners and the single-source paradigm for years. I'll have to set aside some time to read Scripting.com to see what his thoughts on the subject are.

This whole concept ties into another area I'm interested in; how do we as software designers develop interfaces that encourage our users to follow predefined best practices? Basically, the idea is that certain workflows can be inherently more productive than others, but users may be following a less-than-optimal work flow in their current practice. For example, most technical writers agree that creating outlines before working on a final document produces better-structured prose than just sitting down and writing (I even try to sketch out "mini-outlines" when I toss together these weblog entries). But many users of Word don't do this; they just sit down and start typing. How can we encourage people to follow the superior practice by making it easier than the alternative? In essence, how can we design "normative interfaces"?

Most HCI techniques help us get at the ways our users think and determine what would be intuitive for them, but don't help us design interfaces that help teach users a better way of working. Solving this problem may prove to be an important component of getting people to think structurally so the full benefits of the content-presentation separation paradigm can be realized.

[ Permanent Location ]

Threads of Thinking

design, information, internet

May 24, 2003, 01:21 PM

One beef I've had with the generally excellent Movable Type engine that I use to maintain this here weblog is that it doesn't have any convenient way to connect posts that are continuing the same basic topic thread. You can categorize posts to organize them by topic, but most posts, although nominally on the same topic, discuss completely different things. What I need is a way to get an overall picture of an entire rolling thought process that I've posted about. This need also arose in the Weblogs Informal SIG at CHI last month.

Right now, I do this by posting links to related previous posts in the text of the weblog entry (like I just did in the previous sentence). This works reasonably well, but it would be nice to have a convenient way of seeing the entire topic thread in one glance. So in a future iteration of this weblog, I'm thinking of adding a sidebar to the individual entry template like the following:

The "Looking Forward" posts are future posts that reference this post. The "Looking Behind" posts are just the collection of links to previous posts that appear in this posts. I'm hoping this will help make it more clear which posts are connected to this one and afford reading entire threads of thought at once.

[ Permanent Location ]

A Cost-Effective Problem Reporting System

design, systems

May 22, 2003, 01:55 PM

Earlier today I was in one of the CMU bathrooms near where I work and I noticed that one of the urinals was continuously flushing. I thought of contacting facilities to report the problem, but I was busy, I have no idea what the number for facilities is, and I was suffering from the "Somebody Else's Problem" effect.

Later on, I was thinking that a problem reporting system to fix this breakdown would be pretty easy to implement, especially since CMU has a campus-wide wireless network (which seems to be spreading; one day in the not-to-distant future wireless may be near-ubiquitous). All it would require is a small embedded device with a single "big red button" interface that could be placed in areas where equipment frequently breaks down, people need assistance, or some other situtation where one person needs to notify a geographically distant person that a problem has occurred in the area. When someone pushes the device's button, it uses an embedded wireless card to send a notification over the network to a central server that processes the notifications and routes them to the people in charge of maintenance for the area so they can quickly respond. See the diagram below.

I can think of several extensions to the system to customize it to particular situations, such as adding the ability for the problem reporter to leave a quick voice message describing the problem as they hold down the button to give more context, or a fingerprint-recognition system on the button to identify the problem reporter so the support person can contact them for more information or discourage pranksters from pushing the button as a joke. But in its simplest form, this system solves a practical problem, is easy for support people to maintain, and is cheap to implement if the wireless infrastructure already exists (I can't imagine the problem button devices would be difficult to mass produce; they seem pretty simple to me).

Someone should further develop this idea and market it. I have to start making friends with some business students.

[ Permanent Location ]

Filtering Feeds to Free Up Focus

design, information, internet

May 09, 2003, 09:52 AM

Micah mentioned to me yesterday that he has been having problems recently with the volume of content he subscribes to with his news aggregator. He says it is getting to the point where catching up on his online reading is a multiple-hour engagement and is starting to take up too much of his time. At least judging from the "in the near future, the scarce resource will be human attention" meme that's running through HCI research circles, this is likely a problem for many and will only get worse.

Micah was thinking of adding a "priority" to posts, where I, as the author, can tag each entry in the RSS feed with how important I think it is. Then Micah, as the reader, can tell his news aggregator something like "Don't show me any posts from Rob, unless they're of High importance or greater".

After thinking about this, I'm not sure how well it would work, however, for two reasons. One is that I can only encode how important I think the post is to me; I don't know how important my readers will think it is. Worse, for most posts I imagine every reader would have a different opinion of its importance based on their interests.

I mentioned using categories to divide up content into topic areas, then provide separate RSS feeds for each category so my readers can only subscribe to the categories they are interested in. Movable Type can probably already support this. But this isn't really an optimal solution either, since my categorization scheme may not be the scheme my readers want, I may not be consistent with my assignment of categories, etc.

So here's my suggestion: what if news aggregators allowed you to have a set of feeds you subscribed to just as they do now, and then a different set of feeds you "monitored"? You could specify certain search keywords or other criteria that must appear in the feed's content in order for it to appear in your list. This way your aggregator could automate some of the weblog filtering process for you so your valuable attention could be directed to more important tasks, like reading the posts you're interested in. Additionally, this may have the side benefit of encouraging sites to syndicate all of their content, rather than just excerpts, in the hopes that the full content will match more people's filter criteria than just the partial content.

Just an idea.

[ Permanent Location ]

A Note on XML and Single Sourcing

design, information, software development, usability

May 09, 2003, 01:29 AM

In reference to my post a few days ago on a single sourcing paradigm for research content management, Dave asked why I didn't mention XML as a solution to the semantic content / presentation separation problem. That's a good question and raises a point I want to clarify.

XML provides a technical solution to the single sourcing problem by allowing people to define markup languages specifically for semantic content and markup languages for presentation specifications (XHTML, CSS, SVG, etc.) and a means of translating between them given some content-to-presentation mapping rules (XSLT). This is a fairly neat answer for the technical problem, but isn't very intrinsically interesting since there have been other technologies that have purported to solve this same problem before. XML is really only interesting because it has broad industry support and thus has a chance of catching on and lasting.

The interesting and difficult problem that I discussed in my post was the interface problem: the "how do you build an interface that lets the user define semantic content and presentation of that content separately, yet still provides a metaphor that makes sense to the average user?" problem. The difficulty is that we don't think in terms of semantics, we think in terms of how things look. Headings in documents are headings because they are in big bold sans-serif fonts. So when we are starting a new section and want to make a heading for it, our first impulse is to type some text, then change it to a big, bold, sans-serif font. If the program instead requires us to highlight the text and click on "make this a heading 3" then go into a bunch of dialog boxes to say "oh and by the way, heading 3s in this document will be in a big, bold, sans-serif font" then I guarantee people won't use it. This is why so few people use styles in Word, despite their many benefits; they break the WYSIWYG paradigm that fits so well with their tasks. And what if the user underlines the third heading in the document? Should the style change, hence underlining all headings in the document? Should just that heading change, creating a new, local style? And so on. I found an excellent article awhile back that expands on the ambiguity of styling nicely.

It's a hard problem, but one that I think could be solved much more neatly than any interface I've seen (Word's styles and Dreamweaver's CSS support both spring to mind as bad examples). And that's what XML doesn't do for us, and what I was driving at in my post.

[ Permanent Location ]

Defining "Design"

design, language, philosophy

April 29, 2003, 11:53 PM

I was ruminating on the nature of design last night: what design is, what it means to design something, what the place of design in the world is, and so forth. I've especially been pondering the question of to what extent I'm a designer; on the one hand I've always felt that design was a very "artsy" notion that was mysterious to a not-very-artsy person such as myself. On the other hand, I've been called a software designer for awhile, and I've always had a suspicion that "design" ran through much more of what I do than just that; perhaps through almost everything I do. So I dreamed up the following definition that seems to work well for me, and I thought I'd share.

Design is: "a deliberate action prompted by an understanding of the state of the world intended to transform the world into an improved state."

Allow me to now dissect this definition in excruciatingly painful pedantic detail.

"a deliberate action" - This phrase says two things. First off, design to me is a verb, not a noun; it is something we do. Although you can also speak of "a design", this strikes me as a derivative sense of the term. "A design" is just something that has been designed; it has no meaning except in its relation to the verb sense since two arbitrary things that are called "designs" may have nothing in common except that they were both designed. Thus I consider design proper to be an act, not a thing. Secondly, this phrase says design must be intentional; only conscious beings can design and they cannot design by accident.

"prompted by an understanding of the state of the world" - This phrase also says two things. By saying "prompted" I'm implying that design has a source, you don't decide to design "out of the blue". And that source, according to the rest of the phrase, involves some conception of the way the world works. Thus, all design is performed in the context of some kind of framework, the "understanding" you have about the world. This doesn't imply, of course, that your understanding is correct; lots of design gets done based on completely wrong understandings. So in a sense, the main point here is that you will start your design with initial preconceptions, the only question is how accurate these preconceptions are.

"intended to transform the world" - Design is an inherently normative action. By designing you are changing the world, moving it in a direction it otherwise would not have gone. Thus you are going against the current, and, as "intended" implies, you may not succeed in the ways you thought. Whenever you try to transform the world, you're taking a gamble that the world won't outsmart you.

"into an improved state." - Improved state according to whom? Well, the designer of course. This final phrase inserts something tricky into our definition since different people will probably have different notions of what an "improved state of the world" is. Yet rational designers will act to bring about their own conception of "improved", which is worth keeping in mind if you're hiring one to help design something for you. In a sense there is no designing for someone else; the designer ultimately works only for herself and her visions of improving the world.

Currently, I think this definition neatly captures all the factors of the "design" concept that I find critical. But I admit I haven't read much by people who've thought about this at a much deeper level than I have. Comments and suggestions are very welcome as always.

[ Permanent Location ]

Show Me All My Options

design, usability

April 27, 2003, 01:17 AM

Many interfaces give their users a great deal of control over the appearance and behavior of the application. Unfortunately, the means for exercising this control are usually hidden away in obscure preferences dialogs or even worse (horror among horrors!) configuration files written using some obscure, usually nonstandard syntax. To help fix this, I'd like to propose a new user-interface design principle for consideration. Here it is: "Keep configuration options close to the things they configure."

A classic example of this principle in action is the ubiquitous (and often overused) "Don't show me this again" dialog box. Here's one from IE/Mac:

This design is good because if the user doesn't want to be bothered by messages such as this one again, he can simply click the check box that is right there in front of him. He doesn't have to go figure out where in IE's voluminous configuration dialogs the relevant preference to disable these messages appears.

Here's another example from Movable Type's author's interface:

Note the option to change the default welcome message is clearly displayed right below the message itself; this makes it easy for the weblog author to 1) realize that the message can be changed and 2) click the link to go straight to the configuration screen where he can make the change.

You may object to this principle on the grounds that putting all the configuration options relevant to a given interface object right near the object would often clutter the screen horribly and likely confuse users who are new to the system and aren't ready to start reconfiguring it yet; they just want it to work. I have a couple of responses to that. First off, you may be able to design your configuration option so that it doesn't require any screen space; this is frequently possible with direct manipulation. For instance, I can reconfigure the order of my programs in the Mac OS X dock just by dragging them around:

If your configuration option is difficult to represent with direct manipulation, then we need another metaphor. One possibility is to extend the GUI to support the concept of standard "tools" which are always available regardless of the application the user is in. Think of an extension of the contextual help system in Windows, where you can click on a "?" button to turn the cursor into a question mark, then click on any interface element (theoretically) to get a nice little tooltip explaining what it does. That would be how a "help tool" would work. A "configuration tool" would instead provide you with the screen of configuration options when you clicked on that interface element to let you change its appearance or behavior.

These interfaces help solve the configuration problem because they provide the option right when the user needs it; when she has hit the point in her task where she wants the appearance or behavior of the application to be different than what it currently is. This integrates the "reconfigure the interface" task in with the user's primary task, rather than forcing it to become a secondary task that will likely be forgotten since it isn't a part of the user's main workflow, especially if it's difficult to figure out. If you're a cognitive walkthrough fan, you'll notice this helps to both ensure the user trys to achieve the "reconfigure the interface" affect and to ensure the user notices the relevant reconfiguration option is available.

[ Permanent Location ]

What's Related to this Post?

design, information, internet

April 23, 2003, 06:31 PM

One question I've frequently wanted to know the answer to since I started this here weblog is: "Now that I've finished this entry, what things are other webloggers saying that are related to the topics I discussed?" So I have a modest proposal for a solution to this problem.

I propose someone create a server that listens for weblogs.com XML-RPC pings from weblog updates. But instead of just providing a recently-updated list like weblogs.com does, when this server receives a ping it will fetch the weblog's RSS feed and extract the entry content and any associated metadata (title, category, whatever). Then it would run a "what's related" algorithm comparing the new post to all the posts in its database. Finally it would generate a report of weblog entries that are related to the new entry, and spit out an HTML page to a web server that could distribute this information to the masses.

The final system would look like this:

A nice extension to the system would be to send the URL of the final report back to the weblog tool so it could include a "Related Entries" link next to the post (if the weblog's author wanted it to do so, of course). But I don't know of any way to accomplish this without extending existing weblog tools.

I must confess I'm not sure how "what's related" algorithms work or how useful the current state of the art tools are. Google's concept of what's related to my page is a little strange (why does Micah's gesture literature review page come up, but not his weblog? And why does Mathilde's friend Mav's page appear?) although not completely inaccurate. But hey, that's a problem for the Language Technologies people to solve :).

Currently, the automatic notification ("ping") features built into most popular weblog tools are, in my opinion, underexploited. We could probably think of lots of other cool things to do with them if we tried.

[ Permanent Location ]

Tiered Architectures and Cross-cutting Concerns

design, software development

April 21, 2003, 01:12 PM

In Architectures for Software Systems today we had a guest lecturer: Bob Monroe from Freemarkets.com. He talked about tiered architectures for web-deployed enterprise information systems. Having already built such a system (albeit a relatively small one) myself, most of what he discussed was old hat for me.

However, as he was discussing the separation of enterprise applications into tiers to handle presentation, business logic, and data persistence (a standard, well accepted pattern for such systems) I got to thinking about some of the problems we ran into with EE in splitting our systems across these lines. Basically, we found that certain concerns have a tendency to cut across those layers, an example being data correctness checking, or ensuring that data sent to the system by a user or another system conforms to the structure you expect it to. For instance, a "payment" field should only contain numbers and an optional decimal point, and no more than two digits after the decimal point. Some software component has to be responsible for ensuring this is true for all incoming payment values. But where should this component live? It'd be nice to have it on the Presentation Tier so we could provide the user with better feedback if they enter incorrect values (the payment text field could be programmed to prevent the user from entering numbers, @ signs, etc). But what if we have multiple clients? And what if the correctness of the data is security critical and we can't trust the clients to perform the check? Then we should probably also put it in the Business Logic Tier. But what if multiple applications are sharing the same data store? If one application doesn't perform the check properly, it may corrupt the shared database. So we should really also put the check in the Persistence Tier as well. So we wind up with this:

But hold on one sec. This means I have to replicate the data correctness checking code across all of these tiers! Not only does this add to the performance overhead, but since oftentimes the tiers are implemented using different languages (in EE's case, we use DHTML/JavaScript for the client-side Presentation Tier, Java for the Business Logic Tier, and SQL for the Persistence Tier) we have to duplicate the same logic in at least three locations in the system, which clearly violates the DRY principle. So it seems none of our options are viable.

After the talk, I asked Bob how his teams confronted this issue. He said it was certainly a problem, and they usually wound up doing validation checking via social conventions (in other words, pick a tier to check data correctness so you can guarantee to lower tiers that the data is correct. Then tell the programmers "you'd better make sure you get the data checking right or the rest of our application is screwed!"). Though I do believe this is the best decision given the current state of the practice, I'd think we could find a better technical solution than this.

I have a few thoughts on how to solve this issue. Aspect-oriented programming may hold some promise, since the cross-cutting concerns can be implemented as aspects that can be attached to the relevent objects. But most aspect-oriented implementations I've heard of only work with a single language. This won't help if you've got the Javascript/Java/SQL combination we've had to deal with.

Another possibility is to represent cross-cutting concerns in a language-neutral format (such as a simple domain-specific language) and write code generators to produce the necessary Presentation, Business Logic, and Persistence code. This is the approach advocated by the Pragmatic Programmers. But this can get complicated since you may have to write quite a bit of infrastructure code to properly integrate the generated code in with your exising HTML pages, Java classes, and SQL tables.

It seems to me that vendors could provide better frameworks to help support cross-cutting concerns such as data correctness checking. These sorts of concerns are where architects and developers need the most help, so why aren't they being addressed? I can only conclude that most vendors are out of touch with the real needs of their users.

[ Permanent Location ]

MAYA's Marketplace of Mutable Meanings

design, information, internet, software development

April 17, 2003, 12:36 AM

I went to the HCII Seminar Series talk today given by Peter Lucas, the CEO of MAYA Design (which is where Mathilde works nowadays). He talked about Civium, a "vision and architecture for a seamless, distributed public information space".

Civium is a distributed data storage system that implements an information commons through location-transparent persistence. In this sense, it's similiar to Gnutella or Freenet: information can be widely distributed across machines to provide effectively limitless physical storage space and no one machine contains the cannonical representation of one piece of information, so information is much harder to destroy. So in this sense, Civium's not very interesting.

Civium also provides various clients to visualize the information present in the distributed database. Peter demoed a geographic information system (GIS) client that accessed information MAYA obtained from publically available government sources. But I've seen several such systems before, and this one didn't appear to do anything particularly novel (except that it was potentially more extensible, as we'll see). So in this sense, Civium's not very interesting.

What is interesting is the way that Civium handles data semantics and their dissemination. At the core of the system lies VIA, a universal database. VIA isn't entirely relational or object-oriented, but instead is based on three types of entities:

1. U-forms are sets of attribute name / value pairs with a Universal Unique Identifier (UUID) bound to them. So essentially, they're glorified hashtables that can be uniquely distinguished from all the other glorified hashtables on the network. Note that this is essentially what a RDBMS row is (provided it has a UUID primary key), so U-forms can work similiarly to relational table rows in terms of building more complex data structures using foreign keys, etc.
2. Shepherds are software agents that push U-forms around from repository to repository (a repository is any physical storage medium connected to VIA) without having to understand the semantic meaning of the U-form content. They take care of the whole "distributed" part of the system.
3. Roles are the schemata that define the semantic meaning of the data that appears in U-forms. But the neat thing is, Roles are stored in U-forms themselves. So if you need to discover the semantics of data in a U-form you've found, you just need to locate the data's Role U-form from the VIA system. If you want to extend an existing Role, you just need to insert your own U-form into VIA that includes the modifications you need and references the original Role.

Assuming that the semantics of Role U-forms are defined by the system (Peter skipped most of his slides on Roles, unfortunately), then this system essentially implements a "free market of data formats" in which anyone can create new formats or use existing ones, no one has control over a particular format, and market forces can determine which formats become "standards". I don't know of any other systems that provide real architectural support for this concept.

Granted, I have my doubts as to whether this approach would truly be effective in improving computing's recurring "format wars". After all, the browser wars of the ninties between Netscape and Microsoft were a good example of market forces influencing a shared format, HTML, while the relevent standards body, the W3C, stood by and watched, irrelevent. And that was a bad time to be a web developer. But at least in Civium, we wouldn't wind up with one powerful monopoly corporation controlling the format that won out.

Whether market forces, rather than standards committees, are truly the best way to produce consensus on data semantics and representations is a question I'm not prepared to answer. But Civium, if it ever becomes a major force, will certainly put this idea to the test.

[ Permanent Location ]

CHI Report, An Emotional Closing

aesthetics, design, usability

April 12, 2003, 06:53 PM

The final activity of the conference was the Closing Plenary, which was delivered by Don Norman on Emotion & Design. Don's speech was definitely one of the examples of a good use of the presentation format, which I briefly discussed earlier.

Don's plenary had three main points:

• Emotions are an important part of the user experience, inseparable from cognition, and are all too often ignored by usability professionals to the detriment of the profession.
• Science has begun to unveil the inner workings of emotion. We can confidently separate emotion into three main levels: the visceral level where we experience instinctive emotional reactions, the behavioral level where we act on our emotions, and the reflective level where our values, rationalizations, and emotional influences reside.
• Usability professionals should learn more about emotion and its relation to product design. If we continue to ignore emotions, we will continue to become irrelevant insofar as we are not directly affecting the desirability and emotional attractiveness of products that is so important in customer buying decisions.

Don illustrated these points with several examples of good product design. He admitted that people have different emotional reactions to these products and that designing for emotions are subjective. His response was to "deal with it". There is no reason to believe that products can be designed for everyone; often the necessary response is to design solely for a given target market.

The speech served to deliver several excellent points and an encouraging call to action. I've begun to see the seeds sown here at CMU for a more thorough understanding of this important new area; even within the MHCI program there are some who are interested in emotion and design. Kerry, for instance, is interested in fashion design for wearable computers, which definitely ties in to the emotion and self-image themes Don discussed. And I already mentioned several promising examples of work I heard of in the earlier panel session.

I'm looking forward to hearing more from this field, and maybe even having the chance to contribute.

[ Permanent Location ]

CHI Report, Recommender Systems

design, information, internet, society & sociology, usability

April 12, 2003, 04:40 PM

After lunch, I went with Mathilde to a short talk session on Recommender Systems. Three out of the four talks were interesting, so I considered it a pretty successful session.

The first talk was on how the ratings in systems like Amazon.com's customer-supplied product rating system can influence future customers ratings and lead to inaccurately high or low ratings for some products. The speaker studied a system called MovieLens, which looks similiar to an Amazon.com that only does theater movies. He found that around 8% of the time people would raise or lower their ratings based on the rating that was already present. Thus if users would rate a movie as 2 stars, but see a rating of 4 stars on MovieLens, they might adjust their rating, consciously or unconsciously, up to 3 stars. Though these individual effects may be slight, the inaccurracies may spread.

Another interesting finding he reported was that users could tell if a system had wildly inaccurate ratings, and that this would effect the users' opinions of the system. So if users found good movies rated low or bad movies rated high consistently, they reported a much lower opinion of the system as a whole. Unfortunately, he did only study a fairly extreme case of inaccuracy so it is difficult to say where the relevant threshhold value is.

The next speaker, David McDonald from the University of Washington School of Information, discussed a recommender system for group-ware tasks such as finding the relevant expert in a company who may be able to answer a given question. What made his talk particularly interesting was that he was using social networks to build such a system for a medical software company. Here are my main takeaway points:

• David built his social network through ethnographic observations. He discouraged the use of automated tools, such as tools that examine email sending patterns, since he felt these tools do not accurately approximate the real social network but instead are byproducts of the medium (a secretary may send lots of announcement emails to people she is not socially close to).
• He ran into a couple problems where one person was socially close to another even though few people knew it; they were buddies outside of work. Thus their connection didn't come out through his initial observations. Many users felt the tool should reflect their own personal social network rather than the socially perceived network of the entire workplace.
• Social networks are dynamic beasts, so the network had to adapt to changing social environments over time.
• The interface needed to provide a way to "escalate" the results, or expand and contract the number of recommended experts shown. Users reported that they often preferred many choices rather than a single choice, even if the single choice was in fact the best person to answer their question. They also wanted a good deal of control over the direction of the escalation.

The final interesting speaker was Thomas Erickson from IBM T.J. Watson Research Center. He discussed visualizations of social activity, such as those produced by the Sociable Media Group at the MIT Media Lab (which I applied to, by the way, and never heard back from...). He had a few interestiing things to say:

• There are two purposes of social visualizations: one is for an individual's information, the second is to portray the social state of a group back to the whole group. The two should not be confounded, and frequently shouldn't be combined in one interface.
• A completely accurate visualization of a social situation may be bad; many situations depend on face saving, "first impressions", etc. The little white lies that keep our social lives going...
• Ambiguity is often useful in these visualizations depending on the user's information needs. Large differences can be exaggerated, whereas runs of similar-looking data may be compressed. This is probably true of most visualizations

One side comment I thought of while watching these presentations: talks such as these are useful for making a few small, well-argued points that are interesting enough to encourage your audience to look into the area in more depth (or just take away your main points). The speakers who tried to go into great detail and make complicated arguments quickly lost the audience, whereas those who had simple points that powerfully portrayed their message were more effective. More on this when I get to Norman's closing plenary.

[ Permanent Location ]

CHI Report, Emotion and Design

aesthetics, design, usability

April 11, 2003, 08:01 PM

When I got in I went to a panel on Emotions and Design chaired by Jodi Forlizzi, a HCI and Design professor from CMU. Don Norman also showed up, since his new interest is in emotions and design. He opened the panel by discussing how emotions are tightly coupled to cognitive mental activities; he brought up a study that products that are more aesthetically pleasing are actually easier for people to use, even when all other factors are constant. More on Don later.

A number of interesting topics came up that I'd like to pursue in more detail. Here's a few of them:

• Gibson's theory of affordances which is intended to unify all aspects of the user, including cognitive and emotional responses.
• Jodi mentioned how emotions can both heighten the experience of using a product and get in the way of its effective use. How do we ensure we get the former and not the latter?
• Sometimes different emotions are coupled in ways you might not expect; for instance, disgust is frequently coupled with fascination, which explains why many people will linger so long over a disgusting scene, and talk about it at length afterwards.
• HCI as a field has a much higher percentage of women than many other technology disciplines. Someone asked if this accounted for the current attention to emotion. The panelists seemed to feel this was quite possible although emphasized that we shouldn't overgeneralize that "men are bad at emoting, women are good at it".
• I also recall a discussion at the Weblogs SIG about expressing emotions in weblog posts. I feel like these two areas relate, although I'm not sure how just yet.
• We have a tendency to anthropomorphize our products. One person wondered if we should design for this, the conclusion was that it could be good if it was done right. Little guidance was offered on what "right" meant though.
• Kees recommended educating designers in understanding and "getting in touch" with their emotions. I wondered, however, how easy this would be, since western culture in general tends to discourage display of many emotions and considers them "irrational". I was pleasantly surprised to find that Norman agrees.

[ Permanent Location ]

CHI Report, The Interactionary

design, personal, usability

April 10, 2003, 11:45 PM

Finally, I went to the Interactionary competition. Six people from the MHCI tribe were competing in a CMU team: Kelli, Andrew, Abby, Neema, Kevin Lee, and Kevin Fox. I swear I almost had a heart attack while sitting in the audience waiting for them to come up. After they'd finished Kenneth asked me the time; when I showed him my watch he said "my God, Rob, you're shaking!" I was incredibly nervous for them, and I didn't even have to go on stage.

But it all turned out for the best, since they won! We're all very proud of them; Bonnie even took us all out and bought the Interactionary team drinks at Hops. A great and well-deserved ending to a journey that took a lot of time and effort on all of their parts.

After we got back from Hops, we checked email at the conference center, then left for the CMU reception at the Marriott. Turned out there was no free beer at the CMU reception, so we crashed the Microsoft reception across the hall. I talked to several people at both receptions, which got exhausting for an introvert like me after awhile. Abby was getting tired too, so she and Neema and Matt and I left the party and went back to the hotel. We then went out for a night swim in the ocean. There was a storm going on far away; lightning flashed above the dark waters in the distance. It was a surreal and beautiful experience.

[ Permanent Location ]

CHI Report, Privacy, Security, and Trust

design, internet, usability

April 09, 2003, 06:48 PM

This marks the end of my second day here at CHI 2003. So many things happened; a thick swarm of ideas buzzed around my head, flew into my ears, nose, and mouth, got into my eyes and made them all watery, and generally became very annoying until I realized the analogy had gone too far and cut it off.

The first session I went to was on Privacy, Security, and Trust. Most of the talks didn't particularly interest me. One person had done a study of an online community in a small Massachusetts town and concluded that when you ensure people are using their real names, it tends to raise trust and civility while lowering people's willingness to disagree about controversial topics. Another woman had done a study on people's level of distraction while using cell phones, she found people tend to pay less attention to traffic lights while talking on their cell phones. Fairly common-sense stuff.

The one presentation I really liked was one on "Prominence-Interpretation Online". The doctoral student giving the talk, B.J. Fogg, argued that the credibility of a website was a function of two properties of the experience: the prominence of information (she must notice the information) and interpretation (she must make a judgment about the information). What's more, he did a study that found that the top factor people used to interpret information related to the design look and feel of the site, which was almost doubly more important than information design and structure. Which is disconcerting for those who expect that consumers in a market will make informed, researched decisions when assessing credibility. When asked whether we can design our websites to encourage a more robust credibility assessment, Fogg said he thought the only way to improve this situation was through educating people on their limitations and, in the meantime, make sure you have a nice site design.

[ Permanent Location ]

Pattern Sighting in Management Habitat

design, patterns, systems

April 05, 2003, 02:12 AM

I was working with Matt a few days ago on our TCinC independent study, and he showed me part of a book on Systems Diagrams, which are a component of systems thinking as described in The Fifth Discipline by Peter Senge. What struck me as particularly interesting about these things was how similiar Senge's concept of system "archetypes" is to patterns.

For those of you haven't heard of them, patterns are generalized solutions to a set of problems that occur in a particular discipline. They were first described by Christopher Alexander, a building architect, in his 1977 book A Pattern Language. Alexander's architectural pattern language included patterns such as "Courtyard" and "Good Materials". The Gang of Four (Gamma, Helm, Johnson, Vlissides) applied this notion to the design of software systems in their 1994 book, Design Patterns, which is where I first heard of them. They also happen to be one of the ten thousand things I'm very interested in.

In software systems, one common problem is that you have a component that performs a function you want to use, but it doesn't conform to the interface you need it to. Here's an example from a fictitious drawing editor application:

In this situation, we have an inheritance hierarchy whose root is Shape that has a "getBoundingBox()" method. We want to subclass Shape with a class that implements a line of text, and we already have a component, TextView that we'd like to reuse. However, TextView doesn't conform to Shape's interface. So we create TextShape, which implements Shape's interface just by calling the corresponding method(s) on TextView. This solution is then generalized to the Adapter pattern:

These drawings were adapted from diagrams in Design Patterns.

The Fifth Discipline is not related to software design, but instead is a business / management / project planning text that attempts to analyze work environments to locate the "feedback loops" or parts of the work process that must be examined if sustainable organizational learning is to occur. Senge provides archetypes of problem systems that commonly appear in organizations so you can try to fit your system to one or more of the archetypes to better understand what sort of solutions to apply.

Note how similar this is to the concept of a software design pattern; in both cases the assumption is that an abstract problem in the domain has an abstract solution structure that can be distilled by looking at many successful solutions found in practice. Then this solution structure can be adapted to fit local conditions to solve specific problems.

I wonder how other disciplines apply patterns or pattern-related concepts to solve common problems. In a sense, patterns are nothing new; we're just using induction to build abstractions, then deduction to apply those abstractions. It's how the scientific method works, and how humans have learned and thought for millennia. Yet making this way of thinking and encoding knowledge explicit seems to have a power of its own. I wonder where it can take us.

[ Permanent Location ]

Interoperability and a Level Playing Field

design, software development, usability

April 02, 2003, 07:25 PM

I went to the HCII Seminar Series talk today given by Roger Dannenberg, a CMU professor who is a musician and computer scientist. He talked about a real-time audio processing system he developed to assist musicians in producing new electronic audio devices, and he also spent a little time at the beginning discussing the problems and challenges with building systems to assist artists.

One point he made was that artists like to plug together things that weren't originally designed to work with each other (he gave an example of a robot/cello that played itself and a flying car/airplane). This can be a problem for software designers, because this means that individual frameworks and applications are unlikely to be able to serve all of the needs of artists. Applications are usually designed to solve the needs of their users by anticipating what sorts of tasks the user will perform while using the application (in usability engineering, getting the user tasks right is one of the most critical stages of the process). But for artists, you can't anticipate what tasks they're going to want to perform with the application; after all that is part of the artistry. What's a designer to do?

To me, this just reinforces the need for more componentized applications that can interoperate with one another, or "play nice together". I should be able to take my document out of Word and bring it into Photoshop to add some decorations to the pages, then schlurp it into an audio program to add voice notes on why I chose the wording I did. Or even better, get rid of these clunky applications and let me just work with my document, letting all that switching programs stuff go on behind the scenes. I want to be able to record my thoughts in documents, not Word .doc files. I don't want what I create to be limited by the one program I happened to first use to create it.

Others have said this many times before, and usually one of two answers are given:

1. It's too hard.
2. People don't want to use multiple applications; they just want one program that does what they want.

As for point 1, I'll agree that it's hard. But the hard problems are the fun ones, right? We shouldn't shirk away from something just because it's hard; not at least if we all agree that it is nonetheless worth doing.

As for point 2, I don't buy this at all. Sure people don't want to have to hassle with converting their data from one format to another (and dealing with the ensuing problems that causes); that's a program-centric problem and has nothing to do with their goals. But people do get frustrated when they want to do something and they find their application can't do it (or they can't figure out how to make it do it); we UI designers see this all the time. People use one application because it's the path of least resistance. It's the easiest way to get their job done, even if it won't always produce the best results. And they do this because we as technologists have failed, and we've failed because we can't figure out how to make our tools work together so that we don't have to guess at our user's needs.

Roger talked about how much many artists have to struggle with technology to get it to do what they envision. If you aren't a computer expert, the learning curve is generally too high to allow you to try out new things with technology, new directions that computing can go in. And I wonder how many great ideas we're losing each day because of this.

[ Permanent Location ]

Product Lines

design, software development

March 31, 2003, 01:35 PM

I'm taking a course this semester called "Architectures for Software Systems" (the acronym alone was enough to convince me to sign up) from the Software Engineering Institute (SEI). Today's lecture was on Product Lines, which are reusable architectural frameworks that abstract technical and domain functionality into a form that can be applied across a company's products. The lecturer, Rick, described them as "platonic forms" for your applications. For example, Microsoft makes a suite of productivity applications they call "Office". You may have heard of them. All these applications probably share quite a bit of functionality, for example, Word, Powerpoint, and Excel all contain a spell checker. Microsoft may wish to abstract out the spell checker along with all the other shared functionality into a generic architecture for their Office applications; if they did so, they'd have an Office product line.

Product lines are intended to be the first large-scale success story in the long quest for that elusive holy grail of software development: component reuse. Proponents of component reuse and reuse frameworks point out that if large-scale reuse could be achieved, we would finally see that order-of-magnitude increase in software productivity that Brooks claimed (correctly) would not appear for at least ten years hence when he published "No Silver Bullet" in 1987. But although small-scale reuse has been quite successful (libraries containing common sorting algorithms, data structures, graphical user interface widgets, etc. are reused every day) we haven't seen anything that brought about an order-of-magnitude improvement. Product lines, the claim goes, will change all that, since more than just simple code algorithms get reused. The requirements analysis, domain analysis, test cases, documentation, etc., etc. that were developed for the domain are all potentially reused as well.

One point that I got out of the lecture was that the key to large-scale reuse ("strategic reuse" as Rick called it) was having a social framework of staff who understand the domain the product line is built to support and how the technical architecture applies to that domain, both to build the product line and to maintain it. A technical steering committee is required to look after the architecture and see how it can evolve to meet the needs of future products. This appears to be in line with Peter Naur's (of BNF fame) article on "Programming as Theory Building" that I read recently (it's in the back of Agile Software Development). Naur posits that software development is not primarily manufacturing an artifact (the executable program), but instead is primarily the act of building a theory about how the system works in the heads of the programmers working on the project. With a product line I would guess this is even more true, since the product line must be used to solve a variety of problems that it wasn't directly designed for in order to provide the reuse benefits extolled by reuse proponents. This also means that it may be difficult for a company to be in the business of selling product lines to other companies that build the actual products. The in-house expertise is at least as important as the compiled components and documentation, so without this expertise the buying company may be unable to use the framework. Caveat emptor...

In other respects, however, product lines don't seem to mesh well with agile philosophies. Developing a product line means spending a lot of up-front effort in building the architectural framework before you ever ship a product, a big no-no in most any agile methodology. So I went up after the lecture and asked Rick whether product lines were just for the "big boys" or if small start-ups could benefit as well. He said he'd only had experience working for large companies, but that a couple of former members of the SEI had started a company in which they had "grown" a product line while still producing releases. I'm skeptical, but I'll believe it if I see it.

[ Permanent Location ]