Re: Site Structure vs. Site Navigation

[Michael Bernstein <webmaven lvcm com>]

pat eyler wrote:
> 
> >From: Michael Bernstein <webmaven lvcm com>
> >Hello all,
> >
> >In my experience, it usually does not make sense to organize
> >a sites content (and by implication the site's main
> >navigation) by any other method than a strict singly-rooted
> >topical heirarchy (there is an exception to this which I'll
> >discuss later). When organizing content in this way, you are
> >primarily concerned with a documents *subject*, not it's
> >format or audience. This lets experienced visitors find the
> >specific content they're looking for quickly, as well as
> >making it clear to contributors and maintainers where new
> >documents should be placed (Q:"Does the GNOME applet
> >tutorial belong in the applet section or the tutorial
> >section?" A: In the applet section, because there is no
> >'tutorial section').
> 
> A thought that I have had aperiodicly for the last year or so is
> that it might be better to organize the data along two axes.  If we
> consider the vertical hierarchy to be the primary axis, we should
> keep in mind a lateral axis and provide a means to navigate that as
> well:
> 
>                             main gate-+
>       +-----------+------------+------+----+-----------+-------+
>       +GTK        +Developer   +Gnotices   +Office     +Apps   ....
>       |           |            |           |           |
>       +Gnotices   +Gnotices    +Gnotices   +Gnotices   +Gnotices
>       |           |                        |           |
>       +Tutorials  +Tutorials               +Tutorials  +Tutorials
>       |           |                        |           |
>       +White      +White Papers            +White      +White
>       | Papers    |                        | Papers    | Papers
>       |           |                        |           |
>       + ...       + ...                    + ...       + ...

Hmm. You're doing here exactly what I'm reccomending
against: Mixing categorization methods in the same schema.
You've got a Subject, an Audience, a Document Type, and two
more Subjects, all in the top level.

The most important quality that a strict singly-rooted
heirarchy has is non-ambiguity. This can be dificult to
achieve when the body of content you're attempting to
categorize is as large and diverse as Yahoo, but otherwise
just takes care and attention. While a mixed schema won't
hinder navigatiing to the information much, it makes it
difficult to create a sense of 'place'. Say that I'm a
developer looking for GTK specific information, and I find
it by navigatiing to the Developer page, and then finding a
GTK section. Should the navigatuion indicate that I'm in
/GTK/Developer or /Developer/GTK ? According to the schema,
it should indicate both, which is not acceptable. Main
navigation *must* be completely unambiguous.

> If we think about a structure like the above, the GTK->Gnotices page
> would show two navigational interfaces.  The first should show the
> GTK tree (this is the primary interface).  The second should show
> the other Gnotices areas that are available.  The other pages would
> be arranged similarily.

I have no problem with this, as long as the 'main tree' is
unambiguous, as I discussed. suplemental navigation (by
content type, in this case), is a Good Thing (tm).

[major snippage]

> >The exception I alluded to earlier is that it is also
> >possible to organize a site's content to encourage community
> >contributions, by letting visitors 'join' the site and
> >giving them a personal folder that they can add content to.
> >This has the disadvantage of scattering the bulk of the
> >site's content across many personal folders (essentially
> >organizing the site according to author). It then becomes
> >neccessary to create the main navigation schema (a topical
> >heirarchy) as well as the supplemental navigation methods
> >automatically by using meta-information.
> 
> Including a wiki style or reply style section can provide incentive to 'join
> in', without unduly spreading the content into an unmanageable heap.

Hmm. characterizing a community oriented site as an
'unmanageable heap' is a bit extreme. All it means is that
you must not neglect attaching meta-information to the
content, and that you must plan ahead for extracting
meaningful structure from that meta-information.

[more snippage]
 
> >P.S. If you've noticed that I've not mentioned a search
> >interface, congratulations. I do not consider a search
> >interface, however good, a replacement for good structure
> >and navigation. A user should never be forced to search.
> >Unfortunately, many sites use search as a band-aid for poor
> >structure and navigation.
> 
> Agreed, with the caveat that a good search tool is a wonderful (and
> often unimplemented) supplement to good structure and well planned
> navigation.  Please don't throw out the baby with the bathwater on
> this one.

Sorry, I was a little unclear. I also consider search to be
a valuable tool, but have often seen it used as a band-aid.

Cheers,

Michael Bernstein.