Re: Navigation Proposal

[Michael Bernstein <webmaven lvcm com>]

Sorry it's taken me so long to reply, last minute holiday
preparations can be a pain.

Joakim Ziegler wrote:
> 
> On Wed, Dec 20, 2000 at 09:31:56PM -0800, Michael Bernstein wrote:
>
> Basically, there are two separate issues here, which I think we're confusing
> a little. First of all, there's the discussion of whether or not we should
> use a hybrid task/category scheme, or a pure scheme. Secondly, there's the
> issue of four top-level categories being too few, in my opinion.

I'll address them separately from now on, too.

> Now, for the hybrid versus pure issue, sure, it's fine to have a pure schema,
> if it's possible, and doesn't deform an otherwise logical tree. For instance,
> you've created four top level categories which seem to be able to hold all
> the information we have on the site. But is it possible to continue with a
> pure schema on the second level of navigation? How deep will the tree be with
> this method versus a hybrid schema? How wide?

Of course it's possible. All content has a subject/topic.
I'll post a follow up message with a complete tree as an
illustration.

> I'd argue that particularly since hybrid schemas are so common on the web,
> people are used to them, and don't have to expel much mental effort to figure
> them out.

What you're really saying is that people don't bother to try
and figure out an overall site structure, because on most
sites they can't anyway. I don't disagree with *that*, but
just because everyone is doing it wrong, does not mean we
have to follow suit. If following the guideline of
preferring a pure scheme results in an improved user
experience, then I say we do so. If we wanted to accept the
status-quo, we wouldn't be interested in GNOME in the first
place.

> As a thought experiment, take your four categories and turn two of
> them into tasks (pretty easy, just put a verb in front of the noun, like
> "Learn about the GNOME Foundation"). It's not much harder to figure out
> (ignoring that the label is long and unwieldy). It seems to me that the
> usability difference is vastly larger from adjusting the boundaries between
> categories than it is when adjusting between hybrid and non-hybrid schemas.

Mmm, I think you're confusing the issue here. What you've
created is a noun/verb pair, which is a very specific
combination. To make it an equivalent to the more inclusive
'Development' task category, you would have to label it
'Learn', after which the question naturally arises "learn
about what?", which is answered in appropriate
sub-categories, all of which then overlap in content with
existing topical categories again (Learn about GNOME, Learn
about the GNOME Foundation, etc.). The 'Development'
category conceptually contains many different things that
can be developed.

You see, the problem with a hybrid schema is the fact that
the mental model they suggest has classifications that
conceptually overlap to a very significant degree, so that a
user will likely guess wrong when trying to find something,
thus forcing them to either learn the whole site map, spend
extra time hunting around, or just break down and use the
search function. With a 'pure' scheme, all the user must
learn (or intuit) is the 'principle' behind the categories,
and they will more likely be correct when they try to guess
where something is.

In the case of the current proposal, the 'Development'
category and the 'Software' category conceptually overlap to
a prohibitive extent, so decisions as to what to include in
each are almost arbitrary, making it dificult to predict (or
guess) what will be found in each. This leads to users
clicking around more before they find what they're looking
for, exactly the oposite effect from your intention to lead
users to their goal using fewer clicks.

If I'm looking for software documentation, will I
automatically look for it in the 'Development' category?

> As for your four categories, yes, they're mutually exclusive, and yes, they
> cover all the topics. But the fact that there are only four of them suggests
> to me that they would need rethinking and/or splitting up. As they are,
> they'd result in at least three more levels of navigation under them, since
> they're so broad and abstract.

I'm all for refactoring the four categories I came up with
into more (say six or seven) as long as it can be done
within a topical categorization scheme. I'll see what I can
come up with, and post a follow-up.

I'm going to try and explain my position a little more
clearly here, since it seems that part of my solution to
your concerns for 'fewer clicks' has gone unnoticed. I
apologize in advance for the length of my explanation.

'Navigation' in the context of website design has been
conflated to include two concepts: Organization of
content/functionality, and Wayfinding.

The advantages of picking a pure schema (by subject, by
audience, by task, etc) are chiefly on the organization
side, making it simpler to decide what goes where, making it
easier to categorize future additions to the content, and
making it easier to decide to add new categories or
sub-categories when appropriate. In other words, it
increases maintainability by consistently factoring the
content.

It also has advantages with regard to wayfinding, in that it
makes it easier for users to predict what area of the site
will contain what they're looking for, once they've
internalized the organization schema, and without forcing
them to internalize the entire actual site structure. In
other words, it makes a 'site-map' unneccessary.

It sometimes *may* also have a wayfinding disadvantage, when
more clicks are required to reach certain content. But
wayfinding problems have many other solutions, while this is
really the only way to improve organization.

Here is one possible wayfinding solution that I've suggested
before: Create an additional navigation device on the front
page of the site, separate and distinct from the main
navigation, that lists common tasks and leads to the correct
section of the site. We can also create similar 'audience
oriented' navigation to provide shortcuts for the press,
developers, end-users, etc. The thing to keep in mind is
that these additional wayfinding navbars do not compromise
the *organization* of the sites content, which is still
according to a pure topic oriented schema. 

I usually implement a secondary schema (as an example I'll
use an Audience schema) by creating an 'Audience' directory
that contains audience specific subdirectories, each with a
single page of shortcuts specific to that audience. I don't
add the 'Audience' directory into the main navigation, but
instead create a second navigation bar or pick-list that
only appears on the front page of the site, which lists the
audiences, and links directly to 'their' shortcut page. This
provides audience specific wayfinding, which then leads
users directly to the content that is appropriate to them.
Once on a content page, they can see (by looking at the main
navigation) where they are in the site, and learn how the
site is organized, so they can find their way around easier
in the future.

Here is the key, though: Since we have now separated
audience-oriented wayfinding from the organization of the
site, we can have the content of the audience specific
shortcut pages overlap with each other and with the main
schema without fear of confusing the site visitor. The same
applies to creating any secondary wayfinding schema,
including a task-oriented one, as seems appropriate in our
case here. One difference between a task-oriented secondary
navbar and an audience-oriented one, is that a task link is
more likely to go directly to an existing page in the site,
instead of to an intermediary page.

I hope this helps explain the approach I'm advocating more
completely.

Michael Bernstein.