 |
« | Week of Aug 10 | < | Individual Entries | > | Week of Aug 24 | » |  |
 |
 |
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":
- Location
- Alphabetical
- Time
- Category
- 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'! :)
Email Rob:
Social Networking Astronauts
society & sociology
August 23, 2003, 07:06 PM
Micah reminded me yesterday of an article written by the ever-insightful Joel Spolsky on "architecture astronauts", those great thinkers that have the unfortunate tendancy to get caught up in reaching for the highest pinnacles of elegant abstraction only to produce solutions that are completely incomprehensible to the rest of us. Essentially, the architecture astronaut's flights of intellectual fancy bring him out of touch with reality; the grand concepts he dreams up have little to do with the practical problems his real users face on a day-to-day basis. Specifically, Joel mentions Napster; he states: "Your typical architecture astronaut will take a fact like 'Napster is a peer-to-peer service for downloading music' and ignore everything but the architecture, thinking it's interesting because it's peer to peer, completely missing the point that it's interesting because you can type the name of a song and listen to it right away."
That article was written over two years ago, so its example is a bit dated. I thought I'd take the opportunity to update it. Consider Friendster.
To many who are interested in social network analysis, Friendster is interesting because it is based on their paradigm. You join, you're hooked in with your immediate friends, and then you can explore the friends of friends of friends and so on who are in your network. And I must admit it is pretty neat; sometimes I'll find some person way out in my network is connected by two friends who I wouldn't have expected to be joined in that fashion. Its at least a neat curiosity and a possible conversation starter.
But let's stop kidding ourselves. Is Friendster really so popular because it's a real-world, practical social network analysis tool, or is it so popular because its a free online dating service? To the social networking intellectuals who are spilling so much digital ink over the site, the dating is almost incidental, but I'm not convinced. Judging from my experiences with how people actually behave on the site, I'd have to put in my vote for the latter.
My point, I suppose, is that astronauts exist in more fields than just architecture. We who dream of grand concepts in the clouds have a tendency to get excited over the wrong things, whether this is peer-to-peer architectures or social network theory; we easily lose touch with the real needs and desires of "ordinary" users, whether this is listening to music or finding a friday night date. Unfortunately, in our work we often start with these grand concepts; we hear about a neat idea, get excited, and then go try to find a problem to apply it to. How can we be more careful and ensure our energies are more focused on the real problems out there in the world?
Email Rob:
Extreme Usability
software development, usability
August 22, 2003, 05:06 PM
Early last spring, I gave a talk on eXtreme Programming (XP) at the MHCI Student Seminar Series. Giving a talk on a programming methodology to a bunch of usability and design folks fit in with my interests in unifying software development and usability and hopefully helped them understand how to better work with programmers. Given the audience, after I gave the overview of XP itself I threw out some ideas on how to integrate our usability techniques into an XP environment.
XP, at least as described by Kent Beck, is unfortunately fairly naive about usability. Beck does not put down usability, in fact he emphasizes that the software must provide value to its users (or in his words, "the business") and thus representatives of the users must be given control over defining that value. But XP makes a few assumptions that we in the usability community know to be false. For instance, it assumes the customer representative or domain expert will be able to define the users' needs and come up with an effective interface design. However, in HCI it's well known that users are not designers, that they know their work but not necessarily how to improve their work; they may not be able to come up with a more usable interface than programmers. In fact XP doesn't say much about interface design at all; the assumption appears to be that an effective design will come out of the user stories.
On the other hand, XP is in many respects very compatible with usability techniques. XP emphasizes the importance of testing and iteration, which are also important concepts in classic usability engineering. It also emphasizes the importance of trying out many ideas and making improvements where they are needed, which are important concepts in interaction design. So at least in the abstract, it seems that usability would fit well into XP. But how can we make this concrete?
During the talk, we had a discussion about exactly how usability techniques might fit into the process. This list contains the thoughts that came out of that discussion, as well as my own ideas and those I've found through my readings.
- Field workers and interaction designers play the part of "Business" in the Planning Game.
- If this isn't possible, Participatory Design techniques like PICTIVE could help customers develop more effective designs.
- Put usability people on the team, co-located with the developers while they work.
- Use the RITE method for functional tests.
- Have the Tracker record usability metrics and test results in addition to stories completed, time until release, etc.
- Have the Coach look at the UI "big picture" as well as the implementation big picture.
- Develop a Metaphor that is part of both the UI design and the code structure.
The most obvious way to partition the usability / development responsibility in XP is to have field workers and interaction designers (using a technique like Contextual Design or Goal-Directed Design) play the part of "Business" in the Planning Game instead of customer representatives or marketing. This means the designers are responsible for defining the "stories" (which are reasonably similar to scenarios; Scenario-Based Design is a component of Goal-Directed Design as well as a useful technique in its own right) as well as responsible for prioritizing those stories with respect to how essential they are to creating a usable system. The developers are responsible for estimating cost and time of implementing each story. Essentially, I'd claim the Planning Game already provides an adequate framework in which usability and development can work; we just need to change who's involved in the process.
This isn't a brand new idea; Chris Neuwirth, a professor in the English department here at CMU, worked with researchers at Xerox PARC to implement such a process. They even found that "their first model was unsuccessful even 'with a user-centred approach, largely because fieldwork inspired engineering repeatedly led to innovations that delivered no significant end-user advantages over what was already supported' by available systems.... But, for their second exploration, the team 'adopted XP as an approach to keep design closely tied to fieldwork findings and usage experience, with fieldworkers playing the part of customer representatives'. This approach, they conclude, was far more successful, giving a usable prototype in a fraction of the time of the first." In this case, XP improved the usability process just as much as the usability process improved XP; eschewing the large, up-front design time allowed the team to test real, working systems rather than simple mockups or prototypes, improving the quality of the feedback they received and the resulting designs they produced. Kent Beck and Alan Cooper publically argued over this very point; I think Beck came out on top, but you can see if you agree.
However, it may not always be feasible to hire a team of usability professionals and interaction designers to "play customer". In this case, Participatory Design techniques such as PICTIVE may prove useful in helping the customers, facilitated by a trained designer, design better UIs on their own. Participatory Design is apparently common practice in Europe, but sadly hasn't caught on as much in the States.
The next most important change involves getting the usability people into the same room as the programmers and ensuring they work together closely throughout the process. XP and other agile methodologies rely on close communication between all team participants; if the usability people are off in their own room, separate from the programmers, then their designs won't get implemented the way they intended. To ensure these two cultures have things to talk about and interact over, they may need effective boundry objects to help them communicate such as our very own U&SA technique. Ideally, the usability people should participate in pair programming when user interface issues are getting implemented in code. At minimum, one usability person should play the part of the On-Site Customer.
When it comes time to run functional tests, a quick, iterative testing methodology such as RITE should be employed by the usability team to get fast feedback on the usability of the system. RITE is a good fit for XP because it sacrifices slow, scientific precision for quick feedback on design glitches and ensures those glitches are fixed by more quick, iterative tests. The results of these tests can get fed back into design changes to the interface, which will get converted to stories that are placed into the next (or current) iteration as their criticality warrents (or may just get implemented on the spot; because everyone is communicating effectively the easy-to-change things can get fixed without having to go through the formal process).
To ensure that the usability goals of the system are getting met (whaddya mean you haven't defined usability goals?! That should have happened in the Planning Game!) the Tracker should chart the results of the usability tests and map those against the goals of the project. These results should be posted along with the normal functional test scores, completed stories, etc. that help the team realize when the schedule is starting to slip.
At the same time, the XP Coach should be keeping an eye on the "big picture" of the user interface design as well as the big picture of the internal software design. This requires the coach to be both a skilled interaction designer and software architect, however, so it may prove necessary to hire another "UI Coach" to perform this role. Someone has to be keeping an eye on the overall information flow and interaction architecture of the system's design, however, to prevent a series of sure-made-sense-at-the-time fixes from ruining the overall user experience.
Finally, XP calls for the creation of a "Metaphor", or a high-level description and terminology for the system's internals. Usability people also talk about metaphors, but these refer to metaphors in the interface design that draw on users' experience with real-world objects. On the face of it, I figured this was a situation where the same word has two different meanings in different cultures, but now I'm not so sure. If the metaphor for the system design and the metaphor for the interface design are the same, then this should greatly improve the communication between the customers, the interface designers, and the developers, since they'd all be speaking the same language. Supposedly, this was touted as one of the benefits of object-oriented programming: users and developers could both understand the software design if it is written in terms of real-world objects instead of functions and data structures. But so far this hasn't panned out; perhaps using the XP Metaphor in this fashion will finally make this "feature" of the OOP a reality.
And there you are: a usability-friendly XP, or "eXtreme Usability", if you will. Now all we have to do is try it out on a real-life project. Any volunteers?
Email Rob:
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 ;).
Email Rob:
Usability Impacts Architecture (But Don't Take My Word For It...)
software development, usability
August 19, 2003, 04:34 PM
As many of you already know, one of the areas I'm interested in is understanding and improving the connection between software development and usability in general and software architecture and interface design in particular (in fact, I'm currently gainfully employed to work on this problem). Most of the time, when I describe what I do to my fellow HCI people (especially HCI people with some "in the trenches" experience), they immediately see the benefit of our work; often they have a "We can't change THAT!" story of their own to relate to me. Sometimes, however, I get blank stares or a casual shrug; some usability professionals assume that architecture design is the software developers' job and doesn't concern them or that the relationship between architecture and usability is a solved problem. For those people, as well as for my own records, I'm starting a list of other HCI/usability and software people who agree that architectural impacts on usability are an important problem. Feel free to post a comment if you know of anyone who made this important point that I left out.
So don't just take my word for it...
- Scott Burken, a long-time designer and usability evangelist at Microsoft, has an essay on the "long list of reasons why ease of use doesn't happen" on his website. One of those reasons is "the unseen impact on ease of use on system/code architecture". He states:
The biggest danger with the code architecture view of a project is that if the UI is designed last, many assumptions can be built into the design of the architecture that unknowingly effect the UI design. For example, a database architecture for a website might require that information be typed in by the customer in a certain format (which turns out to be confusing to customers), or that certain kinds of widgets have to be displayed together (which turns out to be confusing to customers). By the time the team gets around to working on the UI layer, so many constraints may be placed onto the ui designer, that it's impossible to actually create a system that's easy for customers to use (so surprise: the system turns out to be confusing to customers).
- Ben Shneiderman, the well-known usability researcher, recognizes the architectural implications of usability in his influential book "Designing the User Interface" by recommending that programmers get involved early in the process for identifying architectural issues. I quote: "The prototypes are usually developed by a programmer who is part of the software engineering team. One of this programmer's responsibilities is to identify interface issues that have implications for the technical architecture of the product." (p. 106)
- The Software Engineering Institute (SEI) published a book on software architecture design entitled "Software Architecture In Practice" (SAP). The first edition of SAP equated architectural usability issues with modifiability issues, and deemed it a problem solved by separation patterns like Model-View-Controller or Presentation-Abstraction-Control. The first addition asserted: "Making a system's user interface clear and easy to use is primarily a matter of getting the details of a user's interaction correct...but these details are not architectural." The second edition (recently released) admitted this claim was an error and corrected it: "Many usability issues are architectural. In fact, the usability features that are the most difficult to achieve (and, in particular, the features that are most difficult to add on after the system has been built) turn out to be precisely those that are architectural."
- The Usability and Software Architecture (U&SA) Project, a joint venture between Carnegie Mellon's HCII and SEI of which I am a part, has made this argument since its inception. We've published a technical report on the topic; more current information is in later publications. We argue: "Separation of the user interface has been quite effective, and is commonly used in practice, but it has problems. First, there are many aspects of usability that require architectural support other than separation, and, second, the later changes are made to the system, the more expensive they are to achieve."
- The STATUS Project, funded by the European Union, is U&SA's counterpart overseas. In the overview of their research, they assert "The traditional software quality attributes are reliability, efficiency, maintainability,?. However, there is no doubt (and many authors defend this stand) that usability is another software quality attribute. However, the relationships between software usability and software architecture have not yet been studied."
- Extreme Programming (XP) does not explicitly argue for usability impacts on software architecture, but it does argue for a software design that is created and constantly refactored to fit customer needs. XP's concept of a "metaphor" instead of a formal architecture blends usability and software design: "We need to emphasize the goal of architecture, which is to give everyone a coherent story within which to work, a story that can easily be shared by the business and technical folks." (Extreme Programming Explained, p. 57) If you replace "business" with "users", which is usually what Beck means, you have support for the argument.
That's what I have so far. Again, if you know of any other good pointers on this topic, please do comment below or send me email.
Posted by Rob on August 19, 2003 at 07:10 PM
I added the bullet about STATUS just now. One of their researchers (Mariabel Sanchez-Segura) is visiting Carnegie Mellon right now, so it wouldn't do to leave them out! :)
Posted by Jeff on August 24, 2003 at 10:07 AM
Alan Cooper and Bruce Tognazzini are a couple others that come to mind. Cooper talks about how architecture and usability can be at odds in Inmates, and Tognazzini briefly relates usability concessions that were based on architectural limitations in the early days of Apple in Tog on Interface.
Email Rob:
Posted by Jeff on August 23, 2003 at 08:01 PM
Richard Saul Wurman covers LATCH in Information Anxiety 2. He describes it as a finite list of organizational possibilities. I think this is largely because Category is such a catch-all scheme.
The choice of how to organize infomation isn't always obvious, since more than one scheme can apply, either exclusively or in tandem. Case in point is the Vietnam Memorial Wall, first approached as an alphabetical listing, and then refined as chronological, or the yellow pages, both categorical and alphabetical.
Posted by Rob on August 24, 2003 at 05:44 PM
Thanks for the reference; I knew Bob said he'd heard of LATCH from somewhere else, but I'd forgotten the name of the guy. Here's the book on Amazon.com, for posterity.
I thought about this a little more, though, and realized this list doesn't cover a "network" as a means of organizing information. Granted, networks are rarely useful as organizational schemes because they tend to get confusing quickly, but I'd imagine they are appropriate (or perhaps unavoidable) for at least some types of information organization.
Posted by Jeff on August 24, 2003 at 06:36 PM
Isn't the concept of "network" an offshoot of the location principle? Maybe I'm not understanding exactly how you mean. In any event, network seems too much like a "thing", sort of like saying that a bookcase is an organizational principle.
Posted by Vishi on August 25, 2003 at 12:20 AM
Hierarchys are basicly trees structures. Categories make hierarchies. Location, alphabet and time are types of categories. There may be lots of other types of categories like author, application used, etc which are the meta data of the object being described.
Now, a network or a semi-latice is made up of hierarchies or trees. More info on this is here (http://www.rudi.net/bookshelf/classics/city/alexander/alexander1.shtml).
Posted by Rob on August 25, 2003 at 01:09 AM
By a network, I mean an organizational structure where each information item is organized by its association with some subset of the other information items in the structure. Maybe "graph" would be a better term. Mathematicians define hierarchies as special cases of graphs (hierarchies usually have a single root and every child element has only one parent, whereas graphs have no root and every element can be associated with an arbitrary number of other elements). Friendster's mechanism for organizing your personal network would be an example (although maybe not the best one).
I suppose this could be considered an offshoot of "location". I was thinking that part of the definition of "location" was that each information item had some absolute position in space, independent of the positions of other information items, whereas in a graph information items are ordered purely with respect to one another.
Vishi: It's true that in some sense location, lexical order, and time are all categories; philosophers would say that all these things are properties of the information item. But to an information designer, thinking at this level of abstraction is rarely useful since good design is very much about staying concrete. Most users don't see lexical ordering and chronological ordering as the same thing. Remember, we're trying not to be astronauts here. :)
Posted by Vishi on August 25, 2003 at 12:34 PM
The lesson of the architecture astronauts is that, it makes it easier for the designers/programmers to work with abstract patterns, but they should not loose focus of the user. Task based interfaces help in working with abstract patterns while keeping the user in focus. So, what is important to an information designer is which categories are important to people while doing a task. The importance of the Location, alphabetical , time or something else depends on the task the user is doing and cannot be generalized.
Posted by Jeff on August 26, 2003 at 10:10 AM
We talked about LATCH in studio yesterday. Cheryl brought up the possibility that a sixth organizational scheme was "Random." This caused much discussion, including the possiblity that the acronym could be LARTCH. I prefer L'CHART.
Posted by Rob on August 26, 2003 at 12:26 PM
"Random"... That's a good one. Almost always a bad organizational scheme, but unfortunately also often the easiest to program. Until last weekend, my "Friends" sidebar was organized using that scheme, as you may have noticed. Then I learned more Perl...
Posted by Rob on August 27, 2003 at 11:39 AM
Just wanted to point out that Micah has more on this, including some interesting analysis of LATCH by Ryan.
Posted by Jeff on August 31, 2003 at 12:18 AM
In the first edition of Information Anxiety, Wurman hadn't yet come up with the clever acronym and was referring to "hierarchy" as "continuum". There's a subtle difference, but maybe not enough to justify a sixth method.
Posted by Rob on January 21, 2004 at 09:10 AM
As a quick follow-up: Jeff had it right when he noted that "hierarchy" was originally called "continuum", which is really a more accurate name. "Hierarchy" implies some sort of tree structure to many people, which is really just categories of categories. But the hierarchy in LATCH refers to a continuum organization where each information item is organized in relation to the other items based on some property; e.g. widget A is bigger that widget B which is bigger than widget C, etc.