Hi,
spencerone@??? wrote:
> > Alan:
> > I published a 1st draft of the rationale of our design proposal for the
> > greeter at:
> > 
> > https://tails.boum.org/blueprint/greeter_revamp_UI/design_rationale_phase1
> > 
> 
> Holy shit, this is a ton of work; kick-ass, G!  Thanks for this!!
> 
Thanks!
> > I made a few changes:
> > 
> > - I added a "more info" (aka help) link that was missing.
> > - I moved the reassuring text in the appropriate section "Settings"
> > - I moved Language above Storage as I think we decided
> > 
> 
> I dig the first two changes.  The Language location change, which seems 
> to be based on ticket #9922[0], doesn't seem to have a link to the 
> discussion/logic that its built on, is there one?
> 
I though we agreed on that:
https://mailman.boum.org/pipermail/tails-ux/2015-March/000303.html
> This[1] discussion details some thoughts on the placement of the 
> 'Language' section.  The summary of language auto-detect on the first 
> iteration is:
> 
> • Auto-detect language preference every session, deemphasizing the
> 'Language' section in 'Settings'.
> 
That makes sense, but...
> The summary of *no* language auto-detect on the first iteration is:
> 
> • Present the guided configuration step for 'Language'[2] every session
> unless saved, deemphasizing the 'Language' section in 'Settings'.
> 
I don't agree on that (and I though it was clear). That is because one
*need* to set at least the keyboard layout to be able to type its
passphrase. Be there a saved language of not, it is logical to be
first ask to review the language before reading about typing
something with the wrong keyboard. Sorry for the misunderstanding.
> Also, this[3] comparison shows the two options side-by-side displayed 
> with the understanding that we are placing the 'Language' section on top 
> of the 'Storage' section because we aren't including a language 
> auto-detect in this first phase.
> 
> However, with all of this said, I think we should have the 'Language' 
> section ordered after the 'Settings' section, since all people using 
> this would have no issue locating the 'Language' section on the first 
> screen, at least I am having trouble envisioning a case where they 
> would.
> 
I definately think the left one is better in all cases for the reason
explained above.
> > Also a few questions:
> > 
> > - may I have the source of Tails.Greeter with the explanations?
> > 
> 
> Yes, I did zip it for you previously, I think, but in case I screwed 
> that up, here[4].
> 
That's not what I'm asking for. I'd like the source of the
Tails.Greeter.png I attach to this email.
> > - should we have icons for the ActionBar buttons?
> > 
> 
> No.  Mainly because it is hard to effectively visualize 'Restart', 
> 'Tour', and 'Start Tails' into iconic representations of their concepts. 
>   Considering 'Start Tails', the 'Play' and 'Computer' icons are not as 
> precise as they cold be, which really leaves the standard stand-by I/O 
> icon such as on a Mac.
> 
> However, if we do include icons on our buttons, I encourage only 
> settling on icons that only have the one meaning.  For example, the 
> 'Play' icon works because it is like saying "Run", which is what 
> programs tend to do, but also doesn't work because it means "Play", like 
> a video, and therefore isn't as precise of an iconic representation as 
> it could be; this icon wouldn't make the cut.
> 
I don't really want icons, just wanted to know why there were none.
Would you please add this to the blueprint?
> > - do we want to display both the "Configure Encrypted Storage" button
> > and the unlock box?
> > 
> 
> Yes, if the threat model *can* be defended against by displaying these 
> two options side-by-side.  Doing so also lessens development time, 
> enhances the user experience, and reduces the likelihood of bugs by not 
> having to create different states of the greeter for varying storage 
> settings.
> 
> However, if there *is* a technical way to accurately discover existing 
> storage, then displaying both buttons side-by-side might not be 
> effective to that extent, though doing so would still provide the 
> development and usability benefits touched on above.
>
Currently there is, even though we though about removing it in the
future.
Cheers.