Home
Archives
Archives before June 13, 2001
RSS Feed
Adaptive
Path (my company!)
About
peterme
Coordinates
Most of the Time
Oakland, CA
Interests
Current
American history around the time of the Revolution, figuring out how to marry top-down task-based information architecture processes with bottom-up document-based ones, finding a good dentist in San Francisco Oakland
Perennial
Designing
the user experience (interaction design, information architecture, user
research, etc.), cognitive science, ice cream, films and film theory,
girls, commuter bicycling, coffee, travel, theoretical physics for laypeople,
single malt scotch, fresh salmon nigiri, hanging out, comics formalism,
applied complexity theory, Krispy Kreme donuts.
surf
Click
to see where I wander.
Wish
list
Show
me you love me by
buying
me things.
Spyonme
Track updates of
this page with Spyonit. Clickee
here.
Essays
[Editor's note: peterme.com
began as a site of self-published essays, a la Stating
The Obvious. This evolved (or devolved) towards link lists and shorter
thoughtpieces. These essays are getting a tad old, but have some good
ideas.]
Reader Favorites
Interface
Design Recommended Reading List
Whose
"My" Is It Anyway?
Frames:
Information Vs. Application
Subjects
Interface Design
Web Development
Movie Reviews
Travel
| 'tis the season of my dis-content. Posted on 04/05/2002. |
|
Of late, I have had a lot of reason to consider the Lou Rosenfeld and Peter Morville's notion of information architecture being where "business context", "users", and "content" meet.  Taken from http://argus-inc.com/services/definition.shtml I agree that the design and development of any information architecture must take into account the business realities in which that system exists, and the needs and abilities of that system's users. However, the placement of "content" in this model bugs me. It doesn't really belong there. There is nothing inherent about "content" that ought to inform the final outcome that shouldn't already be part of "business context". By overplaying content, the model exposes Peter and Lou's librarian roots. Sure, in a library context, the librarians are having to wrangle content produced outside their organization and offer it up in a meaningful fashion. In that case, you could argue that there is a "given" of a body of content to manipulate. But that's the exception, not the rule. In my work experience, all the content is produced from within the organization. And a failing of current web site practice is that we treat existing content as a "given" to be shoveled to users via the web site. And models like Peter and Lou's that put content on equal footing to business context and user needs, only end up promoting that. Within a closed system such as an enterprise's Web site, content should be the *product* of the merging of business context and user needs. I would argue that instead of having a separate circle to acknowledge the realm of existing content and content production, that should instead simply be subsumed into business context--it's just another attribute of the current existing business practice, that there is a body of content available for re-use. 19 comments so far. Add a comment. Previous entry: "I hate passwords, too." COMMENT #1 In practice, however, it's a far different story. How often does existing content support the ever changing business goals of an organization AND the needs of the user? It never has on any project I've worked on. I agree that content should be driven from within an organization and must align itself with business goals to be deemed 'successful' from a Business Context perspective. In order to ensure this success, content should be reviewed/re-purposed/rewritten whenever the Business Context shifts. What I feel is missing if content is tucked away into the Business Context (and what I think Peter and Lou were trying to get across with the diagram above) is that content has just as important a relationship with it's users. As such, content should also be reviewed/re-purposed/rewritten when the needs of it's audience changes. All that said, I think the relationship should be depicted something like this. Thoughts?
COMMENT #2 Then again, content wranglin' is part of a library's business context. Anyway, I agree that content that exists outside the business context is simply irrelevant. In fairness to Lou and Peter, though, that's one possible interpretation of the diagram. It all depends on how you populate the sets "user," "content," and "business context."
COMMENT #3 At this point the business context needs to be re-shaped. No point trying to sell buggy whips anymore. Similarly, the user context should be informed by the content context. There is this prevailing zeitgeist that users are omniscient and wise in their purposes (and businesses to, for that matter). Its a myth.
COMMENT #4 When I worked with SpotLife, a video hosting/sharing company, I suggested to them that they should consider trying to index all video content on the web, not just video that they themselves hosted. "Holy crap!" they said, and of course I paraphrase, "then we would have external links!! We'd lose all our viewers and [some web metric popular in early 2000] would drop!!" I still maintain that they should've taken my advice. The reasoning behind it was that if you are the recognized authority on video or whatever else on the web, you expand your loyal audience. People come to you first when they're looking for something. Point is, the web is not a one-on-one relationship, and it's too bad that it's cast as such by the people who pay you. On the net, every piece of data is equidistant from every other piece; you don't "shovel it to users", but make it available by putting it in a context. One goal of a site, even an enterprise site, should be to enrich the user with information about their products -- diverse information. Info from the world at large, from possible applications of the product, even from other users. This is all content which is outside of the business context, but which can be wrangled to properly serve the business and the user. Most blogs like these are a case in point (and serve a business purpose very well). I realize your clients may not go for this. Mine didn't. (And if they're Amazon or Microsoft, they just go and buy up the outside content.) But you might mention that Google's rating system heavily favors external links when scoring results.
COMMENT #5 Considering only the business context and the users is not enough. Content does not just magically "happen" because the business context dictates that it should. Content is hard work, and in my experience far too few user experience practitioners appreciate that fact. Content always places constraints upon architecture, because no organization has an infinite capacity for content production. Moreover, the content itself has inherent qualities that require certain architectural approaches. Tutorial content needs a different treatment from white papers. Audio downloads need a different treatment from a database of store locations. These are issues above and beyond business context that merit equal consideration.
COMMENT #6 Additionally, as Travis points out, content doesn't only come from within an enterprise. Especially in the Web environment, where links and syndication mean that content knows no (web site) borders. What else? The Good Peter and I constantly beat people over the head with content as one of these three circles because in our experience most information architects don't know diddly about the architecture of information. Ergo becoming indistinguishable from many other flavors of experience designers. And yet there are so many benefits to structuring and labeling content in the form of improved searching, browsing, and management. So we give content its own little circle to counter those who think that IA should be completely user-centered. UCD the answer to all of our problems? Bzzzt! Sorry. Doesn't work that way. Content has attributes and, yes, *needs* that have to be figured into the equation, some times at the expense of users and context. We're stuck with more and more content, and of ever worsening quality, so we can stick our heads in the sand all we want, but if you're going to practice IA you'd better accept that you have to devote yourself to understanding and working with content itself. I'm particularly tired right now, so pardon the crankiness. And I'm guessing Peter's going off on circle #3 because, well, he's been reading our hugely long and unwieldy content, er, manuscript for the polar bear book's second edition. I'm sure he's just plain sick of all circles right now. OK, off to bed...
COMMENT #7 No one said (okay, at least not me) that content wasn't important, only that "working with content" always happens within the business context. If you're going to have a circle for content, why not have a circle for technology? Certainly technological factors (from monitor resolution to the statelessness of the web itself) influence the practice of IA, and the development of content. My point is that while content and technology are the construction materials, business and user needs drive architecture. Dealing with content independent of those needs would be something like an architect starting a project by saying "what can we build with all this wood?"
COMMENT #8 it seems to me that the whole point of a venn diagram is to overlap, which means that inherent in its structure is an admission that the lines between whatever's being encircled are blurry at best. indeed, that the whole point of a venn diagram is to note that this blurriness is in fact to your advantage. on a related note, i'm really sick of venn diagrams. the venn seems to me to be so ubiquitously obvious -- is there anything in this world that can't be venn diagrammed in the pursuit of making a point? -- as to have collapsed into utter uselessness.
COMMENT #9 And yes, I'm sick of Venn diagrams as well. A Venn-less presentation is on my list of goals for this year.
COMMENT #10 http://www.louisrosenfeld.com/home/bloug_archive/images/010813b.gif
COMMENT #11 For a "real" architect, that content circle would be "materials". To understand the different capabilities of wood, steel, brick, fiberglass, etc. Such concerns are not unique to any particular project--they pervade all projects. It's simply the background training of an architect/builder/etc. to know these things, to know how to use the material to apply to a specific situation. For an IA, it ought to be no different. I in no way want to demote the importance of content. But I question it's placement here. An IA's ability to structure information exists independently of the business and user needs of a particular project. I guess for me, the three circles seem very project-focused--a business develops a context which informs the "why" of building a site. The users supply the needs that suggests "what" the site should do. The ability to manipulate and structure content is important, but is not specific to this project... I guess I kind of see content-structuring as a cloudy presence behind these two circles, part of the 'general knowledge' that informs all of what we do. (The same could go for capabilities of the technology.)
COMMENT #12 Ultimately it isn't a business context/users needs problem, but the age old problem of how to get two or more people to communicate and form a successful relationship. Lofty goal, eh?
COMMENT #13 is and this "Moreover, the content itself has inherent qualities that require certain architectural approaches. Tutorial content needs a different treatment from white papers. Audio downloads need a different treatment from a database of store locations. These are issues above and beyond business context that merit equal consideration." (cont.) jjgnet: re point 1, you seemed to me to be implying that content was a natural consequence of the biz context. petermhz: content is a consequence of the overlap, yes. within a project, content is not created that hasn't been determined necessary by the business in some fashion, no? (leaving aside the idea of pointing to "external" content) jjgnet: my thinking about it has always been that there are latent streams of information running through every organization. content strategy is about choosing which ones to tap into, and how to transmute what you find into content that meets user needs. petermhz: Well, true. But how is that information being produced? And why? It's a part of someone's job, right? jjgnet: turning information into viable content is trickier than most orgs think. jjgnet: it's not as simple as just wiring the mainframe up to a web front end. petermhz: I wouldn't disagree. But, that's still begs the question, why would an org want to turn info into viable content? petermhz: To make money. To meet some perceived business need. To appease users. petermhz: All of which suggest it would be part of the business context for the project. jjgnet: but there's lots of useless content floating around too. jjgnet: i don't think you can assume a clean correlation between available content and biz context. petermhz: I would disagree, to some degree. Pretty much all available content was developed for a business reason. It might not make sense, particularly in the framework of a particular project, but it does have a reason for being. But yes, the business context of a particular project will suggest which content that is floating around is useful. As will understanding the user needs. But then, it's like there *is* a big content pool sitting behind the two circles, and where the two circles overlap is like a filter or lens on the content that is meaningful for this project. jjgnet: fair enough. but lou and peter describe IA as the instersection of the three circles, so it sounds to me like it's just the visualization you're taking issue with. jjgnet: also: lots of organizations produce lots of content because they *think* it will meet a business or user need. but it really doesn't. meanwhile, the content they should be producing doesn't happen, because of discontiguous systems or political issues, or what have you. petermhz: in large part, yes. i'm wary of things that might muddy up the water by not being, i dunno, precise. i guess i still don't feel that 'content' warrants a placement akin to 'context' and 'users', because while, in the context a project, 'context' and 'users' supply the same basic things (i.e., requirements for a particular project), content doesn't have 'requirements', or, if it does (i.e., tutorials vs. white papers) they are 'requirements' that aren't particularly to the project at hand, but just general understandings of that content. petermhz: also: i agree with you. but i don't think that has anything to do with the three circles. it just means that businesses aren't paying appropriate attention to business needs and user needs. the diagram doesn't address that. jjgnet: re the second point, i'm just saying there are content considerations above and beyond biz context and user needs. jjgnet: re the first point, i don't understand why the nature of the content shouldn't be considered part of the requirements. if you don't bring an understanding of the content to bear on the work, you risk proposing a solution that can't be implemented. petermhz: as gene said, the exact same thing goes for technology. petermhz: should that be a fourth circle? jjgnet: some would argue that it should. petermhz: both content and technology are 'givens' that are essential to understand, but not particular to the project at hand. how you use both will be particular to the problem at hand, which will be defined by business/user reqts. jjgnet: the nature of the content at hand, in my experience, tends to be more project-specific than general. jjgnet: you run real risks by presuming that one company's product support docs (for example) are like another's. petermhz: again, we're agreeing, but addressing different points. i think. it's funny. we're clearly talking in an orthogonal manner to each other. petermhz: i'm not saying that all support docs are the same. petermhz: i'm saying that... what am i saying. petermhz: i'm saying that those support docs were developed as a way for the business context (sell software) meets the user need (get fixes when software doesn't work). petermhz: that those support docs don't exist separately. that support docs aren't just being created for the sake of it. jjgnet: but, once instantiated, content imposes a new set of issues in addition to those that derive from business context and user needs. that's what i'm saying. jjgnet: and, those new content issues are specific to the content that was developed, not general principles (although those exist too). petermhz: what are these specific content jjgnet: structure and integrity are the first that come to mind. jjgnet: i guess integrity is a matter of appropriateness, accuracy, and consistency. petermhz: Structure. Now, this is applying the Ways We Manage Content to this particular body of content, right? Integrity is an interesting one. But I guess I still don't see appropriateness, accuracy, and consistency as being qualities distinct from either the business context (it's important for the business to put out accurate and consistent info (unless they're purposefully misleading, wherein they can use inaccuracy and inconsistency as a tool), and user needs (appropriate for whatever goal the reader is trying to achieve). petermhz: Am I misunderstanding? jjgnet: i suppose there is a sense in which biz context and user needs form the "cloud" behind the content. petermhz: hee. petermhz: Information Architecture -- The Process Of Seeding The Big Boud. jjgnet: what is that compound? silver halide? jjgnet: maybe i'm thinking of polaroid film. petermhz: you are: jjgnet: then what do they seed clouds with? petermhz: http://www.google.com/search?num=100&hl=en&q=cloud+seeding+silver It was clear at this point that Productive Discussion had stopped. One can only prattle on about these things for so long...
COMMENT #14 Sounds like semantics are key here... I usually think of content as physical, and information as mental, both individual and collective. As an Information architect, I think one trys to piece together the knowledge of the business by using librarian methods of examining, cataloging, categorizing the physical artifacts called "content", and other ethnographic methods to get at whats in everyones' heads (users and business). Key idea here is to distill out the "information" from the physical presentation, and then "architect" a new/improved solution to meet everyone's needs. One point I think was alluded to is that the information a business has may be important, but the form it has taken in the past (presentation) may be inappropriate to meet the users needs in different contexts. The challenge as I see it is trying to seperate the information from the content. Just my interpretation... semantics anyone?
COMMENT #15 COMMENT #16 Content and Technology as background/backdrop for the intersection of Business + Users. Content and Technology as separate domains that also intersect with the goals/contexts of Business + Users. COMMENT #17 Your friend happens to sell insurance. You decide to meet for lunch. Your context is "meet with friend for lunch." Friend's context is "sell whole-life insurance policy to friend." It will not be a pleasant transaction. Business entities can assert what they WISH the definition to be, and serve content i.e. marketing crap, on that presumption. But this isn't the 1950s anymore. The user has a context too, and if you misapprehend or minimize its importance, you fail. Whether the business likes it or not, there is AT LEAST a 50-50 relationship. The user context is more than the information goal, the research strategy, etc. I think it is a fundamental expectation of what the interaction should look like, as in the case of lunch with a friend. The responsibilities of both parties, the ethical constraints, and so on. "Information goal" doesn't quite get it, too specific and situation-bound. I would emphasize the user's context far more than the business context in defining the appropriate information architecture. The business context is totally trivial: the business wants your money. The best business sites out there are the ones that have figured out the user's context. Period. My refrigerator broke last night, and damn if I didn't go to the vendor website only to find NOTHING about troubleshooting. Not their problem, I see. Their problem is to take my money and spend it on worthless macromedia splash screens and a pretentious sections on "Corporate Mission" and "Investor Relations." My advice, keep marketing and accounting folks the hell out of information design. They cheapen everything they touch and insult every single visitor. OK now I'm just venting so I'll shut up and leave quietly.
COMMENT #18 Including just a technical element into the initial Venn still leaves a muddied representation of what happens and is needed. There is a balance that should take place with each of the human element actors in this development and production (production would have the technical actor playing a lesser role). How each of the actors interacts with the elements of the information application will be different. Each of the actors is needed and the impact of each of the elements and how the elements interact is paramount to IA. The interface if not providing the proper attraction to the user may keep users that are trying to draw information to their screens from accessing that information. The application can break the attraction between the information and the user also, or it can enhance that attraction. The information/content if written or structured in a manner that is not discernable to the user may break the attraction leaving the information unfindable and therefore unusable. The two Venn's must, in whole, must interact with each other. Leaving elements out of either Venn or collapsing them in to one element breaks the actual actors and elements needed to build any information application (Web sites included) properly. Information Architects need to interact with each element to build the best structures for the information and to ensure the structure of information works across all actors and elements. Keeping this in mind all the components must work together to provide a sustainable inforamtion application that adhere's to the cornerstones of information application development: usable, maintainable, reliable, and repeatable.
COMMENT #19
|
