W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2000

Re: dead man's handle is a key technique (looking to future)

From: Al Gilman <asgilman@iamdigex.net>
Date: Wed, 05 Apr 2000 10:50:40 -0400
Message-Id: <200004051451.KAA129683@smtp1.mail.iamworld.net>
To: <w3c-wai-gl@w3.org>
Cc: w3c-wai-ua@w3.org

At 02:21 PM 2000-04-05 +0100, Jonathan Chetwynd wrote:
>Dead man's handle is the bottom line, if the client does not interact you
>better start trying to entertain them.
>Stop as soon as they do and try to build confidence.

This is a key point in the minimal safety net c.f. EZAccess from Trace.

The reference is to the "dead man" switch on a railroad locomotive which
stops the train if the engineer releases his hold on the control handle.
Prevents the train from proceeding down the track if the engineer dies.

Jonathan is using this to refer to an action (here, to resume continuous
play) which is taken if the user makes no control input for some set period
of time. 

The point is that in appropriate contexts, inaction should be treaded as
one of the action options, and timeout should trigger branching in what the
system does.

[and in the "help" direction is a prime candidate -- pop to meta level]

In primitive situations, that is to say where there is a minimum of prior
training on the control vocabulary, it can be appropriate after a
reasonable wait for the sustem to do something (take the initiative to
establish dialog) when the user doesn't.  Compare with the "cancel or
continue" prompt that comes up on timeout on postal kiosks in U.S. (as I
recall).  This applies to public kiosks or workstations just as much as it
applies to a person with a cognitive disability using the same web or
computer day after day.  Learning how to accomodate the person with
congnitive difficulty helps us learn how to bootstrap "social interaction,"
"grok lock," or comprehending interaction with strangers or walkups.

This is a fundamental consideration in bridging the user interfaces between
Web and multimedia, that is hitherto little explored.

Received on Wednesday, 5 April 2000 10:50:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:26 UTC