Introduction

Users of an information system have an information need. It's the information architect's work to help these users "to complete tasks and find information in blissful ignorance of [their] labours" (Peter Morville and Louis Rosenfeld).

Information needs to be organized to be helpful to the users of a system. And there is even more to it:

We organize to understand, to explain, and to control.

Peter Morville and Louis Rosenfeld. Information Architecture

This is very important: Since we work in teams of software developers, we need to get used to the fact that communication and organizing information help us to understand our domains better. Finally we yield better results: happier users, happier stakeholders, and happier teams.

How can information architects help users to find without searching? How can team collaboration on information help to understand the domain more thoroughly?

To answer this questions we will take a theoretical and a practical approach.

• In this article we examine the types of searching and ways to organize information. This is the basis for our practical considerations.
• In the next article we will provide a more practical approach on how to apply this theory on a Confluence wiki using projectdoc. We look from the perspective of software development teams to create their project documentation collaboratively.

The goal is to learn how to organize project information effectively. While we aim at software developers with the need to document their projects, software and system architecture, this article is probably also relevant for other teams that work on other kinds of projects collaboratively.

Seeking Information

Searching for something you know is a very different behavior than browsing for the unknown.

Peter Morville and Louis Rosenfeld. Information Architecture

First we - as providers of information - need to understand the different types of information seeking users perform.

Enable Seeking

We are looking for a solution for this notion of finding without searching. We need to present a link to a path to pursue for all questions a user may have in a given context. Sure this is not a reachable goal, but this requirement defines a motto that gives us a lot of direction. Without creating an information overflow on the user's side we are up to provide pointers to related information.

What can we do to support our users with their task of information seeking?

• In the case of Searching we attach a search field to every context and employ our wiki's full text search capability.
• According to Asking this is also quite easily accomplished: we add a reference to a person (with her address and contact options) who assist the reader in a given context.
• The amount of work to support Browsing is much more. We need to create relations between the information we present in our wiki. These relations will help to navigate through the wiki spaces.

Classifying

On classifying information we also relate them. With each relation we enlarge our web of information, enabling users to travel from one topic to another related information.

When we define an organization structure we often use the top-down approach. We arrange the information hierarchically and speak of taxonomies.

The beginning of all understanding is classification.

Hayden White

In the sense of Aristotle's Definition of Definition this process of classification makes us understand the terms of our domains. To define a term we first have to put it in a broader context, that is: put it to the class it belongs to.Then specify what distinguishes it from all other elements in this class. In the context of a taxonomy the upstream terms are generalizations, the downstream terms specializations.

Labelling information is a bottom-up approach for organizing. Every resource of type 'Podcast' has something in common. Every topic labelled with 'Java', too. Although these classifications are rather generic to be useful by themselves, they help to specify quite specific queries as in "List every resource of type 'Podcast' labelled with 'Java'".

Once the information is classified, it can be applied to enable browsing. Use automation to render links to relevant information on search criteria. In Finding without Searching - applied! we will have a look on how Confluence and projectdoc supports us on this task.

Conclusion

This short article puts together the types of information seeking and the seeker's behaviors. We then had a look on how to enable users to seek information. While providing means to search for a particular term or ask an expert may be accomplished easily, relating information is a more complex task. But once classified, we can create links to related content more easily.

Working together as a team and organize our domain information will support us to understand our problem domain more thoroughly and to create a proper solution.

Next we will see how to apply this theoretical approach to your Confluence wiki using projectdoc.

References

If you like to learn more on information architecture or Hans Jürgen von der Wense, read:

• Information Architecture by Peter Morville and Louis Rosenfeld
• Information Interaction Design: A Unified Field Theory of Design by Nathan Shedroff
• The quote "I find and find, without ever searching" is from Werke 2, p. 1232: "ich finde und finde, doch ohne jemals zu suchen", Hans Jürgen von der Wense