Author: spencerone Date: To: tails-ux Subject: [Tails-ux] Greeter mockups
¡Hola!,
>
> Alan:
> Sorry for the delay answering. I'll be quite busy next week, so don't
> expect high responsiveness.
>
No worries, I have been busy playing with legos :)
>>>
>>> Alan:
>>> We should also keep in mind that language selection must be
>>> discoverable by people that might not understand a single word of
>>> english. It was among the goals of the list of languages on the left
>>> of
>>> the languages section: seeing different languages names that you
>>> probably know some invite you to click on yours first.
>>>
>>
>> Spencer:
>> I see the value in experiential recognition, however, this is a
>> one-time
>> use case, though it is arguably the most important one.
>
> That's the point.
>
The 'Text Language' icon should resolve the discoverability path, even
if used more universally as the 'Language' icon. It appears to be quite
clear and communicates the concept of "language" effectively. In
addition to the icon, the text of the default language is displayed,
this seems to be enough to do the job.
Maybe there are regional releases where we pick a few major languages,
e.g., Chinese, English, Hindi, and Spanish, and set them to default.
Though maybe this has been decided against.
>>
>> Maybe there is
>> an auto-prompted walkthrough the first time Tails is run [if this
>> isn't
>> a security issue].
>
> This is being thought currently for other reasons I think, but no clear
> conclusion have been reached yet as far as I know.
>
This seems appropriate. It could be for the entire walkthrough or just
the 'Language' section.
>>
>> Or, though it could become annoying, even though it could maybe be
>> deactivated somewhere in the settings, what if there is an always-on
>> alert/walkthrough instruction to edit the language, or even the other
>> settings.
>
> I really don't think that we want to add extra settings that would
> split the anonymity set, need documentation and so on.
>
If this was actionable in 'Settings', it could be one form checkbox:
[x] Guided Configuration Walkthrough
Adjusting the 'Language' settings would be the first part of the
walkthrough.
>
> However, why not
> to ask first for a language if there is none saved in case we don't
> find another satisfying solution.
>
We could just ask for a language preference, as opposed to running
through the whole configuration flow, leaving the guided configuration
experience as an always present link. This, too, could be a 'Settings'
item, though one of much less value, as an auto detect for a language
preference could be enough to keep the language request dialog from
always showing up.
>>
>> We could also do something super simple, like this[0], though that
>> might
>> be too simple as well as bare the burden of a click, and ultimately,
>> more flow fragmentation.
>>
> I don't really get the proposal? Do you mean a welcome/check and go
> screen with three buttons, one for each set of settings? If yes, how
> does it solve the language issue and its discoverability.
>
Ignore this. It is just a tangential thought about a more minimal
dialog screen. Though it would resolve the language issue as noted
above.
>
> What is an IA outline?
>
Information architecture outline. It is a navigation tree, but with
each element listed in addition to the location, and in the form of an
outline. You may already call it by a different name.
>>
>> to effectively determine the impact
>> of the first and third issues, with a mockup/flow study, or two, being
>> needed to determine the impact of the second issue.
>>
> Would you like to convey such a study if we agree it's relevant?
>
I would.
>>>>
>>>> However, I understand and
>>>> respect the desire to accommodate different use cases and the
>>>> varying
>>>> technical understanding of people by having two separate
>>>> configuration
>>>> flows. Having two paths requires a decision, though, and an 'Edit'
>>>> button is an effective way of addressing this.
>>>
>>> I really don't think the edit button to be appropriate for the
>>> "Language" section. Why not for the "Advanced" one if we find no
>>> better
>>> way.
>>
>> An 'Advanced' button is interesting, but we would also need a button
>> to
>> enter the guided configuration flow, and the 'Edit' button with two
>> path
>> choices addresses this in an effective manner, even if only the
>> language
>> options are displayed - though 'Edit' would need a more effective
>> label,
>> and then doesn't make as much sense as the questions then become
>> "Would
>> you like to configure some other settings than are displayed here?"
>> and
>> "Which of these two paths would you like to take to configure the
>> other
>> settings that are not displayed here, the "guided" or the "non-guided"
>> path?"
>>
>> If we have the language section separate from the two configuration
>> flows, we have the same architectural structure we are exploring away
>> from.
>
> Do we agree that we should have the storage section together with the
> language one as directly accessible to allow people to unlock their
> storage straight away (it they have one).
>
Yes, a directly editable 'Storage' section should be front and center.
I am more in favor of an auto-detect feature for the 'Language' flow, as
opposed to an always present discoverable one. But this will need a
proper information outline to be sure.
>>
>> Maybe, to cut down on the fragmentation, we have a directly
>> editable language section that has an expandable advanced section
>> below
>> it,
>
> Looks like quite good. I like the summary of your buttons in
> GreeterMinimalFirstScreen.png. Perhaps the expandable section could
> display such a summary when not expanded? Or the summary could just be
> a
> button that shows another screen
>
I will try and explore this.
>>
>> and, if the arrow or plus sign is actioned to display the advanced
>> settings, the section, in addition to the more technical settings,
>> also
>> reveals a button to enter the guided configuration flow - or maybe
>> this
>> is simply a link and is always displayed.
>>
> I like the idea of a "Guided" button that would always be there, e.g.
> at the top of the screen and that could be used not only to configure
> the advances settings but also to have kind of a "tour" including the
> e.g. the storage settings
>
I have been using a 'Learn more about Tails' link that rests towards the
bottom of the dialog. The thought is based on the flow of a person's
thought where they arrive at the thought that they need help after
moving through the rest of the information.
>>
>> This[1] is what I am thinking. We keep the language settings fixed
>> and
>> directly editable.
>>
> OK. I think we could agree on GreeterAdvancedSettings (with the 2nd
> option after the "or" being more coherent with GNOME desktop practices
> I think) BUT the storage section should be always displayed IMHO and
> not be included in advances settings.
>
Okay. Let me make something and attempt to resolve some of the
conflicting issues/resolutions we are discussing here.
>>
>> We could also do an initiation where people are invited to enter into
>> a
>> more advanced experience with the setting up of the administration
>> password/encryption, like activating 'Developer Options' on
>> Android/Cyanogen.
>>
> I don't get this proposal.
>
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.
>>
>> ... Designer
>>
>
> I don't absolutely reject a title, just want to be honest about my
> background and skills.
>
Got it ;)
>>>
>>> [expanding upon privacy implications]
>>>
>>> - Whatever the content of the option is, saving an option saves
>>> information on the user the device (key) belongs to. If I'm an
>>> adversary that gets a Tails device in Italy, having an italian
>>> language set doesn't give me much information as it's likely most
>>> Tails in Italy have it. On the other hand, any other option saved
>>> on
>>> the clear further reduces the anonymity set of the user.
>>> - some settings, like saving Tor bridges (unencrypted) gives
>>> information that highly reduces the anonymity of the user in an
>>> adversary gets the device
>>
>> I look at editing the settings of a device that I own as an
>> administrative task. Couldn't this be addressed with the protection
>> of
>> an administrative password that decrypts the settings?
>>
> Yes, this is an option to save some of these settings in the encrypted
> storage, if present. That should still be investigated more to know
> which setting is relevant and safe to save this way.
>
We should investigate this to know for sure, because it would make for a
very effective interface should we achieve the proper grouping of
elements, in this case, saving all of the settings from one place.
>
> To summarize:
>
> - I do agree with proposal "GreeterAdvancesSettings" (if put "Storage"
> settings outside the "+")
> - we still have to precise how we edit each setting
> - we still have to agree on a way to make language discoverable
> - should we have a summary of advanced settings displayed upfront (at
> least if some diverging from defaults are selected?)
>
