It’s time. Once too often we’ve found ourselves saying, “How come I can’t find anything?” When that happens, we have to clean our room, or sort through the old boxes – or, in Ohloh’s case, redo the information architecture (IA). We knew for sure that it was time when we wanted to add a new feature in Ohloh and couldn’t figure out where to put it.
The first phase of Ohloh’s IA redo, which is being unveiled today, focuses on the project pages. Our guiding principles were to:
- make it easier to find, peruse and digest data both within one project and across multiple projects, and
- keep the IA flexible enough to support our future growth plans.
Project Home Page
The first things we talked about were the target users and their motivations. We quickly discovered that we had to reconcile two competing needs – needs that reflect the classic dichotomy of the forest and the trees. The first need is for decision support when people make a choice among open source projects. These “forest people” want to evaluate whether a particular project fits their needs. We have to provide condensed and rolled up summary data to help them answer questions like, “Does this project fit my risk profile?”
The second need is for monitoring of open-source projects by managers, contributors, and other project stakeholders. These “tree people” look for specific answers to a variety of questions which can be found either in detailed historical and trend data, or in the value of one very specific data object. Our job here is to connect the “tree people” to the specific data they require with a minimum of effort so they can quickly answer questions such as, “Who are the significant contributors to my project who haven’t claimed commits yet?” and “Who made the last commit that contained Java?”
Solving the problem of how to satisfy both needs led us to one of our primary design goals. We would choose and group relevant data from all different parts of the project pages and design them into a project summary page so that:
- “forest people” would be able to find their holistic, aggregate data without needing to go any deeper;
- “tree people” could use the summary information as a quick visual and cognitive guide to find data they want to drill into easily and consistently; and
- most visits (about 80%) could be completed using just the summary page
Because our plans call for the vast majority of visits to be completed without the need to drill deeper than the project pages, we wanted to devote as much pixel “real estate” as possible to this summary content. We noted, of course, that the traditional left-hand navigation takes up a lot of real estate. So we asked jokingly, “Why do we need navigation anyway? It’s overrated.”
All cheekiness aside, navigation serves three purposes. Most people think of navigation as the place to click to another page. But if you think about it, you’ll probably recognize the second purpose, which is to provide a “table of contents” that tells users what they can expect to find where.
The third purpose of navigation is much more subtle. Navigation helps users understand the bounds of the content. Imagine you go to a big-box store looking for tiki torches. The store is huge and you don’t even know if they carry tiki torches. You consider walking up and down every aisle in the store, but that would take over an hour and you’d be so bored you’d probably miss the torches anyway. Instead, you consult a map of the store’s departments and you spot a few places where they might have tiki torches: garden center, outdoor patio, novelty items, and casual lighting. You’ve just set yourself some bounds – if you don’t find the torches in any of these departments, you’ll go to a different store. But given the ambiguity of the department names, you might very well leave with a nagging feeling that those torches might have been in the international department.
Clearly understandable navigation conveys the bounds. The clearer the navigation, the clearer the bounds and the more comfortable we are in assessing what’s here and what’s not. In fact, when people first get to a web site or to a significant section such as Ohloh’s project pages, they often look at the navigation before anything else to figure out if the data they’re looking for are present, if so where.
But remember our design goals? Our aim is for 80% of visits to be resolved on the summary page, without the need to navigate elsewhere. That means for 80% of the visits, spending time parsing the navigation would essentially be a distraction. So when users first come to the summary page, we want them to look at the content first, before the navigation.
So, we put the navigation at the bottom of the page. This did two things: it freed up more real estate for content, and it encouraged our users to look at the content of the project summary page before being distracted by the navigation. In our tests we found exactly that – that when users could complete their tasks on the summary page, they never even got to the navigation at the bottom.
Putting the navigation at the bottom works great for “forest people,” but what about the “tree people”? We designed the roll-up data displays to guide these users to relevant drill-down links by adding lots of contextual links to more detailed information. Users who are scanning the project summary page for detailed information will be drawn to data displays that that matches their interest. As they parse the display, they’ll notice the keywords directly related to the content they’re looking for. Clicking these linked keywords will take them directly to the more detailed data they seek without shifting their thought process.
In our user tests, subjects gravitated to these embedded links without pause. In fact, they took to them so well that that they rarely clicked on the bottom navigation at all. So does this mean that the bottom navigation really is useless like I joked earlier?
Red-shaded areas are clickable – drill down with one click
Let me clarify – our test subjects actually used the navigation quite a bit – just in a different way. They would scroll down to the bottom navigation, study it for a bit, and then scroll back to where they were. People used the navigation; they just didn’t click on the navigation.
It’s useful to note that we told our subjects that some of their tasks could not be completed because of lack of data. In other words, they didn’t know whether or not they would be able to find the content for their given task. Recall the second and third uses for navigation discussed earlier, content summary and bound setting. As our subjects looked at the navigation, they were probably studying the content, and figuring out bounds of the site – narrowing down their options just like the shopper looking for tiki torches.
As users become more familiar with a site, they generally refer to the navigation structure less and less often. That’s because they build a mental model of how the information is organized. If you went often enough to the big-box store we discussed earlier, you’d start to remember that they keep food in one area, clothing in another, and power tools in a third. The clearer the boundaries between the sections of navigation, the easier the mental model will be to intuit and to learn. Of course, there’s rarely a perfect mental model for navigation, but part of the art is to create a mental model that works well most of the time.
For our mental model we looked to Ohloh’s role of acquiring, consolidating and presenting data from what I’ll call the “open source ecosystem” – a system in which some people contribute to open-source projects by committing code to source control management (SCM) systems, others download the code for use in some capacity, and still others encourage and nurture the projects.
Our expectation is that the bulk of people who use the project navigation will be “tree people” drilling for more detailed information, and that these people will be familiar with different parts of the open source ecosystem described above. We therefore chose to represent the ecosystem in our navigation structure by surfacing four subsystems: Ohloh itself, the code, the SCM, and the people who write and use the code.
We’ll use this same model when we expand project page navigation to include more content. For instance, new data about code quality would go in the code section. Community metrics automatically gleaned from mailing lists, IRC channels, forums and similar sources might be added to a new column for communications, because that represents another viable subsystem.
In addition to the big things discussed earlier, you’ll see lots of other improvements to the project pages in this release. However, as with any phased renovation, you’ll also see some anomalies while we’re working to rehab the entire IA. For example:
- The other sections of the web site will continue to use the original IA, including left-hand navigation, until they are redesigned.
- We haven’t finished putting data displays into the project pages, so if one of your favorites is currently missing, let us know.
- We haven’t systematically addressed the usability of each data display. Our focus was to get a good navigation structure out there first, and then to refine the usability of individual displays and pages.
Our goal right now is to get feedback. We’re pretty sure we’re on the right track, but we’re equally sure we made some blunders along the way. We also know that the best way for us to make the site better is by getting you, the Ohloh user, engaged in the conversation by either commenting on this blog post, adding a comment to the Feedback Forum on Ohloh, or by clicking on the Support link at the top of the Ohloh Meta site.
Tell us what you do and don’t like, and what you want to see in the future. Give us praise or scold us, but please let us know what you think.