[site logic] Re: an index for every directory?

At 02:22 AM 2001-11-09 , Jonathan Chetwynd wrote:
>Is this part of the guidelines?
>should it be?

AG::  [hook in existing work] It goes in Checkpoint 3 under our current filing
system.  It is missing semantics in the current draft.  The semantics has
to do
with using a site structure that is easy to grasp, remember, and navigate
incrementally within.  

The highest and best statement of the principle and practice integrates
navigation behavior, orientation for navigation behavior, the virtual-data
structure of the site, and the explanatory content offered in the help/learn
functions of the site.

The 'parent' of this topic is indeed Guideline 3, make it grokkable.

It can be derived from the application of the XML Accessibility Guidelines to
site structure.  In particular, with regard to site structure, one should
- have a plan
- implement the plan in the structure of URLs used to access and name the
pages.
- support the plan through site navigation
- explain the plan to visitors, not just content contributors, in site guide
materials

It can likewise be derived from our "both show and tell" rhetorical-diversity
super-principle.  

The last two bullets above direct that the mental model you show in the site
navigation you should tell as well.  In the success criteria it should make
clear that a grapical summary of site structure is not enough; the topic
labels
used in navigation labeling and in this summary chart [or Table of Contents
listing] should be expanded offline in the site guide literature, either in an
annotated table of contents - which is a good genre to consider for promotion,
or a link away in a site virtual glossary, or with an effect similar to
these. 
Minimimum expansion is "use it in a sentence" and the next level up is
"describe in 21 words or less."  This is where the semantic web hits the
navigation web.  Can I learn more about that keyword?  The answer should be
'yes.'

A representative server-side technique is "for all URLs that resemble
directory
requests, include links to the help/learn slice of the site prominently
whether
returning a 'normal' page through server defaulting configuration or supplying
a BODY in an error message."  Many database-driven sites simply return a 403:
fobidden error when you ask for a directory listing by truncating the URL
where
you are.  This is not-ready-for-prime-time behavior.  Just as 404 errors
should
return a link to search and site map, so should 403's, or at least errors that
arise from the inability to serve an URL which fits the historical
directory-listing pattern.

I don't know if the group will class this next as a server-side technique, but
to me it is at the checkpoint level:  The site designer needs to understand
that error responses are part of their site content.  We have heard expert
testimony that LD users are perpetually in a test-and-fix loop.  This means
that the error recovery features are where they live.  They should be well
done.  A positive technique which is generic across services which create a
hierarchical filing system appearance in their URL naming is to use
context-sensitive error responses, such as responding to failed requests for
directory-looking URLs should include links to the site organization
explanation and navigation / search starting points.  And if the request is
deep, link to the place in the site organization explanation which corresponds
to the innermost sorting category of the site logic which contains the
point at
which the failed request would appear to be pointing to.

This is like the one about how "the metadata shown to the User Agent in the
form of HTTP header fields is part of your site content."

Designers suffer from an "out of sight, out of mind" syndrome as do we all. 
All aspects of site design and making-it-work that are not constantly under
their nose need to be reminded to them, to get all bases covered.

Unfortunately there is too much propaganda coming out of W3C to the effect
that
"That hierarchy you think is in the URL space isn't there.  It's just a point
set with distinction between points and no other structure."  This is not
listening to Steven Pemberton's concerns for usability.  The path structure of
HTTP and FTP etc URLs shows hierarchy to your users.  That is how a
significant
slice of users perceive things.  Don't shoo them off this perception; use all
the communication assets that are working to your purposes.  Make the path
names make sense as much as you can, and tell the users who will follow a link
to the explanation where the mnemonic path segments leave off and where the
opaque system IDs start.  And show them via the context-sensitive links from
403 bodies to subtopics in the site orientation guide as well.  

Al

>I'm finding it very frustrating when I visit large sites, and cannot find
>out what other resources there are by knocking of the end.
>


>for example:
><http://news.bbc.co.uk/low/english/entertainment/music/newsid_1580000/1580
273>http://news.bbc.co.uk/low/english/entertainment/music/newsid_1580000/158
0273
>.stm
>I'd like to know what else was in each directory, what is the meaning of
>low, etc
>
>jonathan chetwynd
>
><http://www.peepo.com/>http://www.peepo.com         "The first and still the
best picture directory
>on the web"
><http://www.learningdifficulty.org.uk/>http://www.learningdifficulty.org.uk
"Our guide to helping people with a
>learning difficulty get the most from the web"
>

Received on Friday, 9 November 2001 08:43:00 UTC