W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 1999

Re: Tree model integrity (fwd)

From: John Nissen <jn@tommy.demon.co.uk>
Date: Thu, 26 Aug 1999 17:35:49 GMT
Message-Id: <52679@tommy.demon.co.uk>
To: jbrewer@w3.org
Cc: w3c-wai-ig@w3.org, jn@tommy.demon.co.uk
Judy,

I got a reply from Toby on chi-web, to which I've responded, see below.

Cheers,

John
--
Forwarded message follows:

>Date: Thu, 26 Aug 1999 16:51:56 GMT
>From: jn@tommy.demon.co.uk (John Nissen)
>Reply-To: jn@tommy.demon.co.uk
>Message-Id: <52674@tommy.demon.co.uk>
>To: CHI-WEB@ACM.ORG
>Cc: jn@tommy.demon.co.uk
>Subject: Re: Tree model integrity

>Hello Toby,
>
>Thanks for your considered reply.
>
>In message  <19990826015900.2688.qmail@hotmail.com> tobyhede@HOTMAIL.COM writes:
>
>>i think that it remains to be seen that all information can be represented
>>in a tree/hierarchy. The tree system is a representation that stems from the
>>last 20/30 years of file system hierarchies...nielsen, among others has
>>pointed out that many new computer users have a great deal of trouble with
>>the tree or hierarchical methodology. the tree is limiting as an information
>>methodology, it disallows the entire network principle that makes the web
>>such a valuable medium. 
>
>One can have the web as a forest of trees.  What I'm saying is that each
>site can and should generally have a hierarchical structure, unless there
>is a good reason otherwise.
>
>>a tree system permits only one classification for
>>information...each 'unit/block' of information resides within one branch of
>>the tree, but different users will have different classifications for the
>>same information. using a strict tree structure your are in reality
>>enforcing your classification upon them.
>
>I disagree here.  Classification has little to do with structure.
>
>>Searching:
>>i agree that having to page back through the search results in order to
>>perform another search can be frustrating, but a page with 10,000 search
>>results on it would be rather slow to load and difficult to navigate through
>>coherently. a better way to resolve this issue is to have a 'refine search'
>>input area at the top (and perhaps bottom) of the page. some of the better
>>search engines do indeed use this technique.
>
>The frustration you mention is an example of what I'm getting at.
>However I'm not expecting search engines to return all 10,000, but the
>usual 40-60 or so.  These are normally put on up to six pages or so,
>but I propose that they should all go on one page.  Then this particular
>frustration is avoided.
>
>I slightly disagree about the refinement for two reasons.  A refinement
>generally uses the same form as the original search.  Secondly, when I 
>abandon a search I want to abandon any refinements at the same time, so
>I'd like Back just to take me out of the whole process in one click.
>
>>Back Buttons:
>>there are two issues here. the browser's back button takes you back through
>>the history of navigation actions. but, a great deal of information forms
>>part of a logical stream in itself. especially with deep links forming an
>>integral part of the web (see below), the need to link within a stream of
>>information is vitally important. imagine an encyclopedia or dictionary that
>>refused to let you turn to the previous or next pages, but would only let
>>you return to the index or table of contents (or wherever it was you last
>>were)...i think the art is in differentiating between the two types of back
>>and forward activity.
>
>I believe that the encyclopedia and dictionary are exceptions in that
>cross-linking is the norm - i.e. navigating items of information that
>are at the same level, significance or importance.  I'd have to accept
>that Back would take me through all the items I'd visited - rather
>frustrating.  The only way around this would be to have the browser's
>backward link unaffected by your navigation sideways links - and that 
>would require changing how browsers work!
>
>I'd like the normal case to be that Back button takes me up the
>hierarchy of information on the site.
>
>>Site Entry:
>>http://www.useit.com/alertbox/990725.html
>>if a user needs to hit your site from the top in order to map your
>>information, than the navigation system is probably not transparent enough.
>>menu structures and page titles can provide instant user recognition of
>>location within a larger information structure, plus provide the flexibility
>>that a networked information structure demands.
>
>That's not what I'm getting at.  There is little information at the top
>level, and it mostly concerns what is at lower levels.  So the user can
>quickly go through the first level or two to get at the guts of the
>information.  To speed the process an index may be desirable, but I'd
>put it at a higher level than the information that it is indexing.  This
>may seem counter-intuitive, but it keeps all links going down the 
>hierarchy, and this is important.  (Exceptions are the cross-links from
>one part of the index to another.)
>
>Cheers,
>
>John
>--
>>>From: John Nissen <jn@tommy.demon.co.uk>
>>>Reply-To: jn@tommy.demon.co.uk
>>>To: CHI-WEB@ACM.ORG
>>>Subject: Tree model integrity
>>>Date: Wed, 25 Aug 1999 21:02:57 GMT
>>>
>>>Hello,
>>>
>>>A few weeks ago we had a thread about the importance of building
>>>up a coherent mental model, so you know where you are when you
>>>are navigating a site (but, if you get lost, you can quickly find
>>>yourself again).
>>>
>>>Now, during your navigation of the web, the browser builds up a
>>>tree of visitations.  You are aware of this when you use the back
>>>and forward buttons, and also when the colour of links change.
>>>
>>>I believe many problems that users have with web applications are
>>>due to the applications messing up the browser's tree.  Sites should
>>>have all information in a hierarchy, so that the model of the site
>>>maps onto the browser model.  And sites should avoid "short cut" buttons,
>>>instead leaving the user to use the browser to do the navigation.
>>>
>>>I claim:
>>>
>>>A.  It is possible to present almost all information in a tree hierarchy,
>>>where the nodes are pages and the branches are hypertext links.
>>>(Help information, glossary of terms and dictionaries are exceptions,
>>>since cross-linking is inevitable.)
>>>
>>>B.  Most navigation buttons introduced to make it faster or simpler
>>>for the user actually have the opposite effect, because they
>>>subvert the browser's own controls.
>>>
>>>Some implications:
>>>
>>>1.  Searching
>>>
>>>The search engine should present results on a single page.
>>>It should not break the results into a number of pages and have
>>>"next" and "previous" buttons.  Instead the user should be allowed
>>>to scroll.  The browser back button will then take the user straight
>>>back to where they started with the search form, no messing.
>>>Search refinement should be from this same point.
>>>
>>>2.  Back buttons
>>>
>>>The application should never supply its own back, forward
>>>or home buttons.
>>>
>>>3.  Internal links
>>>
>>>There should be no links between different points of the same
>>>page.  All links should point down the hierarchy.  (Exceptions
>>>are for cross-referencing in help files and dictionaries.)
>>>Applications should never have "top of the page" buttons.
>>>
>>>4.  Site entry
>>>
>>>Users should be encouraged to visit the site starting at the
>>>top.    Then the tree of the site will map directly onto the
>>>browser tree as it creates it.
>>>
>>>5.  Table of contents or index
>>>
>>>This should be on a separate page at a level above the contents
>>>itself.
>>>
>>>6.  References
>>>
>>>These should generally be in a page by themselves at the lowest
>>>level.
>-- 
>Access the word, access the world       Tel/fax +44 181 742 3170/8715
>John Nissen                             Email to jn@tommy.demon.co.uk
>Cloudworld Ltd., Chiswick, London, UK   http://www.tommy.demon.co.uk
>

-- 
Access the word, access the world       Tel/fax +44 181 742 3170/8715
John Nissen                             Email to jn@tommy.demon.co.uk
Cloudworld Ltd., Chiswick, London, UK   http://www.tommy.demon.co.uk
Received on Thursday, 26 August 1999 12:41:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:33 UTC