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!