[My apologies. This post is something of a mess. Part of me wants to spend more time refining it, but part of me wants to just get it out there, as I've been sitting on it for too long already.]]
As per usual, my brain is swirling with half-baked notions that seem like that ought to fit together, but so rarely do. In the shower just now (yes! bright ideas do come in the shower!) I figured out a way to weave some coherence through some ideas related to information architecture, cartography, and the plasticity of cyberspace.
It's best to start with LineDrive, the driving-directions mapping technology discussed here a bit back. The great thing about LineDrive is that it makes maps usable through simplifying their presentation in ways that suit human perception. The reason LineDrive can do this is because it's highly responsive to the specific task at hand--someone needing to get from point A to point B.
See, most maps are filled with all kinds of information, because the mapmaker can't be certain as to what people will need to do with that information. LineDrive gets rid of extraneous information, focusing on the essentials for the explicit goal. LineDrive is able to do this through the magic of, well, computation. In cyberspace, there is no there there--there is only what the computer makes of it. Typical driving directions interfaces are too wedded to the existing print-model of maps, overloading the visualizations with unnecessary information. LineDrive uses a computer for what it's good for, and through it's algorithms, makes a 'there' that's more likely meaningful to its user.
Information architecture could benefit from such notions. Classic information retrieval systems are unaware of the users' specific task--why the user wants the information, what the user plans on doing with it. They compensate for this by being exhaustive, both in terms of breadth of information, as well as providing as much metadata as is feasible.
But why not have information architectures that are task-specific? So few are. Most information architectures are (sadly) drawn from the structure of the organization. Better information architectures are derived from the qualities of information, its metadata and so forth.
But many, if not most, websites ought to be fairly aware of the tasks that their visitors are pursuing. Few websites are so general purpose as to need to be all things to all people. For the last four months, I've been working on a site for an enterprise-level software company. The basic task of most folks visiting the website is obvious -- research the purchase of enterprise-level software. And there's a fairly well-understood purchase life-cycle process that the web site can respond to.
So, our suggestion is to do that, and user feedback of prototype designs has been quite positive. To make this more concrete, I'll offer an example of a similar site (that I didn't design) - iplanet.com. For an article I'm writing, I interview Beth Berrean, an IA at ZEFER who worked on this website. She wrote to me the following:
By breaking down the main goal into a certain life-cycle tasks (evaluate, purchase, install, implement, maintain, extend), we were able to identify a high level navigation that would make sense--solutions, products, services. (sort of a why, what, how thing).
Secondly, we also thought through how these tasks are actually performed and what was needed. Various people are involved in making a decision: a CXO might want to know what other companies had implemented a particular solution and the details around how they had done that; a Developer who would be asked for an opinion during evaluation would want to know what technology standards were implemented.
This gave us our idea for a secondary nav system which makes us the home pages of the solutions and products section--it's a dhtml toc kind of solution that would allow each user type to get to the info they needed as quickly as possible.
More websites ought to take advantage of understanding the basic task in order to present their content in ways that users will be more receptive to. I think it ends up being analagous to LineDrive--by using the tasks as a boundaries and a guide through the content, you can 'draw' the straight clean line, eliminating extraneous information that you might otherwise present.
Thinking farther in the future, I wonder how an explicit understanding of task could help shape our information architectures on the fly. LineDrive draws from the same cartographic data as any other mapmaking software--it just does something smart with it, as opposed to simply reproducing it with a line drawn over it. Could content structures be arranged meaningfully, on the fly, to respond to understood needs?
I'd love to hear more about how others have developed task-based information architectures, their experiences, what has worked and what doesn't. I think there are some interesting research opportunities here, to see if having a task-based foundation for an information architecture makes such spaces more usable than the more standard metadata-based structures from information retrieval.
3 comments so far. Add a comment.
Previous entry: "I inevitably get that song in my head."
Next entry: "A point from my last post."
> The great thing about LineDrive is that it makes maps usable through simplifying their presentation in ways that suit human perception.
It sure doesn't seem to me like LineDrive is offering maps (though they call what they produce a "route map"). It looks just like standard driving directions, "informationally" (ugh) equivalent to a set of written or spoken instructions ("left onto Elm Street, keep going a few miles, right onto Cherrywood Parkway" etc.) Therefore, they are not offering a better map, a more simplified map or any kind of map at all: just a tried and true visual representation of a set of instructions (which probably works better for most people since it seems like half the people I know can't reliably tell "left" from "right").
I'm not trying to nitpick here; I think the distinction is important since it carries over in the analogy to presenting a whole site vs presenting a subset bounded by the requirements of the task-doer. LineDrive isn't giving a subset of the regular map: it is presenting something (IMO) fundamentally different (though superficially similar, and, obviously, derived from the same data).
In the analogy to task-specific presentation of site data, it isn't just stripping away extraneous information that is going to make a big difference to users, it is the information itself (how it is written maybe, or what the focus is, or how big and accurate the graphs are, or whether the schematics are to scale, or whatever).
> Thinking farther in the future, I wonder how an explicit understanding of task could help shape our information architectures on the fly.
The thing is that the task that people seek help from LineDrive in accomplishing is extremely simple and doesn't admit of much vagueness. The requirements can be stated very precisely without any ambiguity. Abstracting only a little, *everyone* who uses LineDrive has *exactly* the same task: get from [A] to [B].
On the other hand, even assuming that people had a clear enough idea of their own complex tasks -- say, "research this company" or "find out about argentina" -- it seems impossible that they'd be able to articulate their requirements well enough for a computer to get what it needs in order to give back just the right information (maybe I'm not thinking far enough into the future -- sure human-like intelligences would be able to do things as well as humans).
Anyway, I guess I'm wondering what you are picturing beyond the (somewhat standard on well-designed sites) self-selection by audience-type ("potential employees", "investors") or task ("find a product", "contact us")
Posted by Stewart @ 08/23/2001 02:06 AM PST [link to this comment]
I agree with stewart to an extent. Are you talking about sites/companies that existing to only achive one thing or sites that quickly funnel people into the appropriate 'user-experience-on-rails'...?
Like the video games Time Crisis or Pokemon Snap, a 'UI-on-rails' glides you along through each requisite step on a pre-determined route once you've elected to step through the task-doorway.
With Virgin Mobile we tried hard to keep to the vision of a 'vending machine' for phones on the web... kept paring it back to that. It was pretty successful as such in it's orginal incarnation.
Stefan who happened to be my client at Virgin, of course had done the ultimate UI-on-rails with Tom before that though... upmystreet.com
and followed the UI-on-rails train (heh) of thought through with the rest of the crew with the awesome democracy-hack of faxyourmp.com
Posted by Matt @ 08/23/2001 02:31 AM PST [link to this comment]
From the quote: "By breaking down the main goal into a certain life-cycle tasks (evaluate, purchase, install, implement, maintain, extend), we were able to identify a high level navigation that would make sense--solutions, products, services. (sort of a why, what, how thing)."
So...iplanet ended up with the same "products, solutions, services" IA that every other site has? What's the point in working out a unique task-based IA if the same-old same-old is what results? I'm just as guilty of this as anyone and have used "solutions" in IA before. Somehow the value of peter's LineDrive analogy (and it is really only an analogy, not a model to use) seems lost if the tasks are just "what, how, why." Of course the tasks are "what, how, why, (and maybe who)"--I mean, what else is there?
Posted by Andrew @ 08/24/2001 01:05 PM PST [link to this comment]
Add A New Comment: