the iCite net > news / blog > a permalink

news and thoughts on and around the development of the iCite net
by Jay Fienberg

Information architecture as a product feature

posted: Nov 21, 2003 1:50:34 AM

Having worked with a lot of information tools of various genres ranging from content management systems, knowledge management systems, collaboration and personal publishing tools, I think it is safe to say that a feature of each tool is its information architecture (or, its general concepts about how information should be organized and worked with).

I think it is something of a "dirty secret" that these tools tend to fail to offer an up-front way to evaluate their information architectures. And so, consequently, when we get into these tools, we soon find ourselves both working hard to figure out their information architecture and also how we will match up our own information ideas / requirements with those assumed and/or fixed by the tool.

As a simple example, before choosing blojsom as the tool / system for this blog, I tried blogging using three other tools. Each of these tools, for example, in their own ways, had very specific ideas about: 1) the relationship between the blog and other pages I might want to have on my website, and 2) the nature of how old posts would be organized in an archive.

So, it was through trial and error that I learned that these three blog tools: 1) assumed the blog to be the home page and no web page senior to it, and 2) saw all past posts as organized only by their date (i.e., specific day).

(This blog lives within a larger site, and the post archive is organized by month now, and will later also be organized into faceted categories.)

I imagine that I could tweak to my requirements these three blog tools that I chose not to use. But, the main issue for me was that I was having to do a lot of work to figure out these information architectural assumptions.

What I liked about blojsom was that I was able to very quickly figure out these assumptions, and also that they were significantly minimal with regards to the areas where I wanted the most flexibility.

However, in any case, I imagine it would be possible for any of these tools to be expressed in terms of information architecture concepts (e.g., navigation systems, labels, taxonomies, etc.). And, I also see an important feature coming out of this as well: the componentization of a tool along the lines of its information architecture.

So, what I envision is being able to look at a tool / system, without owning it and spending dozens or even hundreds of hours test driving it, and get: 1) a picture of its parts in information architecture terms, and 2) a picture of which parts can be removed and which parts can be easily used as components in other systems—again, in information architecture terms.

A web service-y example would be taking a set of categories from one system, say SharePoint, and being able to use them in another system, say SocialText. That is an OK example, but it makes you think about application services more than information architecture.

I think a better example of what I am getting at is: being able to take the navigation system from MoveableType and use it around SharePoint. And, I don't just mean web services or links between two different web-based interfaces—the issue is that both of these products are significantly coupled to their own navigation systems.

It may not be possible, and it may not even necessarily make sense, to uncouple these things. But, that kind of fact is the kind of information architectural assumption or choice that these products could express up-front. In other words Microsoft could be saying, "we have created a highly integrated information system good for such and such, and so here are the specific parts that always are connected together in our system".

I am very interested in social software and collaboration tools, but I think there are specific information architecture oriented features of these tools that are going to become more and more important. The ability to re-use not only categories and search, but also things like navigation systems and labels, between systems, is going to be a big deal.

I think, eventually, businesses will see information architecture re-use in a similar perspective as data and code re-use. Like, a company now probably would create a RDBMS fronted by an application in some modern programming language, having some sense that they could change vendors and preserve at least the concept of their system.

Right now, when you change information tools, you often have much less portability of information architecture. If you are moving your information from Outlook to your file system to a wiki to a content management system to a portal, each time you will at least re-build your information architecture—and usually, you will need to significantly redesign it to match the constraints of the new system, which you will need to labor-over intensively to understand.

Anyway, one inspiration for the iCite net is that I imagine iCites will work as tools for publishing information architectures in human and machine readable formats (and, no, I am not trying to create a markup language called IAML!). And, I think even more importantly, iCites will allow the componentization of information architectures, and a medium where those "skeletons" can exist autonomously of the interfaces that use them.

So, for example, someday, someone could take parts of the sitemap for this site and parts from another site, plus a little search taxonomy, and combine them into the skeleton for a new site. People do this kind of thing already, by hand. But I imagine this being directly puggable into future systems.

(I also imagine this in no way lessening the need for information architects! Just because you yourself can measure the size of a sub-zero refridgerator and roll it into your house doesn't mean you'll never need an architect to design your kitchen!)

permalink | comments {0} · trackbacks {1}

also available as: rss · rss2 · rdf · atom

Comments and Tracbacks

trackback from: the iCite net development blog
posted: Apr 13, 2004 8:24:55 PM
title: Idea for an article on information architecture

I am thinking about writing an article about the information architecture embedded in the templates / processes of web tools / systems (of which blog tools could be one case). Here is what I have sketched-out so far as a kind-of intro / outline

Note: All comments and trackbacks are moderated. Spam is deleted. Other comments are approved as promptly as possible.

Note: Older posts no longer accept new comments or trackbacks.

« prev post
S.P.E.W. factor

» next post
Mobile hacked, blojsom WAP

blog newsfeeds

brief content:

 XML  ·  RSS  ·  RDF  ·  Atom 

full content:

 XML  ·  RSS  ·  RDF  ·  Atom 

blog archive

jan · feb · mar · apr
may · jun · jul · aug 
sep · oct · nov · dec
jan · feb · mar · apr
may · jun · jul · aug
sep · oct · nov · dec

jan · feb · mar · apr
may · jun · jul · aug
sep · oct · nov · dec

may · jun · jul · aug
sep · oct · nov · dec

first post: 
April 30, 2003

highlight views:
Spammers' Choice

Jay elsewhere online
Jay Fienberg - the official home page

Wrong Notes - the music blog of the Ear Reverends

Fine & Full, aka, a fine and full burger

Sociomobilepoetextologia (moblog, currently inactive due to lack of proper mobile)

to enjoy roll
sites I like to read when I start from here

· Anastasia Fuller
· Andy Baio
· Biz Stone
· Boris Mann
· Bre Pettis
· Chris Dent
· Danny Ayers
· Dare Obasanjo
· David Czarnecki
· David Weinberger
· Don Park
· Evan Williams
· Greg Narain
· Jason Kottke
· Jim Benson
· Lucas Gonze
· Marc Canter
· Matt May
· Matt Mullenweg
· Michal Migurski
· Nancy White
· Rebecca Blood
· Reg Cheramy
· Richard MacManus
· Sam Ruby
· Shelley Powers
· Tim Bray
· danah boyd

powered by blojsom

Entries by blojsim