Action-531: Try to tease apart aspects of the document which are UI Guidelines

This action item addresses the comment "It was not written by user  
interface people and not for user interface people ... and by the time  
we get to the brief user interface guidance in sections 6,7 the way is  
lost." On the Oct 15th call we discussed some ways to fix the  
document: renaming the document, adding more text to the intro, giving  
UI readers more direction ...

Stepping back and reading from his perspective I can see where he's  
coming from. The content is good but the presentation is confusing. I  
think we can improve readability by reordering the sections, renaming  
some of them, and explicitly indicating which sections are most  
relevant to UI people.


The sections should be reordered to present the more general UI advice  
first. Section 5 addresses the application of a specific technology  
and it's presented as the first section of content. We have a lot to  
say about TLS, but I think it should be more toward the end of the  
document because it's so specific. We should also consider adding an  
intro paragraph to 5 about why it's the most worked example.

Section 7 is has the most general UI advice and should be the first  
section of content after the overview and scoping/definitions. We  
should follow it up with is separate section for communicating error  
messages (error handling and signalling). That's one of our stronger  
sections and we should highlight its importance for the design of  
future interactions/interfaces. The remainder of the current section 6  
should follow.

Section 8's name is too general. I think we're presenting this  
information as security lessons learned from  the mistakes/oversights  
of others. We don't have concrete advice on how/when each of them will  
come up but we want people to be aware of these issues when they're  
designing security indicators. I don't have a great suggestion for a  
new name but the entire document is asking them to consider security,  
so this name doesn't feel precise enough. Maybe - "Additional Security  
Threats to Consider".

We should combine sections 3 and 4, both sections contain definitions  
that relate to the document as a whole and tell the reader what the  
document is focused on.

The section could look something like:
Working Definitions and Assumptions
	- Document Scope
		- Product Classes (3.1)
		- Interaction Model (most of 4.1)
		- Content (rest of 4.1)
	- Terms and Definitions (4.2)
		- Common UI Elements
	- Language Conventions
	- Levels of Conformance
	- Claiming Conformance


The first sentence of the overview doesn't capture the intent of the  
document.  "This specification deals with the trust decisions that  
users must make online" -- aren't we dealing with the communication of  
security context information and suggesting ways for UI designers to  
support them in making informed security decisions? (I probably missed  
some long discussion about why we're using trust here instead of  
security.)

Should we move the acknowledgements section to precede the reference  
section?


-- Maritza

	http://www.cs.columbia.edu/~maritzaj/

Received on Tuesday, 4 November 2008 18:13:00 UTC