Re: ISSUE-35: information overload/underload -- no oneSizeFitsAll (public comment)

I think we're good on this one. 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




Web Security Context Issue Tracker <dean+cgi@w3.org> 
Sent by: public-wsc-wg-request@w3.org
04/13/2007 07:57 AM
Please respond to
Web Security Context WG <public-wsc-wg@w3.org>


To
public-wsc-wg@w3.org
cc

Subject
ISSUE-35: information overload/underload -- no oneSizeFitsAll (public 
comment)








ISSUE-35: information overload/underload -- no oneSizeFitsAll (public 
comment)

http://www.w3.org/2006/WSC/Group/track/issues/35

Raised by: Bill Doyle
On product: All

from public comments

information overload/underload -- no oneSizeFitsAll 
where it says, in 2.2 Relevance of security information

   The Working Group will analyze common use cases to determine what
   security information a user requires to proceed safely and recommend
   security information that should, or should not, be presented in
   each case.
please consider
While GUI users rarely perturb the presentation decisions of the web 
author, 
Screen reader users commonly do use verbosity settings in their user 
environment.  So the presumption must be that the good practice this 
Working 
Group decides on as to "how much to say when" is in fact only competent 
for 
user interface modes and conditions similar to the predominant delivery 
context of web users.  It's not universal.  Yes, it's good to get more 
consistency in following this good practice where it fits, but recognize 
the 
limits of the goodness of this practice and don't think that this goodness 

extrapolates across all Web delivery contexts.  For that reason, the 
function/performance model of the security aspect needs to be articulated 
separately and independently from the good practice binding for 
presentation 
of those functions with the desired comprehension and annoyance 
performance 
characteristics in the nominal delivery context.  In particular, 
10.1.8 "Provide explanations ..." shows you realize that the information 
needs 
to be there in support of a mixed-initiative, variable-level-of-detail 
user 
experience.  All the available information should be considered 
'conditonal 
content' of the dialog state as contemplated by UAAG 1.0, Guideline 2.  So 

while the WSC deliverables may well not discuss *how* to present all this 
information, *some* way to access all this information is a requirement of 
the 
UAAG guideline.