Hey,
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.
STORAGE
-------
=> Do not have both input and "Configure Encrypted Storage"
Why configure and input in the same line ?
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"
- There is no persistence:
I suggest: have a "Configure Encrypted Storage" button with one
sentence.
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 know there is some issues about the collapsing UI. I'm trying to write
something about Guidelines, but it's not yet finished.
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.
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).
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.
TEST
----
I can review the mockups with NUMA people and/or do user testing session
on paper or with a real prototypes this fall.
Cheers,
tchou
[1]
https://tails.boum.org/blueprint/greeter_revamp_UI/design_rationale_phase1/
[2]
https://mailman.boum.org/pipermail/tails-ux/attachments/20150114/77c5004c/attachment-0001.svg
(Remember basics + persistence : "this option is on, so more black")
spencerone@???:
> Hi,
>
> Thanks for the responses! After some exploration the Greeter eventually
> reached a point where some decisions need to be made. Each needed
> decision is listed below with a brief summary and accompanied by a link
> to an image, with more info on each image.
>
> As always, feel free to share your thoughts. Keep in mind that although
> we will benefit from arguments for, we also really need arguments
> against, so please do not be shy.
>
>
> NEEDED DECISIONS:
>
> Structure Types[0]
> ---------------
> There are three different structures.
>
> • Step-by-step - Guided walkthrough
> • Show/Hide - Hidden off-screen or behind on-screen element
> • Openface - Full display
>
> [0] - Greeter.Decision.00.svg
>
>
> Start Tails Button Location[1]
> ------------------------------
> Should the location of the button be in either the top Greeter frame or
> the bottom of the Greeter canvas?
>
> • Top
> • Bottom
>
> [1] - Greeter.Decision.01.svg
>
>
> Color Blocking[2]
> -----------------
> Should the canvas either split into cells to emphasize separate content
> or stand-alone as a single-celled canvas?
>
> • Blocked
> • Not Blocked
>
> [2] - Greeter.Decision.02.svg
>
>
> Settings Labels[3]
> ------------------
> Should the settings sections be labeled with either two or three labels?
>
> • Two
> • Three
>
> [3] - Greeter.Decision.03.svg
>
>
> Label Icons[4]
> ---------------------
> Should icons accompany either the section labels or the line item labels?
>
> • Section
> • Line Item
>
> [4] - Greeter.Decision.04.svg
>
>
> Close Greeter[5]
> ---------------------
> Should the Greeter have the option to be closed?
>
> • Close
> • No Close
>
> [5] - Greeter.Decision.05.svg
>
>
> Display/Hide[6]
> ---------------------
> Should the Greeter use display/hide functionality to manage information?
>
> • Accordion
> • Drawer
>
> [6] - Greeter.Decision.06.svg
>
>
> Other Options[7]
> ---------------------
> Should we explore other Greeter options?
>
> • Icon Buttons
> • Icon & Text Buttons
> • Icon, Text, & Info Buttons
> • List Item Buttons
>
> [7] - Greeter.Decision.07.svg
>
>
> Once we decide on these things we can bust out a mockup that embodies
> the new decisions and we can hopefully move into each of the settings
> options, e.g., Keyboard Language, and so on.
>
> I have kept the explanations as brief as I could, so please ask
> questions if you got 'em.
>
> Wordlife,
> Spencer
>
>
> _______________________________________________
> Tails-ux mailing list
> Tails-ux@???
> https://mailman.boum.org/listinfo/tails-ux
>
--
tchou
