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?
I like the thought processes you’ve put into this decision on IA. I’m not sure I agree with the final navigation, though.
I would go more towards category->expertise->approach. The reason being that if I am visiting the site, I have categories of interest that I am likely to focus on. Next, I would likely wonder which articles in this group are most suited to me, hence my expertise level. Third, I would want to know which articles within that expertise level are “highest-rated”, “most-reviewed”, etc.
Just my 2 cents :-)
Hey Bob, thanks for the feedback! Looks like we’re tied (one vote from you for c>e>a, one vote from me for c>a>e. Maybe some other folks will add their coins to the fountain…
One other person suggested in email that for a given context, we should show the number of articles in the link. Something like “Agile Development (23)”.
Thanks again!
Scott,
Maybe you and Bob can both be right.
Have you considered using faceted navigation? Faceted navigation means that level of expertise, category of article, and chosen approach can all live at the same level.
Therefore, as a user, I can pick the facet by which I want to begin navigating the site. For some, level of expertise is the most sensible place to start. Others will want to begin their search by category or even chosen approach.
Why not surface all of them and let your users pick the most appropriate starting place?
Here’s a good example of faceted navigation:
http://browse.guardian.co.uk/search
Here’s an example from Home Depot:
http://tinyurl.com/2zoh5q
What do you think?
Scott
Hey Scott,
That’s awesome! And it scales a lot better, eventually supporting N-dimensions. I love it.
As it turns out, I implemented an approach that works the same way as the guardian site, although it doesn’t look like it in the presentation (yet). Another benefit of the MVC paradigm, I think I can change the presentation without having to rework the guts. I’ll write about it now for the next article.
Thanks VERY much for helping with the ideas – it is suggestions like this one and others from our readers that will make nexus awesome.
I tend to ignore the URL problem. To me, an URL is just that and not a way to learn something about the page. I find it much more convenient to have a “non-speaking” URL than to have a speaking URL that does not exactly fit what I see on the page itself (maybe I see my set filters there, but the URL tells me a different story. Huh?)
IMHO, navigation should be handled on the page, not the URL.
The only occasion when I use URLs for navigation is when a site does not provide any useful navigation on the page itself and I believe that I can go “home” for example, by deleting everything after the *.com/.
Thanks for sharing your perspective! More user understanding is better. Just so I’m clear – are you saying you ignore the URL stuff (mostly) and rely on the page navigation? Or are you saying that the “speaking” (or friendly, as the web-developers call it) URLs detract from the site in some way?
You are correct, Rolf, that navigation should be handled by the page. Unfortunately, designers can’t always be counted on to implement that properly on complex sites. I see having friendly URLs as providing additional usability in the form of a “default” breadcrumb trail for the user. Not to mention the fact that search engine spiders appreciate friendly URLs much more.
I rely on page navigation most of the time. “Friendly” URLs don’t detract, IMHO they are only useful to the user if there is insufficient page navigation. (BTW, the term Friendly URL is part of the problem: friendly towards whom?). I can see the spider’s point, though.