Susan:
> Hi all. I am new to the discussion. I worked with Saj at IFF this
> year on some task flow wireframes and getting workshop feedback. I'm
> a newbie at Tails but have 20 years in usability and interaction
> design.
>
> Thanks for allowing me to help as possible. I'll mostly lurk and
> learn.
Thanks for joining the discussion!
> I do have a few small concerns about this design:
>
> https://labs.riseup.net/code/attachments/download/1344/Greeter.Encrypted.Storage.png
As a general note, these drawings are mockups made by Spencer, I guess
using Illustrator, but for the implementation we're relying on the Gtk
toolkit from GNOME, the desktop environment that we have in Tails and
which is also the most popular over Linux distros in general.
You can see some of their default widgets here:
https://developer.gnome.org/hig/stable/ui-elements.html.en
So, in this particular case I uploaded some real screenshots of the
prototype so you can see the real widgets:
The whole window:
https://labs.riseup.net/code/attachments/download/1353/locked.png
The locked state:
https://labs.riseup.net/code/attachments/download/1355/locked-small.png
The unlocked state:
https://labs.riseup.net/code/attachments/download/1354/unlocked-small.png
> * I'm concerned about the lack of contrast in two areas, which is an
> accessibility issue for everyone but may also impact being able to
> notice state changes. The two areas of contrast concern for me are
> the icons (blue on blue) and the thin, white font on the blue
> background.
The blue on blue icon is black on blue in the prototype, and as you're
mentioning later on, the icon might be moved out of the button. If it
stays inside the button, I think it should be the same color as the text.
> I suggest going with bold fonts on dark backgrounds for better
> legibility. The best practice is for the font size to increase 2
> points in size when light fonts are on dark backgrounds in order to
> retain the same legibility as the same font when dark on a light
> background.
You can see on the screenshots the default font that we get from the Gtk
toolkit. Do you think this is better in term of readability?
They use blue buttons for "suggested" action. I'm personally not sure
the "Unlock" button here deserves this special status so I would be fine
to going back to a gray background here as well.
> The text on the long button and in the password field now seems a bit
> small compared with the others, so bumping it up a size and using
> bold on the blue backgrounds seems wise there as well.
I'm not sure why Spencer put a smaller than usual text on the long
button but, in the screenshots, both the long and short buttons have the
same text size.
> * The lock is apparently not a button(?), but it looks just like the
> buttons do.
Yes! I mentioned this already to Alan in this thread (#8 on
https://mailman.boum.org/pipermail/tails-ux/2016-April/000936.html).
> * Beyond contrast and what's-a-button confusion, some further
> emphasis may be needed to allow people to understand the feedback
> when the state changes from Encrypted to Unlocked storage. The open
> lock may not be a strong enough signal, especially if the label
> "Encrypted Storage" stays the same regardless of locked/unlocked
> state.
>
> Alternatives:
>
> - You could change the lock area to have a white background to solve
> both contrast and button-confusion issues
>
> - You could move the lock indicator up to the label area above the
> field, near the label.
>
> - (Possibly the best idea) It would make a lot of sense to move the
> lock icon to the button on the right, so that the indicator and the
> button that changes it are in the same control, where the users'
> attention is focused.
You mean moving the lock icon "inside" the button? or "nearby" the button?
If the icon is inside the button should it display:
A. The current state of the storage: a closed lock with "Unlock"?
B. The state after the action has been performed: an open lock with
"Unlock"?
If the icon is nearby the button but not inside it, I guess it should
display the current state.
> * The toggle button is a bit small for touch access, and very close
> to the Lock/Unlock button, which could cause some annoying error
> messages if a finger slips while trying to show the passphrase.
>
> Alternatives:
>
> - Maybe the toggle switch isn't needed because you have a word label
> that could be the action (button), which would also make the
> click/tap target larger. A text label by itself could change from
> "Show" Passphrase to "Hide" when toggled.
>
> - Or you could move this show/hide control toward the middle of the
> row so that it's not so close to the button.
>
> In any case, the toggle control itself should be 2x larger if the OS
> allows it. Most touch controls should be about the size of the
> smallest fingertip and spaced so that that fingertip won't press two
> things at once.
>
> - Toggles for password show/hide have been implemented in web UIs as
> checkboxes under the password area and as eye icons in the field
> itself in apps. I don't have any testing data on which approach
> would be more recognizable for users, but in my extensive testing
> experience with other UIs, people tend to first click on the biggest
> target, which in this case seems to be the words, even though those
> are probably not actionable in this design. A good argument for the
> eye icon is that you might not have to localize it. If the icon looks
> big enough to be a button/icon and not just a glyph/indicator, then
> people will probably experiment with it. On a desktop system you
> could add rollover labels to it.
Here again, it's a pity you didn't have the screenshots to comment on.
You'll see that we implemented this using a checkbox which has an
actionable label.
We put it in the top right corner to match the other checkbox that we
put for "Save Language Settings" that you can see here:
https://labs.riseup.net/code/attachments/download/1341/Greeter.Explained.png
but not on the screenshot as the backend for this is not implemented.
Would this work?
