[Tails-ux] Greeter Feedback [was: Greeter mockups]

Delete this message

Reply to this message
Autor: spencerone
Data:  
A: tails-ux
Assumptes vells: Re: [Tails-ux] Greeter mockups
Assumpte: [Tails-ux] Greeter Feedback [was: Greeter mockups]
Hi,

>
> tchou:
> Back in the Greeter. I tried to read all the last messages and the
> blueprint [1] (you did a great job!), but maybe I missed some stuffs
> and
> did not understood things. Maybe I should have replied in dedicated
> emails, sorry for that.
>
> So, here are my feedbacks and thoughts. If I don't mention things, it's
> that I'm probably OK with the current proposal.
>


Thank you for taking the time to read through all of this and respond!

>
> STORAGE
> -------
> => Do not have both input and "Configure Encrypted Storage"
>
> Why configure and input in the same line ?
>


The thought was to make it visually unclear if storage existed or not,
since we are filling it technically. However, it makes sense that the
form reflect the function and display only an input field for all cases.

>
> CONTENT STRUCTURE TYPES & OPTIONS AVAILABLE ON THE 1ST SCREEN
> -------------------------------------------------------------
> => Show/Hide - Hidden off-screen or behind on-screen element
>
> We need to find the good balance between "Greeter revamp: Consider
> merging basic and advanced screens" (#8976 & "lot of screens" in #8235)
> and "Greeter revamp: Feedback to the user which options are going to be
> used" (#8974).
>
> The proposal I did with NUMA [2] was neither to show nor hide advanced
> setting, it was in-between : to show icons, with the state of the
> options (black for on, light for off) and the details collapsed.
>


I like this, as it makes sense and balances the two options, but I think
it would be Tails-specific, yeah?

>
> START TAILS BUTTON LOCATION
> ---------------------------
> => Bottom of Greeter
>
> I feel that the most use case is someone who has persistence and wants
> to use it. It's a kind of "login" (without user) userflow:
> - type a passphrase in the input
> - click on "login"
> The usual flow for login is to click just after, or just bellow the
> input the "login" button (here the "start tails" button).
>
> An other common use case is the "new comer". Maybe the user goes
> through
> the tour, maybe he changes his language, and then login. I think we
> want him to go through the interface from top to bottom, to discover
> and be warmed of what's on/off and what's possible.
>


Yes. At first the top-to-bottom flow seemed most appropriate (it looked
nice, too), but then we needed to accommodate for multiple flows and
forcing the two most occurrent use cases, start Tails with saved and
default settings, to navigate through the dialog seemed unnecessary.

The benefit to the top action bar location for the 'Start Tails' button
is that it opens up the bottom space for other buttons to accommodate
other top-to-bottom flows, like navigating through the sections
following the Guided Configuration flow[0].

>
> SECTION ORDER AND LABELS
> ------------------------
> I suggest an other order:
> => Language, Settings, Storage
>
> As above, I feel the most common use case "passphrase usecase", and
> while it's a pass *phrase*, it happen quite often that the passphrase
> is
> wrong. I think it's good to have the feedback message the closest from
> where the user clicked (and I suggest to keep the wrong passphrase and
> have something to reveal it and correct it).
>


I think the feedback can be more localized. We can even go text-less
and display something more subtle but still just as clear. Shake
animations, colored borders, and so on, for example. As opposed to only
displaying a 'Fail'/'Success' message.

>
> CLOSE GREETER
> -------------
> => No Close/Restart
> In fact, I'm in favor of removing the failsafe screen. I think that if
> you go there to add an option or select "failsafe", it's because there
> is a problem or a super specific thing that you want to do and than the
> documentation or the support team said you to do. I think that we could
> ask to hold a key or something to make this screen appears. When
> something is happening not often, we don't have to ask the user to take
> a decision (Live or Live (failsafe) <= and maybe he want to be safer ?)
>
> But anyway, if we remove it or not, I think that it's something that is
> not happening often (and maybe never once you are in the greeter) to go
> back in the failsafe screen.
>


I never understood the setting. Someone with more technical knowledge
of the function would need to advise on the details. However, a soft
reset from the Greeter might still be useful if we remove the failsafe
mode.

But if we keep the setting, and therefore the screen, we should see
about making the USB Stick and DVD failsafe screens match (one is black
and one is gray).

Wordlife,
Spencer

[0]:
https://mailman.boum.org/pipermail/tails-ux/attachments/20150828/2b2c6b68/attachment-0005.png