Re: comments/questions on my two techniques - MY ACTION ITEM

Hi Tim,

Here is my attempt at answering some of your questions.... (my comments are
enclosed by <SofC></SofC>)


Tim wrote:
My first technique - "Allowing the user to extend the default timeout"

Applicability - To content controlled by timeouts via script

Description - When scripts provide functionality that has a "default"
timeout.
What is "imminent" ?

 <SofC> Imminent means "about to occur". So the user is warned of a timeout
that is about to occur.
 </SofC>

Request more time "to the current period"?  How would
this work?
Say I had a current default timeout of 30 seconds, so at 20 seconds should
the warning
be provided, giving the user 10 seconds to respond before the 30 seconds is
up?
Or should the 30 seconds be allowed to lapse, and then a request for
extension comes up?

  <SofC> To be consistent, this should probably follow the method in
'Providing a script on page that warns the user a timeout is about to
expire' (http://tinyurl.com/deqv7) where the warning is provided before the
timeout expires. This is the same as your first suggestion of providing the
warning at 20 seconds and giving the user 10 seconds to respond.
  </SofC>

If the user takes 5 seconds to respond, changing the default timeout to 40
seconds, does that
take effect after the current 30 second default timeout expires,  or does
the user get 40 seconds
from the current 25 seconds?

 <SofC> Good question.... I'm not sure about this one. There is yet another
possibility - if the user changes it to 40 seconds, then the user gets 10
seconds added to the previous time of 30 seconds, giving them a total of 40
seconds in that time period. So if it took them 5 seconds to respond, they
have 15 seconds left before the timeout expires.
 </SofC>

Request "more time to the default"?  Instead of "new" timeout value, how
about "larger" timeout
value?

 <SofC> Because of the title for this technique it would be more consistent
to use "larger". Neither am I opposed to leaving out the word "extend" in
the title and allowing this technique to be flexible in either direction
(shorter or longer time period).
 </SofC>

Instead of saying "A timeout is -about to- happen" say "A timeout
will occur in x seconds".

 <SofC> "A timout will occur in x seconds" would be consistent with the
method in 'Providing a script on page that warns the user a timeout is
about to expire' (http://tinyurl.com/deqv7).
 </SofC>

Would you like to --increase--the default setting?  Answer yes to open a
window and enter the "larger"
timeout value?  Smaller than default values not allowed?    Is there a
maximum value?  Is the larger
value set subject to external influences beyond its control (for example,
server timeouts)?

 <SofC> I don't think external influences is within the scope of this
example. But, yes, if it was subject to those then the script would also be
doing something about the external influence where possible.
 </SofC>

The last sentence should be "The user can increase the setting, and when
the form is submitted, the window
closes and the new larger default value for the user takes effect"?

 <SofC> I like the suggested wording. But I'm not sure about using a new
window with a form. It's not the only way to do this so should we be so
specific about it? For example, a javascript prompt dialog box can be used
instead.
 </SofC>

Examples:

1)  Stock market statistics on the delivery unit need to be current to the
user; therefore,
the user requests a longer timeout to absorb the current contents before
continuing

2) A chess player requests more time to consider moves in an online timed
"chess" game
with another player

3)  In an online auction, a bidder requests more time to make a bid for an
item


 <SofC> I like the examples. I think they need to be a little clearer to
indicate that they have a timeout and the user is asked whether they would
like to change the timeout length. Currently it sounds a little like the
user is initiating the request.
For example: A delivery unit containing Stock market statistics that need
to remain current, thus the delivery unit is set to update periodically.
The user is warned before the update occurs and given an option to extend
the timeout. This allows the user to set the timeout for as much time as
the user needs or wants.
 </SofC>


Resources:

(1) http://www.jayeckles.com/tutorials/servlets.pc - setting session and
default timeouts using
Java servlets

(2)
http://viral.media.mit.edu/peers/doc/d756cb761d93c8aff5fb0aadf16d5c41ae1f353c.html

-
Overriding timeouts in peers applications

(3) http://www.phpbuilder.com/tips/item.php?id=141 PHPBuilder Timeout Info

Related Techniques -
(1) Providing script on page that warns user timeout is about to expire
(2) Polling the server and triggering a warning to the user when a session
timeout is imminent


Tests - Procedure:  Change ""page" to "delivery unit"?

<SofC> Yes (though.. maybe wait until the "delivery unit" vs "web unit"
issue has been resolved)
</SofC>

How can a warning of the timeout appear after the timeout has expired
suggest - allow the current default timeout to expire, then
when timeout expires, generate a dialog box asking the user to increase
default timeout,
when the user confirms, but before the second (old default) timeout period
has expired, the
default timeout value is increased.  Will this happen before the old
default timeout is passed?
The increase the user confirms will immediately make the default timeout
value larger
Wait for the larger default timeout to take effect, and ensure that the
larger value is in effect

-----------------------------------------------------------------------------------------------------------------


My second technique - "Polling the server and triggering a warning to the
user when a session timeout is imminent"

<SofC> This technique is outside my sphere of knowledge. But from what I've
gathered I think:
- the server can not "push" (or at least assume that), and therefore it can
not update the client by this method.
- the intent is for user notification of server timeouts (as opposed to
client-side timeouts that have been addressed in other techniques).
- an example may be that a user is filling in an order form on a secure
page; the server has a time limit for the submission of the form because of
the security risks involved; the secure page has a Javascript that
periodically asks the server how much time is left before the time limit is
reached; when the time limit is (x) minutes away, the javascript warns the
user and asks if the user would like more time; if the user responds with
'yes', the javascript sends a request to the server to extend the time
limit; the javascript continues to periodically ask the server how much
time is left before the (new) time limit is reached; and so on...
</SofC>


What is definition of "imminent" in title?

Applicability: for content affected by timeouts on a relevant server or
process?

Description: Again, what does it mean for a timeout to be "imminent" (more
specifics needed here)?
   Definition of "active content"?
What happens if the server uses a method to timeout that the script can't
recognize?
Is the capability for the server to initiate and push updates (such as
timeout information)
  to the client of its own accord
assumed to be present?

(NOTE: Is the intent of this technique to update the client when the server

receives
  notification of external events, or simply to update the client at
regular time intervals?
What is the scope of this technique, or should the scope be broadened?)

NOTE: In this technique, do we want to specifically address as advisory
additional
practical uses for server push capability (such as multi-user interactive
applications, keeping users of an application up-to-date with status
  information or news, and providing feedback during long-running
operations)?

NOTE: Do we want to address the pushing of timeout information by means of
creating
  of a task queue (with tasks added)
by an application, for this technique?

NOTE: A possible way of notifying a user that their session will timeout in

x minutes (with the option
to click to continue the session), might be to use a client side JS
counter.   When a user enters a
delivery unit, a JS counter could start running?  Since the session time
out might only
happen after a period of inactivity (disconnection from the server), the
user could watch a counter
count down for x minutes on the delivery unit?

A possible example might be: for a server default policy, click edit
profile and go to
dial-in constraints profile, check the box for minutes client can be
connected (session-timeout)
and set it for x minutes.  However, this time might be reset due to other
factors?


(Possible) Resources:

(1)
http://struts.apache.org/struts-action/userGuide/preface.html     Session
Timeout Info

(2) http://www.macasp.com/Doc/techies.asp - MacASP Timeout Information

(3) http://www.timfanelli.com/tags/jboss - JBoss session timeout
information

(4) http://www.dnzone.com/ShowDetail.asp?NewsId=565 ASP.NET session timeout

information

(5)
http://www.nextapp.com/platform/echo2/echo/doc/tutorial/serverpush.html
server push

Related Techniques:

(1) Providing script on page that warns user timeout is about to expire
(2) Allowing the user to extend the default timeout

Received on Friday, 10 February 2006 05:01:15 UTC