W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2001

Re: lights are on, no one's in.

From: Al Gilman <asgilman@iamdigex.net>
Date: Wed, 07 Nov 2001 10:11:05 -0500
Message-Id: <Version.32.20011107092427.0416fa40@pop.iamdigex.net>
To: <w3c-wai-ig@w3.org>
At 07:13 AM 2001-11-07 , Jim Ley wrote:
>"Jonathan Chetwynd":
>> One can check if the user agent supports a given snippet.
>> However is there anyway to check if the user has access to a given i/o
>> device?
>>
>> ie a mouse, mousewheel, etc
>
>Of course not, and even if there was, there's no way to tell if they
>actually are actually able to use the one they have got.   The most you
>can do is check to see if the UA supports things, but that's no guarantee
>that the user can (or even the actual system, consider Jaws, it changes
>radically how IE works).  Anything that you need to know about a user
>cannot be gained by a computer, and I would also oppose anything that
>went in this direction (it's putting an undue burden on users to describe
>their situation, whilst I'm very keen on educating users, I don't think
>it's feasible.)
>

AG::

First, yes! you can't tell what the user can do, or can do readily, by
querying
the hardware.

On the other hand, sometimes there are enough twiddle factors so that it pays
to nominate a user interface profile of settings for them to accept or adjust,
not just leave them to grope their way to a sweet spot.  In this case it pays
to be scientific in how you learn about what is easy and what is hard.  And
this is not impossible.  It is useful to know about the work that Eric
Velleman
did with users with limited but somewhat usable vision.

Pre-testing for user-profiles (Velleman CSUN 2000)
<http://www.csun.edu/cod/conf2000/proceedings/0078Velleman.html>http://www.
csun.edu/cod/conf2000/proceedings/0078Velleman.html

The response to this ergonometric exercise needs to be carried out as hints or
nominations in the context of an "author proposes, user disposes" framework
which has the last say.

>You just need to ensure that even if it's there but there's no mousewheel
>it is still usable.
>
>> My current project is designing a toolbar.
>> If a mousewheel is available many of the options are hidden, if not
>they are
>> shown.(hence)
>> This dramatically effects the GUI.
>>

How about the page wakes up with the large button bar and there is one more
button with a wheelMouse image on it that flops to the other UI with the
abbreviated button bar?  But the mode button survives with 'not' red bar in
circle overprint on mouse to say "not using wheelmouse" and restore the long
buttonbar?

The point is that you can't just go behind the user's back to learn if they
are
happy to use the wheelmouse, even if you can test to learn it is installed. 
This is a major issue in the Device Independence domain, where the conditions
of the "delivery context" are understood to include what the user can and
cannot do readily and happily; but the hardware is much easier to check for.

I haven't played with any of the personalization functions of major sites, but
have you benchmarked how myYahoo works, etc?

Do you have an antechamber to your site where visitors brush off their shoes
and leave their bumbershoots?

Why not just ask them to twiddle the [optional/advanced] controls if they wish
to have them available at this point?  Then you can go with a session state
that retains this preference.  People are trying to leap too far to cross-site
preferences that persist and are applied a_priori.  We should start just with
remembering what we have learned on the fly on this site in this session.
Then
worry about how to propagate.  For you the issue is getting the users to
check-drive the advanced features, accept them, and then you can confidently
employ them in that session.

Basic idea is that the user has to know that they have choices and have some
idea of what the choices are, at least to the point that they can try, and can
escape from, any of them.

Al

>> The pre-beta, is here:
<http://www.peepo.com/2k1/mousewheel/>http://www.peepo.com/2k1/mousewheel/
>
>Please start off with good scripting techniques, try and get into the
>habit of using object detection. IIRC Konquerer supports mousewheel and
>document.all, but I'm pretty sure it will error on your script. and
>onload="defaultEvents" doesn't do what you think...
>
>This is better - also remember that all browsers which support mousewheel
>also support at least a subset of HTML DOM1/2 so using these will future
>proof your code rather than the obsoleted (and slow) document.all
>approach.
>
>var ImageNumber = 1;
>function shiftUpDown() {
>  d=document
>  ImageNumber = countRotations(ImageNumber);
>  if (objImage && objHref && d.images && d.links) {
>   objImage.src=d.images[ImageNumber-1].src
>   objImage.alt=d.images[ImageNumber-1].alt
>   objHref.href=d.links[ImageNumber+1].href
>   window.status=objImage.alt
>  }
>  return false;
>}
>
>
>function countRotations(addRotations) {
>  if (event && Number(event.wheelData)==event.wheelData) {
>   addRotations += event.wheelDelta/120;
>  }
>  return addRotations;
>}
>  
Received on Wednesday, 7 November 2001 10:08:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:58 GMT