Re: [Tails-ux] Greeter design proposal rationale

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.