Why bother with information architecture? — RenaissanceCMS. I was happy to be asked to write something on information architecture generally for Rob’s blog. It’s easy to forget that not everyone takes for granted the usefulness of IA, so I have tried to inspire people who aren’t sure what it is or what it can do.
Rob creates charming ethereal designs as well as working on marketing, branding, and visual identity and being generally ethical and sustainable. I particularly liked his latest post on tagging. I tend to approach folksonomy from a management and retrieval point of view, and so find myself arguing that just because it is cheap, doesn’t mean it can replace all other KO systems. However, I have been thinking about image retrieval, and one area where social tagging is useful is in labelling vague and abstract ideas like “mood”. If most people tag a photo as “sad” or “mysterious”, that is probably going to be useful for creative people who don’t need a specific image but are just after something that evokes a “feeling”.
Information Architecture for Audio: Doing It Right - Boxes and Arrows: The design behind the design. Another gem for the ever reliable Boxes and Arrows. The article highlights differences in the way that users interact with text and audio and sets out techniques for improving delivery of audio. For example, starting off a piece of audio by saying how long it will last and a summary of its content is helpful, as you can’t scan audio in the way that you can scan text.
Pace layering in ia is a paper by D. Grant Campbell and Karl V. Fast from the Faculty of Information and Media Studies, University of Western Ontario. They bring pace layering theories from ecology and environmental science into information architecture, viewing ia as an “ecology”. Basically, ecologists have noted that events occurring over different timescales interact to affect an environment - something like the lowering of the water table would be a slow event, but a flash flood would be a fast event. Only by looking at the ways these differently “paced layers” interact, can you predict how the local environment will respond. They propose that the underlying ia of website, with taxonomies and embedded nvigation structures etc., is a slow layer but that folksonomies bubble away as a fast layer of the site, changing rapidly and responding quickly. They suggest that the most stable structure will be one that can accommodate both fast-moving and slow-moving layers and that the slow layer must be robust and flexible enough to adjust itself to pressures from the fast layer.
I don’t think I have grasped all the implications of this, but my first impression is that it fits well with the “best of both worlds” approach - encouraging social tagging but not relying on it for critical information management, while using the folksonomic tags as feedback for updating and reviewing taxonomies.
Getting Started in Information Architecture for the Web contains some handy tips for novice information architects.
Edited by Alan Gilchrist and Barry Mahon (Facet; 2004). There were a couple of chapters on taxonomies. The book provides a very easy to read selection of essays from industry practitioners covering a range of IA themes. Problems for multinational taxonomies included the differences in English language usage and company structure between US and European companies.
In arguing for investment in IA, (page 196) “reducing search time and frustration, enhancing knowledge sharing, are goals whose performance can be measured. Reducing the risk of litigation or of losing customers may also be used as sound arguments.”
I found this to be a useful article on usability issues.30 Usability Issues To Be Aware Of | Know-How | Smashing Magazine
There is a handy glossary and a lot of comments. I particularly liked the way you can assign meaning by juxtaposition. I come across this all the time in text and it’s interesting to see it works just as well - if not better - purely visually.
This was a dinky little podcast on
A fairly light and simple introduction but with a couple of good examples.
I particularly liked the description of information architecture as the art of digital librarianship.
No taxonomy blog would be complete without a link to this:
Understanding information taxonomy helps build better apps.
It seems to be the article that everyone comes back to (or starts off with). A clear and simple explanation of how taxonomies form the backbone of most information architecture. I also noted a couple of good points about how the semantic web won’t run without them – a topic I intend to return to!
I have just read Eric L Reiss’ s book Practical Information Architecture (Addison Wesley; 2000). It seemed like a decent and sensible introduction to the subject, but it’s such a fast-moving area something written 7 years ago seems desperately old already. I picked up a few useful tips - for example it’s a bad idea to string several single word hyperlinks together, as people ignore the spaces and punctuation and assume it’s all just one big link and they also tend to ignore very short single-word hyperlinks, presumably because it is hard to guess what extra information the link will provide. Not something I’d thought too much about in an online context, probably because it’s not something you see so much now. In the early days of the web, people went a bit hyperlink crazy and it is very frustrating to click a link to find the only extra information you get is a dictionary-style definition or reams of related but not relevant information. As a reference editor, I was trained to include only relevant and helpful cross reference links and to think about the extra value following each link would provide to the reader. With a printed product, it is (comparatively) hard work to look up an article on a different page, so editors try very hard not to send people off on wild goose chases. My impression is that web editors are a lot less gung-ho with links now than they used to be.
Reiss sets out some useful project management guidelines for big web projects as a series of ‘a’s: allocate (resources); analyse (goals, audiences, etc); architect; accumulate; assemble; adjust, etc. which seemed a little contrived, but the basic stages are probably a reasonable starting point if you have never handled a big project before. Establishing clear goals for what the site is trying to achieve is probably the most important task and one that can easily get lost if lots of different “stakeholders” or departments are all throwing their two penn’orth into the mix. Managing the politics of conflicting desires and demands seem to me to be a bigger problem than handling the technical aspects of the project, but then I am usually more at home with logic than power gaming!