https://labs.riseup.net/code/attachments/download/1354/unlocked-small.png
is also a good contender for testing, IMO, if the background of the lock were white and the lock segment didn't act like a button.
If you continue to work with this design, maybe the label could be "container" instead of "storage". I like that plan because it removes a bunch of words.
I think this design is pretty much equivalent to putting the lock near the label above and using "Lock" and "Unlock" on the button, but it may have an advantage over that design because the lock is larger and in the line of sight more.
https://labs.riseup.net/code/attachments/download/1354/unlocked-small.png
I like the contrast between the unlocked "bar" and locked open field. It would make more sense to me if the barrier represented the closed container and the opening corresponded to open container, but I don't know how the interaction design may help the design you have here.
In the 1Password example, the lock ends up open on the left side after having travelled all the way across the password entry zone and then the whole password entry widget quickly disappears, showing the contents behind. If you type a wrong word, the lock tries to cross the field, but then turns momentarily red and goes back to the right side so you can try again.
It's often helpful to echo a successful interaction design so that things work alike and users only have to learn them once. Possibly some kind of open/close or other animation would be helpful with this widget, because it says so much without having to rely on words alone.
I hope this helps stimulate your ideas. I don't have any great new ideas about how to animate or reinforce open/close at the moment.
https://labs.riseup.net/code/attachments/download/1353/locked.png
I love the explanation about defaults being safest in most situations.
Susan
On May 6, 2016, at 7:11 AM, sajolida <sajolida@???> wrote:
> 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?
> _______________________________________________
> Tails-ux mailing list
> Tails-ux@???
> https://mailman.boum.org/listinfo/tails-ux
>
>
