Autore: spencerone Data: To: tails-ux Oggetto: [Tails-ux] Greeter mockups
Hi hi,
> Alan:
> I'm late again, and won't probably be quicker next time... don't expect
> quick answers for me for one more month I think.
> I reply to some of your points below, if it's not too late.
>
No worries, it is never too late : )
>>>>
>>>> Spencer:
>>>> An auto-prompted walkthrough for the 'Language' section, leaving the
>>>> guided configuration experience as an always present link.
>>>>
>>>
>>> Alan:
>>> I think that's what we should do, *but* let's make it possible not to
>>> have it on the 1st iteration(s).
>>
>> If there is an auto detect for language preference then the 'Language'
>> section can be grouped with the more technical settings, allowing
>> 'Storage' to be more prominent[0]. The logic is:
>>
>> • If the auto detect runs at boot and does not detect a language
>> preference then the guided configuration step for 'Language' will
>> appear, walking people through selecting, and possibly saving, their
>> language preference.
>>
>> • If the auto detect runs at boot and does detect a language
>> preference
>> then the greeter dialog will appear, allowing people to focus on
>> configuring storage and/or starting Tails.
>>
>> In both of these cases the issue of language is addressed before the
>> greeter screen we've been discussing ever appears, so it seems
>> appropriate to deemphasize the discoverability of the 'Language'
>> section.
>>
>> On the first iteration the greeter loads on boot with the expandable
>> 'Settings' section open. The alternative is having no expandable
>> section [More on this below].
>>
> This looks great *while* we actually implement this saved language
> setting. That was not necessarily the plan for the 1st iteration of the
> greeter, but why not...
>
It is still possible to not have this on the first iteration. The
thought experiment is necessary to ensure that if we do introduce a
language auto-detect in subsequent iterations that it doesn't prompt
another redesign of the greeter.
If we include the language auto-detect in the first iteration, we can:
• Auto-detect language preference every session, deemphasizing the
'Language' section in 'Settings'.
If we exclude the language auto-detect in the first iteration, we can:
• Present the greeter dialog every session and reorder the 'Language'
section below the 'Storage' section once language preference is set,
somewhat deemphasizing the 'Language' section in 'Settings'.
• Present the guided configuration step for 'Language' every session
unless saved, deemphasizing the 'Language' section in 'Settings'.
>>>>
>>>> When someone wants to edit the settings they are asked to set up an
>>>> administrative password. This addresses the security issues
>>>> associated
>>>> with saving the more technical settings.
>>>
>>> I don't think that we should do that as there is no such concept of
>>> an
>>> administrative password in a live amnesic distro like Tails, unless a
>>> user choose one, that would be only active for the session.
>>
>> Though I have to read the persistence documentation more thoroughly,
>> doesn't this exclude the passphrase for the encrypted partition, which
>> persists throughout multiple sessions? If so, and we have a
>> passphrase
>> to access the persistent volume, wont the language preferences be
>> stored
>> in this same location? If so, then, to me, we have two user types: 1)
>> the administrative user - who saves preferences and uses storage, and
>> 2)
>> the passive user - who saves nothing and uses default and/or single
>> session preference settings [This designation is solely for argument
>> purposes]. If this is the case, then an administrative passphrase is
>> what is used to gain access to the persistent volume, right?
>>
> No. There are two separate sets of privileges:
>
> - the encryption paraphrase that is only used to decrypt the encrypted
> partition, if present. It will persist between sessions;
> - the administrative password, that can be set whether there is an
> encrypted partition or not, and that will *not* persist between
> sessions. One can need administrative password (e.g. to install an
> additional software) without wanting encrypted storage, and one can
> need a persistence storage without wanting to allow any admin access
> (more security).
>
> Is that clear?
>
Mostly. I understand that there is a separation between the persistent
storage passphrase and the administrative passphrase. Other than as a
security measure to wake the device from sleep, the value of a
non-persistent administrative passphrase still eludes me. Though I might
be unfairly picking on this example, it is unclear to me where software
would be stored if not on the persistent partition and how a temporary
password would permit this. Are the installs single session only?
>>
>> Some questions:
>>
>> • Close[x] not needed?
>> If I boot into Tails, the greeter dialog appears. There is a
>> Close[x].
>> If I click it, do I return to the host computer’s boot dialog? Does
>> it
>> need to exist? What is the intended function/experience?
>>
> I don't think it needs to exist.
>
Or does the Greeter replace the Tails Boot Dialog?
>>
>> • Display/hide configuration settings?
>> On the greeter dialog the ‘Settings’ section expands on click and
>> displays the ‘Language’ and ‘Privacy’ section contents. If ‘Settings’
>> is closed on load, the “Check & Go” intention is lost. If ‘Settings’
>> is
>> open on load, closing the ‘Settings’ section serves no purpose and the
>> included privacy settings [the more technical options] might be
>> unwanted
>> to some people. If the Settings[x] exists, saving the dialog
>> preference
>> could resolve these issues. However, saving the dialog preference
>> might
>> be a security issue. Should we keep the Settings[x] or just always
>> display the info?
>
> I'm all for always letting the settings expanded and have no expandable
> section if we have enough space. The attached mockup seems me really
> fine to that extend.
>
Yeah, the logic just doesn't hold up for the expandable function as part
of this greeter dialog. Hiding info might come in handy, though we
might have to address it differently, possibly hiding all of the
settings other than 'Storage'.
>>
>> If we keep the Settings[x] are we saving the dialog
>> preference of it being open/closed? If we save the dialog preference
>> is
>> the state of the content included?
>>
> I don't think we want to save the dialog preferences yet, but some
> might be saved at some point. Perhaps we'll need three sections of
> settings then:
>
> - language, that are saved unencrypted;
> - privacy settings that can be saved;
> - session settings (that are only relevant for one session).
>
> But all that saving of privacy settings needs more designing that is
> not only UX and that should be in my opinion be a 2nd step (else we'll
> never release the new greeter...)
>
