APR: Information Architecture Challenge

We have an interesting information architecture challenge as part of our agile project. We have talked about browsing and searching articles organized both by category (product management, business analysis, etc) and by level of expertise (beginner, expert). We’re also rating and reviewing the articles, which introduces the ideas of “latest”, “most reviewed”, “highest rated”, etc.

This presents us with a three-dimensional way to approach structuring the information and navigation of the site.

Two Areas of Focus

There are two things we need to address as part of helping people find the articles that they are interested. Searching, which can bypass this structure, is not in scope for the next release of nexus – as we are focusing first on the browsing use case.

The most important element to focus on is the site navigation. A lesser, but also important element is URL structure. There are benefits to having consistent and clean URLs that represent the different pages of nexus. Site navigation is a two-dimensional problem (we have two dimensions within the screen real-estate). URL-creation is a one-dimensional problem – each URL (web-page address) is linear, or even serial. Since URL structure is more constraining, we are tackling this first.

What Does Browsing Look Like?

We’re focusing on URL structure, as it relates to browsing. How does that perspective apply?

A “good” URL will tell us something about the page. For example: http://tynerblain.com/nexus/testing/highest_rated/beginner/ could represent the list of the highest rated articles about testing, written for beginners. This approach to URL structure has benefits in that it provides context for users (who can look at a URL and see where they are), makes it easier to share or save a page, and does a good job of setting expectations.
http://tynerblain.com/nexus/?topic=testing&view=highest_rated&expertise=beginner would provide the same benefits – but it is clunky for people to read, harder to share, and far less memorable. It also forces the implementation on the users. Users should not care if “highest rated” is a view, or a sort, or whatever. There are also search-engine benefits to using the clean URL structure. And luckily, it is actually easy to use the clean structure when working with Ruby on Rails.

When browsing, we have three dimensions:

• Level of expertise (beginner, expert, both/either/neither)
• Category of article (Product Management, Business Analysis, Project Management, Testing, Agile Development, Interaction Design)
• A Chosen approach (view the highest rated, most recent, most rated, most reviewed, or most viewed articles)

Good design approaches will survive changes to this as well (new categories, etc).

Which Comes First?

We can ignore the URL-formatting for a minute, and just think about which sequence makes the most sense. Here are some examples:

• beginner -> testing -> most_reviewed
• testing -> beginner -> most_reviewed
• most_reviewed -> testing -> beginner
• most_reviewed -> beginner -> testing
• beginner -> most_reviewed -> testing
• testing -> most_reviewed -> beginner

I believe that the beginner/expert dimension is the least important of the three. I also think that the category “filter” is the dominant element when users are browsing, and the “let me slice it this way” dimension of ‘chosen approach’ is subordinate. I would expect a person researching testing articles, for example, to look at both the “highest rated” and the “most reviewed” views within a single browsing session. I think it is less common that someone would be viewing “highest rated” articles and change category to category as part of the same exercise.

So, we’re going to start out with category->approach->expertise as the winning information structure for URLs.

Consistency Matters

Once we establish a hierarchy of category->approach->expertise in our URL structure, we need to make sure that our site navigation reflects something consistent with this. Therefore, navigation elements should present category information/filtering in a dominant position, and the chosen approach (most rated, etc) as a subordinate. The expertise level should be below both of these.

In truly agile fashion, we’re implementing category->approach first, without mixing in the expertise element into either the URL structure or site navigation. We are showing it as information. When this matters more (more than whatever else is being prioritized), we will re-address it.

Thoughts?

What do you think?