Re: User choice [was: Best Practices document - not best practices]

Andrea Crevola wrote:

> Probably we do not need only a controlled vocabulary for device 
> capabilities description. We *run the risk* of stealing freedom to our 
> users if we delegate all the work to formal descriptions of device and 
> context distribution.
> 
> We need something that could let the user choose the quality and the 
> quantity of information.  ...

Definitely.

The user's choice doesn't depend just on the device.  That is, the
user may make different choices on the same device and different
times.


For example, my PDA (connected to the network via Bluetooth and a
mobile phone) has an HTML browser that lets me choose between "wide
mode" and "optimized mode."

"Optimized mode" tries to fit the page into the width of the display
so the user doesn't have to scroll horizontally.  (It scales images,
ignores some table structures and probably some CSS, etc.)

"Wide mode" displays the page with less convenience but higher
fidelity (frequently exceeding the width of the PDA display and
therefore requiring horizontal scrolling, but preserving more of
the layout of the page, which sometimes is necessary to perceive
the semantics (e.g., some tables and some CSS-formated layouts)).

Additionally, it's easy and quick to switch between the modes;
there's a button on the toolbar, as opposed to a preferences item.
(I wish my regular browser (on my desktop computer) had the same
feature.)


Yes, in the current case I'm not really choosing how much information
I want; I'm just choosing which form I prefer (or need).

However, a user might choose between more barebones information vs.
fuller information.

One might choose text only vs. text with images.

One might choose having full navigation sections with links to many
sibling pages vs. having just "breadcrumbs" (upwards links to index
pages).


Actually, it also relates to something I might have mentioned before:
CSS style sheets for printing that print drastically different content
that what is displayed on the screen.  The browser should really give
the user a choice between printing the print-specific version of the
document (if any) and printing a facsimile of what is rendered into
the on-screen browser pane.



> I know that Opera Browser recognizes this kind of tag and creates a 
> navigation bar. Firefox (with some extension) do the same.

Mozilla does too.  It's great for pages that have Next and Prev(ious)
links.  You don't have to find the Next and Previous links in the page
and move the mouse cursor there to active them.  You can plant the mouse
cursor on the Next link in the toolbar and click it repeatedly without
moving the mouse (even after scrolling vertically, if you use keys or
the mouse wheel to scroll).


> The <link> strategy is a client-side strategy, the second one could be 
> performed by a proxy or by a server.

Too bad HTML doesn't define tags to differentiate between:
- redundant navigation sections (e.g., navigation bars with many links
   that appear on many pages),
- minimal navigation sections (e.g., an uplink to the parent (sub)index
   page or uplinks to all ancestor pages), and
- unique content of a page.

Users should be able to choose whether they want screen space to be
taken up by redundant navigation content.

(I think that having large amounts of redundant navigation information
on leaf-level pages in a huge waste of screen space and is quite
inconvenient.  When I click in a link to read an article, I want to see
the damn article in my browser pane, not the full site navigation with
the article buried below.  All I need is a link or two to parent or
ancestor pages with full navigation information and I can get back
up to the links to everywhere else in the site.

However, I understand that some (many?) users want or need fuller
navigation information everywhere they go.

If there were standard markup to mark redundant navigation content,
browsers could decide whether to display it or not (ideally with
direct user choice).)


Daniel

Received on Friday, 19 August 2005 18:12:53 UTC