ProgrammersAsInformationArchitects
ThoughtStorms Wiki
Browsing the new edition of InformationArchitectureForTheWorldWideWeb I'm struck by the authors' dismissal of similarities between InformationArchitecture and SoftwareDevelopment.
Whereas many other professions are allowed insights into information architecture, the book merely says "People rarely confuse software development and information architecture ... developers help us understand what is and isn't possible." And later on "Programmers are often excellent at modelling content and metadata for inclusion in a database. They're also great at figuring out how all of the component systems and technologies ... fit together."
In other words, programmers play the same role with respect to information architects as structural engineers play to real architects.
But here are a couple of thoughts on why programmers should make good information architects :
- 1) First, programmers with any experience are familiar with the most fundamental problem of all system design. How to square informal requirements, as understood by humans, with a formal system that can be implemented in a computer. They know that messy compromises and negotiations are going to have to be made here.
- 2) Further, most experienced programmers have done (and probably trained in) user and activity requirements capture. Just as every generation thinks it discovered sex; so every generation believes it discovered the user, and attentiveness to her requirements. There are differences in who the user is and the interface, hence systems analysis is different from HCI is different from web IA, but the overall strategies remain the same. There's more similarity between the kinds of ContentContextUser approach described in IAFTW3 and a good old fashioned systems analysis technique like ChecklandMethodology's CATWOE than between IA and graphic design, usability or experience analysis, architecture or project management.
- 3) Programmers are already used to the idea of organizing information for a purpose. On the micro-scale this happens when they pick an appropriate data structure. Are they optimizing for speed or size? Is it better to use broad or deep trees? Link a list in both directions? Expend memory on another index to speed things up? These decisions are all about findability of information. It's just that the agent doing the finding is the program itself. In the database, similar decisions are made. Is this organized for transactions or datamining? Is this piece of information in table X queriable with only two joins from these indexes?
- 4) Programmers already manage and navigate through a fairly large and complex corpus of documents : their source code. This can often consist of hundreds of classes, each in a separate file. Or think of it as thousands of interlinked and interdependent subroutines.
:To cope with this they've adopted many information architecture strategies :
** metadata (typing, reflection),
** controlled vocabularies (variable and method naming conventions, namespaces)
** synonyms (#define)
** classification schemes (methods belong to interfaces belong to classes belong to modules or frameworks)
** prefered terms (facade pattern)
** broader and narrower terms (class hierarchies)
** faceted classification (multiple inheritance, polymorphism)
I'm not trying to argue that software people come pre-trained as Information Architects. But, apart from actual librarians and information scientists, it's hard to see how any other profession can be more familiar with or more habitually engaged with the problems and solutions of information architecture. If you need to train someone from another profession to be your IA, your skilled programmer is likely to be the best bet. (Though remember the DevilIsInTheDetails)