W3C home > Mailing lists > Public > public-wsc-wg@w3.org > May 2007

Re: Recommendation template (Was: Editing process for Recommendations)

From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
Date: Thu, 3 May 2007 09:20:44 -0400
Cc: public-wsc-wg@w3.org
Message-ID: <OF6A399D59.3F922B70-ON852572D0.003C698C-852572D0.00494F55@LocalDomain>
To: tyler.close@hp.com
Great structure for discussions; doing this will help us proceed quite 

As I said during the meeting, I  specifically want to hear from anyone 
doing a lightening discussion proposal about this template; if they agree 
it's a good one (since they'll be filling it out), or what changes should 
be made. 


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

"Close, Tyler J." <tyler.close@hp.com> 
Sent by: public-wsc-wg-request@w3.org
05/02/2007 01:25 PM


Recommendation template (Was: Editing process for Recommendations)

Here's a stake in the ground for our recommendation proposal template.

--- Begin template ---

    Each proposal must have a short name by which we can refer to it.

    Each proposal must reference the WG Goals
<http://www.w3.org/2006/WSC/drafts/note/Overview.html#goals> the
proposal helps achieve.

    Each proposal must provide a brief overview of the problem it
addresses and general approach being proposed to fix the problem. This
section should reference the usability principles
es> violated by the current approach, as well as any usability
principles that will be upheld by the proposal.

    Each proposal must reference the Available security information
<http://www.w3.org/2006/WSC/drafts/note/Overview.html#available> it
relies upon. (I'll add anchors to the Note that can be the target of

    Each proposal must reference the use-cases
<http://www.w3.org/2006/WSC/drafts/note/Overview.html#scenarios> it
addresses. This section must provide more detailed description of
exactly how the user will interact with the proposed user interface. The
details provided in this section must be sufficient to enable
lo-fidelity testing of the proposal.

Expected user behavior
    Each proposal must discuss the user behavior it relies upon and that
therefore must be tested. Each item should refer back to a step in the
"Use-cases" section of the proposal. For example, a proposal might rely
on the user reacting in a given way to a specified indicator. The
proposal must call out what the needed user reaction is, as well as what
user reactions might be detrimental to the user's interests. For each
item, the proposal should list the motivations for the user to react in
the desired way as well as any factors that reduce the user's motivation
to react in this way.

    Each proposal should list any significant disruptions it makes to
current user habits for web browsing. This section should help the
reader understand what issues might cause the proposal to not be
deployed, despite advantages it may have.

--- End template ---

I think the above template gives us the information we need to evaluate
a proposal and proceed with testing and implementation. I realize that
the template asks for a lot of content from the author and so we might
not get complete documents for many of the proposals by the F2F, but I
think that's OK. At least we'll know what we don't know.

This email addresses ACTION-212.

Received on Thursday, 3 May 2007 13:20:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:15 UTC