Re: [Tails-ux] Greeter design proposal rationale

Supprimer ce message

Répondre à ce message
Auteur: Alan
Date:  
À: tails-ux
Sujet: Re: [Tails-ux] Greeter design proposal rationale
Hi,

On Fri, 28 Aug 2015 17:20:52 -0700
spencerone@??? wrote:
> I worked through the Greeter alternatives being preferred by everyone
> and was able to identify some key concerns being weighed that we can
> focus on to move forward and have complete consensus.
>
> TL;DR - This[4] is what we should do. Why? Read below :)
>
> ---------------------------------------------------------------------------------------------------
>
> Note that the 'Storage' section is updated to reflect the current
> Greeter Rationale[0]. However, I am unfamiliar with the benefits of
> 'Enable' though I have trust and have included it; Alan, would you
> explain so that I understand?
>

I think that there is a misunderstanding. If you mean the [Enable] text
in [0], I think it refers to an icon you would click to enable the
storage.

[0]:
https://tails.boum.org/blueprint/greeter_revamp_UI/design_rationale_phase1/#index9h3

> Also note that I spaced out the current proposal[1] and that 'Language'
> is ordered first as agreed.
>

Great!

>
> Key Concerns:
>
> 1. Available canvas space as 'Privacy' options increase
>
> 2. One-click Access [vs] Two-click Access
>
>
> Rationale:
>
> 1. If 'Language' is not grouped with 'Privacy' then they should not
> resemble each other (though tchou has some thoughts on still grouping
> them with 'Language' ordered first).


I don't agree. The design you proposed before is coherent with GNOME3
design, while the one-liner:

- looks strange to me
- is far less clear about which line is what

> Also, Tails has a 'Language'
> string at the footer during the current Greeter experience that, other
> than its placement, is quite functional. Using this could prevent
> needing pagination for the self-guided flow because it frees up so much
> vertical space. Here[2] is what the change would look like.
>
> 2. To settle the pagination issue it seems that the question should be:
> which is more important, one-click access, which means everything on one
> dialog, or pagination of the 'Privacy' settings, which means two-click
> access.


I think that we should:

- take into account sajolida's point that it seems we agreed on not
having the privacy settings displayed upfront
- keep the idea of a "check and go" screen that was one of the key
principles of our design proposals and solves our tickets #8974 and
#8976
- find a way to have something whould act like an expandable section
but would fit the GNOME HIG

> However, I worked through that and discovered something. Given
> the logic to move "these are your DEFAULT settings" to the 'Settings'
> section, there is no confirmation to the self-guided user that they are
> using default privacy settings.


We should keep this information on the 1st screen I think!

> Because of this, 'Start Tails' is
> de-emphasized until they move to the next dialog. This change conflicts
> with the highly occurrent use case of starting Tails with default
> settings on one click.


Please see the attached proposal.

> This also brings back the fork-in-the-road issue that I feel is best
> resolved with a single button with two paths forking from there, as seen
> here[3]; the mental model is more clear this way.
>
> But for those who just despise the idea of a Mac-like 'Edit' button,
> here[4] is the way we should go. This isolates each step as the
> default, Guided Configuration, and allows people to switch to
> Self-guided Configuration.
>
> Why is *this* the way to go?
>


These two proposals reintroduce things that we dropped in the
previous process, with good reasons I think.

Cheers