Algorithms, routines, and programs come into being as elaborations of an already conceived design. That design may evolve based on understandings we gain during its implementation, but we cannot write even a single line of code until we have some conception of how the program will work. The same can be said for data structures. We quickly form a sense of the key domain objects and their properties and relationships to one another, and this guides even our earliest design and implementation efforts. The design of application objects, and the underlying data structures and algorithms are well taught in computer science courses.
The advent of HTML, browsers, and the world wide web has given rise to new (and very different) classes of application that are more dominated by content (information to be displayed) than functionality (services to be performed). Because web sites are so easy to build, they often start out as an assembly of content, whose structure is added in afterwards. For simple web sites, this may be an economical prototyping approach. For more complex web sites, it can result in poor usability and considerable rework.
The same skills that we apply to develop a system architecture can be (very profitably) applied to the task of structuring content-rich applications. This paper is intended as a superficial introduction to the emerging disciplines of Content Modeling, and Relationship and Navigation Analysis.
In this paper, I will use the term "application" rather than "web site" to describe the things we are designing, because the principles apply equally to any content-rich application, whether it is implemented via HTTP/HTML or code and GUI.
We begin by defining what the "content" portion of our application is. There are two general approaches to this problem:
These two approaches are actually high complementary, with the former approach generating a list of content that must be accommodated and the latter generating a structure into which it can be organized. Elaborating this model (e.g. as a UML class model) will bring us to a better understanding of the various content-subtypes, and the attributes associated with each. Note, however, that there may not be a simple one-to-one mapping between content-subtypes and user-view objects. In such cases, it is critical that the mapping from user-view to specific content items be well defined.
The content model should be reviewed:
The next step is to map out all of the relationships among objects in the content model. Many of these relationships will be obvious (aggregation, composition, and direct reference). Other associations may not be obvious from the basic class hierarchy, but may be implied by use cases (e.g. the ability to get from a customer to any order that customer has submitted).
Relationships among obvious application domain objects (e.g. items in a sales catalog) are not difficult to map. For some content, however, the structuring relationships may be less clear cut (e.g. how we might organize music or family pictures). In such cases we must look for inherent sub-classes (e.g. musical pieces in the same genere, or by the same performers), or we may even have to make up an organizational structure (e.g. vacation pictures by trip, family pictures by event, etc). What ever axes we choose to sub-class our content and establish interconnections must make sense in the world view of our intended users.
This process may lead to the breaking up of composite objects into distinct sub-pieces, or the creation of new association classes to represent non-obvious relationships. Each of these must have a rational mapping into the users' world view. The result of this process will be a richer version of the content model, which must again be reviewed.
Once we have (what we believe to be) a fairly complete model of the content objects and their relationships, what remains is to propose the mechanisms by which the implied object hierarchy will be navigated.
Deciding how users will navigate the object hierarchy breaks down into two (largely independent) sub-analyses:
Some objects will be primary entry points into the hierarchy:
Just as some objects will be viewed as primary, so will some interconnections. From our use-case scenarios, or perhaps just from our understanding of the object model, we can identify some relationships that we expect to be traversed "all the time". These must be recognized so that we can give them a clear visual representation, and a traversal mechanism that involves a minimum amount of user effort (e.g. a short mouse movement and single button click).
Other interconnections will be designated as being secondary (not all the time, but regularly) or tertiary (only used in exceptional situations). Knowing that a relationship is tertiary gives us the latitude to represent it in a less obtrusive way (thus reducing visual clutter) or to require more elaborate interaction in order to traverse it.
Note that in this process, we may find that we create new objects, relationships, and navigational requirements. Suppose that a search can return a long list of objects (e.g. recipies). We will need a way to browse that list (forward or backwards in large or small increments) as well as a means to select desired recipies. Thus, even if we didn't consider "list of returned recipies" as an class in our original model, that class might well emerge as an artifact of decisions about how to select and navigate a large database of recipies.
The available navigational idioms (links, tabs, action bars, right-click menus, etc.) may be fundamentally constrained by our user interface technology, and further limited by the basic User Interface design. The selected user interface technology and toolkit will support only certain types of widgets, and our choices are limited to these. There may also be a higher level product style-guide that dictates whether we should use (for instance) tabs, menus, or action bars.
From the available widgets:
The quicker and more central mechanisms should be used for the most commonly followed paths. The peripheral mechanisms may be better suited for less common actions and relationships. More obscure and complex interactions should be reserved for exceptional situations. It is not sufficient, however, to merely assign widgets to relationships in a way that minimizes hand motion. If the proposed user interface is to be learnable, there must be a consistent set of principles that determine which types of relationships are mapped onto which types of widgets. In similar situations, users should be presented with similar options with similar placements and representations. Consistentcy of organization, metatphor, placement, and presentation make a system much easier to learn and use. In all cases we must ask whether or not it will be obvious to the user what is options are, and how to accomplish all reasonable (at this juncture) objectives.
We must also consider how the user can reverse each decision, or recover from an accidental mis-choice at any juncture. It would be unfortunate if one misplaced mouse-click could result in data loss, or necessitated a long and complex series of interactions to get back to the place where the error was made. Sometimes, the answer may be to do all navigation on a stack, and to provide a "back" operation to return you to the previous state and contents. We may decide that a stack only makes sense for a few relationships, but we still have to consider how a user will be able to recover from mistakes like following the wrong link.
We use methodology to guide us through processes that are too complex or critical to be trusted to chance. A content-rich application whose content parallels an obvious world-view will be easier to understand. Navigation that has been designed with consideration for the full range of relationships, and the manner in which users are likely to want to traverse them is likely to be more convenient and intuitive.
The application of content modeling, and relationship and navigation analysis to such problems can help us to reliably achieve these goals.
A more complete discussion of Content Modeling can be found in a 2001 paper by Sridhar and Mandyam, "Effective Use of Data Models in Building Web Applications".
Relationship Navigation Analysis is a much richer field than is implied by the simple suggestions made above. A (non-trivial) introduction to the richer subject can be found in a 2000 paper by Yoo and Bieber, "Toward a Relationship Navigation Analysis" .