[Tails-ux] Greeter design proposal rationale

Delete this message

Reply to this message
Autore: spencerone
Data:  
To: tails-ux
Oggetto: [Tails-ux] Greeter design proposal rationale
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