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

Gregg C Vanderheiden
greggvan@umd.edu




> On May 12, 2017, at 8:22 AM, Schnabel, Stefan <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>
> 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
>  
> 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 <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 <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.