Hi tchou and everybody,
tchou <tchou@???> wrote:
> 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.
>
Please note that you are very late
>
> STORAGE
> -------
> => Do not have both input and "Configure Encrypted Storage"
>
> Why configure and input in the same line ?
>
This is a mistake, thanks for pointing this out.
> I see to possibilities:
>
> - There is a persistence:
> It's possible to change the configuration of the persistence but
> it's something that is not done so often. So I suggest :
> - change the label "storage" to "encrypted storage"
> - have a "configure" button link like the "Save Language Changes"
>
I think that when the storage is locked, we should have the unlock
controls, and when unlocked the configuration controls (see dedicated
thread.
> - There is no persistence:
> I suggest: have a "Configure Encrypted Storage" button with one
> sentence.
>
Right
> 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.
>
> So:
> - we have less screens
> - the main screen is still light
> - information is discoverable
>
I think the problem with that is that it is unclear and that it is not
common among GNOME UX.
I propose to display the options that diverge from defaults and add a
"+" button to add options (see my other email).
> 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.
>
This is not what we decided, because:
- the button at the top is the GNOME guideline for action dialogs[1]
- it makes sense to click "Start Tails" without changing options
1:
https://developer.gnome.org/hig/stable/dialogs.html.en#action-dialogs
> 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 disagree with you. Putting settings before storage emphasize
settings, which is the opposite of the feedbak sajolida and you said
before that defaults should be preferred I think.
To solve your issue, I
propose that if the user logs in and the passphrase (or anything else)
is wrong we should better have an infobar [2] at the top of the window.
2:
https://developer.gnome.org/gtk3/stable/GtkInfoBar.html
>
> 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.
>
That should be another discussion
> TEST
> ----
> I can review the mockups with NUMA people and/or do user testing session
> on paper or with a real prototypes this fall.
>
Great!
Cheers
