All sections are required for FPWD. Use your best judgement on filling them with appropriate content.
Title
- Each proposal must have a short name by which we can refer to it.
Goals
Each proposal must reference the WG Goals the proposal helps achieve and explain how this is done.
Overview
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 violated by the current approach, as well as any usability principles that will be upheld by the proposal.
Applicability
This section defines to what kinds of implementations the requirement or good practice applies. It speaks, e.g., about interface modalities (visual vs. audio) and the like.
Requirement | Good Practice
The statement against which we expect an implementation to declare conformance. Requirements correspond to a MUST, Good Practices correspond to a SHOULD.
Techniques
This section lists techniques that can be used to implement the requirement or good practice. It's currently expected to be informative, but we might need to revisit that.
Dependencies [optional for Robustness only proposals]
Each proposal must reference the Available security information it relies upon.
Examples (informational)
Give an example for what an conforming and what a non-conforming implementation could be.
Use-cases [optional for Robustness only proposals]
Each proposal must reference the use cases 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.
Attack resistance and limitations
Discuss the security properties that can be derived from this requirement, and the limitations there are. References to ThreatTrees or vulnerability databases will be useful, but not required.
Usability effect [optional for Robustness only proposals]
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.
Disruption
- 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.
Background (informational)
Place to give a more detailed discussion of the background and rationale for the requirement / good practice.
References
- Each proposal can optionally reference other parts of the wiki (such as Action Items, archived emails) as well as external supporting work such as published papers.