Re: Scripting (was RE: Accessible road maps)

> play.  In other words, if you click something, and nothing happens, how 
> long can one wait without being confused?  Client-side scripting solves 

But that is exactly how most scripting dependent sites present.
You click a link and nothing happens because the link is actually to
the non-existent null fragment.

However: if nothing appears to be happening, there is a fault in the
browser user interface; and generally any result that is near instantaneous:

1) doesn't represent anything really happening - it is just an internal change
  in the browser state; 

2) could have been turned round very fast by the server if the page hadn't
   been bloated by the scripting - straightforward HTML can interact very
   fast even server side and on a slow connection - the slow turnround
   is the result of bloat of current commercial pages, in part due to
   scripting (the server cannot take a long time to do the calculation
   in your example as the client can do it quickly using interpreted code)

Note that the tree control example, given earlier, is probably
particularly confusing because caching in the browser or, more likely,
by the script, in the document object model, means that you will get a
slow response sometimes and a fast one at other times.

> structured documents are better than plain text.  Most agree now that 
> interactive documents (web based applications) are also better than just 

I certainly don't find that to be the case, and generally find the most
useful documents on the web are actually static PDF.  My heart sinks
if I see a set of scripted pull down lists because I know that I am
going to have to know exactly what I'm looking for and how the database
constructor classified it (I won't be able to get the actual product
listed until I've selected the right category).  Even though they are
server side, I also don't like FAQ servers that only provide access by
keyword searches or go to a different page for each FAQ item.  Sites that
insist you find a product by searching keywords are also annoying.

I can imagine that there are cases where some animation is actually
beneficial, but I cannot think of any real examples; the animation I
see is generally gratuitous.

In any case, interactive documents are only really suitable as final form
content for direct human consumption, so cannot have value added.  Search
engines are an example of adding value, although it is possible, by using
additional, static, links, to allow them to get round client side scripting.

> Plus, can you imagine an accessible way of asking a user if they need more 
> time to complete a secure transaction without using a client side 

The same way as you do it for a paper form.  You tell them the time limit
in the content.  You can also script a warning (I don't mind scripting
as long as it is not mandatory for the user and is not intrusive,
either through taking over control of the user interface or by failing
on some browsers), but they may not get it, as the reason for the delay
may be that they have interrupted the input to look something else up or
been diverted from the PC for something more urgent.  I would certainly
prefer to know up front the time limit on any transaction that has a
limit of less than about a working day.  It's particularly annoying
where the business logic obviously requires quite a short timeout but
it is not documented.

As such, I see this use of scripting to be an added convenience for the
user, not something that is essential to the application.

As you've played the congnitive card, this particular behaviour is 
very counter-productive.  As an analogue, if I was accessing the site
in a foreign language that I didn't know well, an asynchronous popup
would be very disconcerting.  For the rest of the site, I would have
more or less controlled the situation by reading what I could undertand,
but I would suddenly be presented with something unexpected with a time
limit for understanding it.

Also, thinking of an elderly relative who is afraid of computers, any
unsolicited event like this would be likely to panic them, and confirm
their fear that they would never understand them.

It seems to me that it is precisely the class of user that would run out
of time that would be least able to cope with an unsolicited popup.

> scripting alert?  This is a situation where the transaction has a physical 
> time limit with the server.  The server can't wait forever for the client 
> to respond, so it sets a reasonable time limit, but requires the client to 

Apart from under-resourcing the server, the reasons I can think of for
getting into this situation, without the user having abandoned the 
session, are:

- you are selling a finite resource, e.g. airline seats, and may be
  selling them at a discount based on no refund for cancellation,
  or you are making an offer based on a price that you don't control
  (e.g. share dealing).  You want to reserve the resource/fix the price
  so that you won't subsequently reject the transaction, but you don't
  want someone to frustrate the system by indefinitely reserving without
  paying.  In that case, you don't want to allow extensions because
  someone playing the system could automate the process of extending
  (note you should never apply database locks whilst interacting with
  a user, so this would be a flag on the record, not a lock);

  One reservation in the airline seat case is if you find that a lot of
  people hold a seat but then abandon the site during a potentially slow
  part of the dialogue.  This is only a potential issue for the last
  few seats and only if a lot of productive enquiries are happening at
  the same time.  The main legitimate reason for taking a lot of time 
  before the payment stage is that the customer needs to set up an
  itinerary and booking one flight may depend on getting another one; 
  the application needs to ensure that they can do this on one session,
  so that you will get frequent interactions.  If lots of people abandon
  during the payment stage, you have usability problems on the site
  (the time I abandoned a flight booking system was because it wouldn't
  accept UK postcodes in their standard format, but some mailorder systems
  have forced me to dry run orders because you can only find delivery options
  and prices by starting the checkout process - I'm good in those case, and
  clear out the order before abandoning completely).

- for security reasons, you want to ensure that the user doesn't just
  abandon an open session.  In this case, the right approach is to 
  use a much longer session timeout than the security timeout and
  re-authenticate if the transaction is continued after the security
  timeout.  (For the variable price case, you could present the new
  price for approval.  For the airline case, you might want to penalize
  the user for letting the transaction timeout, to prevent them putting
  on new holds too soon for other customers to get access to the seats.)

> respond if more time is needed.  Just like in software application, a 
> dialog box appears alerting the users that time is about to expire and how 
> to request more time.  I only know how to do this with client side 
> scripting.  Sure it would be nice, and in many cases one can "wait 

The browser feature that is designed for this sort of operation is
cookies; HTML forms were really designed for stateless use.  There would
seem to be a flaw in both the specification and implementation of cookies.
The flaw in the specification is that there is no such thing as a
time-limited session cookie[1] and the flaw in the implementation is that
tbe browser doesn't warn when a cookie that relates to the current page
(I'd suggest the test is that as submitted when requesting the page
or was received wiith the page and that it would be submitted for at
least one link or form on the page - of course scripting can prevent
such static analysis!) has expired.

One could also treat an expiry time in the HTTP headers for a POSTed page
as being an indication of when a problem would arise, although this
might imply cachability.

All in all, I'd say this usage amounted to writing a custom user agent.

> Content-Type: text/html; charset="US-ASCII"

This is not syntactically valid HTML.

[1] time limited cookies have gotten a bad name because they are generally
set with an almost indefinite timeout and used for market research not
for the direct benefit of the customer.

Received on Friday, 4 June 2004 15:50:18 UTC