re: Note Section - Design Principles

Great writeup. I'd like to be sure each design principle is backed by 
something; references to research, to deployment experience, to a long 
discussion with concensus, etc. See my assumptions section for the types 
of backing we're using. 

Please do put a draft of this in the Note area of the wiki soon (before 
the 11th). Remember to include Brad's reply as well (or tell Brad to fold 
his in after you've put in yours, and me too). 

> - Dialogues should not contain information which is irrelevant or 
> rarely needed.

I'm a fan of the button (or equivalent) that brings up more information 
(for debugging, for explaining or reporting a problem). I assume that 
falls within this recommendation (or the next one), so I'd like to see it 
explicitly called out. 

> - The user should be able to conveniently access more information as
> required by their level of experience.

Or the task at hand. Reporting a problem or debugging often calls for more 
information than getting something specific done. 


> Characteristics of the average user (is this what was meat by the 
> assumptions section?)

Not necessarily. But we should begin to get a start on describing our 
user(s), since techniques like personas call for something like that. You 
can put it there if you think that's where it fits best. 


> - Users lack the knowledge that would help them make security 
> decisions on the internet. This includes being unaware of security 
> protocols and concepts, the meaning of current security cues, and 
> the difference between the web content and the browser chrome.

Users do have some notions around real world security (boxes that hide 
things away are toys for children at a young age, many people need to lock 
or otherwise confine things, including houses, cars, and cattle). 

> - A user has only a single locus of attention, a feature or an 
> object in the physical world or an idea about which you are intently
> and actively thinking

I know that there's a lot of CHI research on mechanisms for peripheral 
awareness. But I'm not familiar with most of that research. Where do the 
assumptions around that fit into this? It must only be useful for the 
user's primary task, not for something they need to be told about that 
they're not thinking about. 

>From Brad:
> I'm not quite sure I agree with many of the "Characteristics of the 
> Average User".  Being the IT person for friends and family, most of 
> those users do care about the security dialogs and it isn't uncommon
> to get a phone call saying "What do I do with this, am I at risk?"  

I agree; I do to. But what do all the people without a nerd in the 
immediate family do? 

On things I'd add:

I don't see anything on:

Flexibility and efficiency of use Accelerators -- unseen by the novice 
user -- may often speed up the interaction for the expert user such that 
the system can cater to both inexperienced and experienced users. Allow 
users to tailor frequent actions. 

Help users recognize, diagnose, and recover from errors Error messages 
should be expressed in plain language (no codes), precisely indicate the 
problem, and constructively suggest a solution. 

Offer a personalized service that takes account of each client's needs and 
preferences and reflects its social identity.