Hey,
>> 
>> Spencer:
>> I dig the first two changes.  The Language location change, which 
>> seems
>> to be based on Redmine ticket #9922, doesn't seem to have a link to 
>> the
>> discussion/logic that its built on, is there one?
>> 
> 
> Alan:
> I though we agreed on that:
> https://mailman.boum.org/pipermail/tails-ux/2015-March/000303.html
> 
Thanks!  We did, and considering the order again in just a text outline 
would result in the same outcome.  However, since then, the 'Language' 
section has proven to be less important than initially anticipated, as 
the two alternatives below (Auto-detect & Guided Walkthrough Step) 
accommodate a more realistic use of the section by not having it intrude 
at every moment of the Greeter experience.
However, I think this is fine to test or build.
>> 
>> This 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, de-emphasizing 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' every session
>> unless saved, de-emphasizing 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.
> 
No worries.  I understand exactly and could not agree more with the 
logic that 'Language' needs to be established before reading/writing. 
However, both of these alternatives support this logic and offer other 
benefits as well, most notably being content clarity.
I think we agree on the language auto-detect logic, but since that isn't 
an immediate concern we need to accommodate for not having it yet, if at 
all.  If we do include language auto-detect, creating a dialog now that 
will be scrapped in the near future when it gets rolled in isn't as 
sustainable as designing a greeter that acknowledges this future patch 
and uses an already existing dialog instead of a temporary custom one.
Just trying to be future-proof, but if the labor involved isn't as big 
of a concern, then no worries :)
>> 
>> Also, this 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 definitely think the left one is better in all cases for the reason
> explained above.
> 
Ack.
>>> 
>>> Alan:
>>> 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.
>> 
> 
> That's not what I'm asking for. I'd like the source of the
> Tails.Greeter.png I attach to this email.
> 
Ha, my concern with screwing up seems to have been quite prescient :)
Here ya go[0].
> 
> I don't really want icons, just wanted to know why there were none.
> Would you please add this to the blueprint?
> 
Will do.
>>> 
>>> - 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.
> 
Are there tickets for this so that I can learn more?
Wordlife,
Spencer
[0]: Tails.Greeter.svgz