Re: Navigation Proposal

[Michael Bernstein <webmaven lvcm com>]

Joakim Ziegler wrote:
> 
> On Wed, Dec 20, 2000 at 09:53:28AM -0800, Michael Bernstein wrote:
> > Joakim Ziegler wrote:
> > >
> > > While nice in theory, I think this falls into the "too much abstraction"
> > > trap. Yes, it's a really nicely topical, logical hierarchy, but people expect
> > > stuff like "Development" to be a top level header.
> >
> > I disagree. I think it's worth not creating a mixed
> > noun/verb categorization schema, and you'll actually confuse
> > people more if you don't excersize retsraint in this regard.
> > If I'm looking for documentation, do I find it under
> > 'Software' or under 'Development'?
> 
> I've never heard of cases where a "mixed noun/verb categorization schema" has
> ever led to problems. Indeed, the stilted terms or overly broad/narrow
> ctegories you create by trying to stick to one would likely be a bigger
> problem.

Sorry, noun/verb is my own terminology. Topical vs.
functional, or subject-oriented vs. task-oriented would be
the more usual way to describe it, I suppose.

Have you read 'Information Architecture for the World Wide
Web' by Louis Rosenfeld and Peter Moreville? Chapter 3 deals
with this specific issue of organization schemas, and the
point is made that hybrid schemas are more confusing because
it's impossible to form a mental model of the site.

The book is published by O'Reilly, and I can reccomend it
unconditionally to anyone who designs websites. Here is are
two small (relevant) quotes:

"The power of a pure organization scheme derives from it's
ability to suggest a simple mental model for users to
quickly understand. Users easily recognize an audience
specific or topical organization. However, when you start
blending elements of multiple schemes, confusion is almost
guaranteed."

"Hybrid Schemas are common on the web. This happens because
it is often dificult to agree upon any one scheme to present
on the main page, so people throw the elements of multiple
schemes together in a confusing mix. There is a better
alternative. In cases where multiple schemes must be
presented on one page, you should communicate to designers
the importance of retaining the integrity of each scheme. As
long as the schemes are presented separately on the page,
they retain the powerful ability to suggest a mental model
for users."

> Remember, even extremely usability tested software, such as
> everything coming out of Apple, has top-level menu items like "File", "Edit",
> "Tools" and "Window".

You've made the point yourself that the website shouldn't
emulate the desktop, but I'll still point out that websites
are primarily comprised of content, whereas desktop
applications are primarily tools for content creation and
manipulation. You are correct that mixing schemas in menus
are not much of a usability problem *once you've learned the
platforms' conventions*. Users will not be willing to spend
as much time learning the structure of your site as they
have been willing to learn the conventions of their chosen
desktop environment.

> > Also, keep in mind that one of the goals of your
> > categorization schema should be maintainability. If you come
> > up with new content, it should be immediately obvious and
> > crystal clear which topic it falls under, and if you're
> > creating a new category in the future, it should be
> > immediately obvious whether it's a sub-category of an
> > existing topic, of if it's a new top-level category.
> 
> This isn't going to happen. No matter how perfect your categorization schema,
> there will always be data that doesn't fit.

Of course. But it will be immediately obvious when it
doesn't fit and you must simply decide whether it requires a
new sub-category or a new top level category, which is
vastly preferable to a situation arising where you're unsure
where to place a new document.

If I want to create downloadable printable manuals, do I put
a download category in 'Documentation', or a printable
documentation category in 'Download'? If you have a topical
heirarchy it's obvious that you need a 'Download this
document in a printable format' task oriented link from each
relevant page, so the problem never arises.

Now, if you want to have a separate navigation device on the
front page that contains links to the most common tasks, the
problem is solved. you can dedicate screen real-estate to
those tasks without polluting a topical heirarchy with task
oriented top level items. So  you can have a task-oriented
quick link to 'download all documentation in a printable
format' that is not part of the main navigation.

With a completely database-driven site architecture,
maintaining multiple site navigation schemas is not any more
of a problem than maintaining one. All you have to do is
make sure that content is tagged with the appropriate
meta-information when it is added, according to whatever
(and however many) schemas you want, and navigation options
can be dynamically generated based on this information.

> In your four top level
> categories, you might have avoided this problem on the top level, because the
> categories are so vague, but it'll just come back to haunt you on the level
> below.

I don't think that the categories I've defined are vague.
They are broad, true, but they are also mutually exclusive.
On the contrary, vagueness comes from having categories that
overlap to a significant degree, which is exactly what I'm
trying to avoid.

Now, it is true that more than four top level categories are
desireable, and I'm certainly open to suggestions of content
that does not fit into the divisions that I've proposed, But
given the content that's been suggested so far, I don't see
where any additional top level *topical* categories are
possible.

> Given a reasonablys malls et of data, like we have, you're not going o
> be able to construct a balanced and symmetrical category tree, because you
> can't specialize enough without ending up with just one or two documents in
> each category.

The sub-categorization does not have to be as deep in all
places on the tree. If a site section does not have enough
content to warant further sub-categorization, then it
doesn't, and shouldn't be. 

Cheers,

Michael Bernstein.