RE: Follow up from the meeting on Issue 14: timeouts

>>>  So we need to think through where it is reasonable and where it is not — and require a warning where it is reasonable — and have an exception for when it is not.

Exactly my intention, too.
OK, my bad, I have to explain more with emphasis on Exceptions.

1. There is a time dependant = limited scenario given forming a context.

2. We have two roles, content author and end user forming and interacting with the context.

3. We have really different cases to consider

(therefore we should opt for most flexible Option 3 in the original mail: Break apart into 3 SC – one to provide advance notice of any time limit, one to save data for a day, and one to address inactivity time limits):

a) Time Dependency is essential for the context

Author creates the time or a data status dependency as a given prerequisite of the context for all users. Individual user cannot influence duration since it is immutable for single user by definition. Either a timer or collective work of all users ends the context.

This is a candidate for “provide advance [and maybe permanent display of time limit] notice of any time limit” SC in my opinion. Again auctions, meeting commenting, auditing scenarios come into mind with stopwatches showing etc. Games fall also in this category.

Exceptions: I can’t see any need for exceptions requiring warnings here. So no need for mandatory extra in-between warnings since there was a initial warning and a immanent permanent display of the limit. Of course, you CAN add these warnings extra (“hey people, only 2 min for questions left”) but not as a MUST. Moderated systems may track the number of bidders on a server and raise an “Expect delays” warning but this is highly situative and should be left to the author.

I would rather see an extension of this SC requiring a permanent display of time left as part of the UI or context.


b) Time Dependency is essential for the author (!)

Here it is in the personal interest of the author that no unneccessary burden is put on the IT infrastructure. This has two aspects:

I)  Load Balance

Author puts a time limit for connection being idle (memory). This affects server time-outs based on the number of parallel open connections. Special SC candidate to address inactivity time limits and defining what is “short”. User should be able to influence it if it is short up to a limit.

Exceptions: When the time limit for ide is long enough (what is “long enough” needs to be defined, this defines also the exception).

II) Persistency Data

Author puts a time limit for storage of persistency of user data. User should be not able to influence it, instead, a hard number (24h) is dealt currently. Special SC candidate to save data for a day

When internal security regulations prohibit caching on insecure internal “buffer” servers in cloud scenarios this could create a problem. So this SC requires also secure buffer IT structures. Need to discuss persistency mechanisms on mobile (e.g. data vault on android device etc. to fulfil this requirement)

Exceptions:


-          There may be contexts where buffering for 24h is not allowed for security reasons

-          There may be other time-dependant actions invalidating the entered data (if data gets “old” after 1h in MS sharpoint servers, why keep it?)

Stefan



From: Gregg C Vanderheiden [mailto:greggvan@umd.edu]
Sent: Freitag, 12. Mai 2017 14:37
To: Schnabel, Stefan <stefan.schnabel@sap.com>
Cc: Jason J White <jjwhite@ets.org>; David MacDonald <david100@sympatico.ca>; Katie Haritos-Shea <ryladog@gmail.com>; Andrew Kirkpatrick <akirkpat@adobe.com>; w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>
Subject: Re: Follow up from the meeting on Issue 14: timeouts


Gregg C Vanderheiden
greggvan@umd.edu<mailto:greggvan@umd.edu>



On May 12, 2017, at 8:22 AM, Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>> wrote:

>>> ANY SC THAT REQUIRES A WARNING ABOUT TIME OUTS   should have an exception for real time events.

Isn’t the info about time out already an integral part of the event itself? Does it make sense NOT having this info and warn extra for it?
What sense would make an online auction without a permanent countdown counter info?

 Not all auctions have fixed time ending.  Some end when bidding stops.
Also auctions were just one example.

  *   games
  *   commenting during a meeting  (must complete comment before meeting ends  — or you will lose all text entered up to meeting end)
  *   asking a question after a presentation and before the next one.   Even the moderator does not know how long there is for response since they move on when questions stop coming in.

there are many places where there are time limits for doing something or entering data where it is not under the control of the author.



And are there types of real time events where an exception would be nevertheless inappropriate and I want to be informed?
For instance, a hotel room booking scenario.

Not sure I follow.    can you explain?

lets say there are limited rooms and you need to register for them before they run out.    But no one knows when that will be.

I’m not saying that ANYTHING that has to do with real time —

Im just saying that there are places where real-time is natural part of something and there is no way to warn people about everything.    So we need to think through where it is reasonable and where it is not — and require a warning where it is reasonable — and have an exception for when it is not.




>>>> There are data loss situations in places where there are real time events.

The question is are there scenarios where data loss plays no role but are time based? These are candidates for “do not apply”.

can you unpack "where data loss plays no role but are time based?”

I don’t follow.   I thought this was about data loss.     did you mean to have “no” in the sentence?

thx

g




-          Stefan


From: Gregg C Vanderheiden [mailto:greggvan@umd.edu]
Sent: Freitag, 12. Mai 2017 13:55
To: Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>
Cc: Jason J White <jjwhite@ets.org<mailto:jjwhite@ets.org>>; David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>; Katie Haritos-Shea <ryladog@gmail.com<mailto:ryladog@gmail.com>>; Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>; w3c-waI-gl@w3. org <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Follow up from the meeting on Issue 14: timeouts

you misunderstand.  (or I do)

I was saying that  ANY SC THAT REQUIRES A WARNING ABOUT TIME OUTS   should have an exception for real time events.

and that - you can’t have a rule that says “You must do this or you fail the SC”   and then say  "well obviously it doesn’t apply here”

if it doesn’t apply - you must have an exception in the SC to that effect.


There are data loss situations in places where there are real time events.  So your analysis does not cover or automatically exclude time limits due to real time events.

am I misunderstanding?   or do we still need the exception.

g

Gregg C Vanderheiden
greggvan@umd.edu<mailto:greggvan@umd.edu>



On May 12, 2017, at 7:40 AM, Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>> wrote:

The rule is “Do not state the obvious”. This also holds true for warnings.
The point is having a number of confirmed valid use cases where warning for time limits is required, extract the general pattern behind these cases (why they apply, what is “data loss” by def etc.) and put that pattern description in a clause. Everything else then is an exception or not a data loss by definition and falls not into 2.2.1

-          Stefan



From: Gregg C Vanderheiden [mailto:greggvan@umd.edu]
Sent: Freitag, 12. Mai 2017 13:23
To: Jason J White <jjwhite@ets.org<mailto:jjwhite@ets.org>>
Cc: David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>; Katie Haritos-Shea <ryladog@gmail.com<mailto:ryladog@gmail.com>>; Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>; w3c-waI-gl@w3. org <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Follow up from the meeting on Issue 14: timeouts

I’m not sure what the current wording is,

but anything that has to do with giving warnings when there is a time limit should have an exception for anything that is based on the real world.

  *   Auctions, filing deadlines, many deadlines, games, real-time interaction, etc. the author isn’t setting the time limit in these cases, it’s a natural function of the fact that something has to be done by a certain time in real-time.
  *   And it would get very tedious (and look pretty strange) if authors had to keep writing on their page every time there was something that had deadline. (“Warning, there is a time limit for you to shoot the enemy. You must shoot them before they shoot you”) (“warning, there’s a time limit on getting onto the elevator. You must get on the elevator before the doors close”)

g

Gregg C Vanderheiden
greggvan@umd.edu<mailto:greggvan@umd.edu>



On May 10, 2017, at 12:41 PM, White, Jason J <jjwhite@ets.org<mailto:jjwhite@ets.org>> wrote:



From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Wednesday, May 10, 2017 7:29 AM




I think the SC requiring advance warning for time limits which states the amount of time available (if this time limit is known by the author) is a viable SC (or viable addition to 2.2.1)

[Jason] It’s viable, but I’m not enthusiastic about it, as it doesn’t solve the user’s problem. Could we better confine the use of options 2 and 3 in SC 2.2.1?
That is, can we state the circumstances in which it’s acceptable to use option 2 or 3? At the moment, it’s entirely at the author’s discretion, whereas from the user’s point of view, either the first option (the time limit can be removed) or the last option (it’s more than 20 hours in duration) is far preferable. The exceptions are outside the content author’s control and so would remain in any case.

________________________________
This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.




Thank you for your compliance.