We've come to understand Information Architecture (IA) as the practice of structuring information (often according to context) for a particular purpose. Tom Johnson and Donna Marsh circled around this definition last week. From their discussion, it seems that defining IA is problematic because it is most commonly applied to web development. However, from Donna and Tom's experiences (and those of others) it's quite obvious that IA also applies to disciplines such as TC, software programming, and user experience design (Peter Morville has said as much about a decade ago).
To complicate things a bit more, an alternate popular definition of IA exists within the field of information system design, where IA refers to the analysis and design of blocks or chunks of information (and their inter-dependencies) within a system. Beth Mazur has used this definition in her efforts to draw distinctions between IA and information design.
The practitioner perspectives that Tom and Donna provide and the academic definitions that Morrville and Mazur provide are built on features of information interaction, content analysis, classification, information hierarchies, information navigation, and information structuring for particular purposes. It seems to me that if I can invoke TC practices that include these features, I can illustrate to my students a range of practices that will help them understand the complexity of their design activities. For this purpose, I need to begin by locating design activities, as an aspect of IA, within TC practices and embedded engineering writing instruction.
No comments:
Post a Comment