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.
I do have a few small concerns about this design:
https://labs.riseup.net/code/attachments/download/1344/Greeter.Encrypted.Storage.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.
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.
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.
* The lock is apparently not a button(?), but it looks just like the buttons do.
* 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.
* 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.
Best wishes,
Susan
On Apr 29, 2016, at 7:49 PM, Spencer <spencerone@???> wrote:
> Feel free to take a look at the existing proposal screenshots [0][1] and make changes that would lessen the lock state indicator's appearance as a button.
>
> The crazier the idea the better (:
>
>> do without the [secondary] description in parenthesis
>
> Less is more.
>
> I hope these comments find you in good company (:
>
> Wordlife,
> Spencer
>
> [0]: https://labs.riseup.net/code/attachments/download/1320/Greeter.States.png
> [1]: https://labs.riseup.net/code/attachments/download/1344/Greeter.Encrypted.Storage.png
>
%20and%20the%20thin,%20white%20font%20on%20the%20blue%20background.%20%0A>%20%0A>%20I%20suggest%20going%20with%20bold%20fonts%20on%20dark%20backgrounds%20for%20better%20legibility.%20The%20best%20practice%20is%20for%20the%20font%20size%20to%20increase%202%20points%20in%20size%20when%20light%20fonts%20are%20on%20dark%20backgrounds%20in%20order%20to%20retain%20the%20same%20legibility%20as%20the%20same%20font%20when%20dark%20on%20a%20light%20background.%20%0A>%20%0A>%20The%20text%20on%20the%20long%20button%20and%20in%20the%20password%20field%20now%20seems%20a%20bit%20small%20compared%20with%20the%20others,%20so%20bumping%20it%20up%20a%20size%20and%20using%20bold%20on%20the%20blue%20backgrounds%20seems%20wise%20there%20as%20well.%0A>%20%0A>%20*%20The%20lock%20is%20apparently%20not%20a%20button(?),%20but%20it%20looks%20just%20like%20the%20buttons%20do.%20%0A>%20%0A>%20*%20Beyond%20contrast%20and%20what's-a-button%20confusion,%20some%20further%20emphasis%20may%20be%20needed%20to%20allow%20people%20to%20understand%20the%20feedback%20when%20the%20state%20changes%20from%20Encrypted%20to%20Unlocked%20storage.%20The%20open%20lock%20may%20not%20be%20a%20strong%20enough%20signal,%20especially%20if%20the%20label%20%22Encrypted%20Storage%22%20stays%20the%20same%20regardless%20of%20locked/unlocked%20state.%0A>%20%0A>%20Alternatives:%20%0A>%20%0A>%20-%20You%20could%20change%20the%20lock%20area%20to%20have%20a%20white%20background%20to%20solve%20both%20contrast%20and%20button-confusion%20issues%0A>%20%0A>%20-%20You%20could%20move%20the%20lock%20indicator%20up%20to%20the%20label%20area%20above%20the%20field,%20near%20the%20label.%20%0A>%20%0A>%20-%20(Possibly%20the%20best%20idea)%20It%20would%20make%20a%20lot%20of%20sense%20to%20move%20the%20lock%20icon%20to%20the%20button%20on%20the%20right,%20so%20that%20the%20indicator%20and%20the%20button%20that%20changes%20it%20are%20in%20the%20same%20control,%20where%20the%20users'%20attention%20is%20focused.%20%0A>%20%0A>%20*%20The%20toggle%20button%20is%20a%20bit%20small%20for%20touch%20access,%20and%20very%20close%20to%20the%20Lock/Unlock%20button,%20which%20could%20cause%20some%20annoying%20error%20messages%20if%20a%20finger%20slips%20while%20trying%20to%20show%20the%20passphrase.%20%0A>%20%0A>%20Alternatives:%20%0A>%20%0A>%20-%20Maybe%20the%20toggle%20switch%20isn't%20needed%20because%20you%20have%20a%20word%20label%20that%20could%20be%20the%20action%20(button),%20which%20would%20also%20make%20the%20click/tap%20target%20larger.%20A%20text%20label%20by%20itself%20could%20change%20from%20%22Show%22%20Passphrase%20to%20%22Hide%22%20when%20toggled.%20%0A>%20%0A>%20-%20Or%20you%20could%20move%20this%20show/hide%20control%20toward%20the%20middle%20of%20the%20row%20so%20that%20it's%20not%20so%20close%20to%20the%20button.%0A>%20%0A>%20In%20any%20case,%20the%20toggle%20control%20itself%20should%20be%202x%20larger%20if%20the%20OS%20allows%20it.%20Most%20touch%20controls%20should%20be%20about%20the%20size%20of%20the%20smallest%20fingertip%20and%20spaced%20so%20that%20that%20fingertip%20won't%20press%20two%20things%20at%20once.%0A>%20%0A>%20-%20Toggles%20for%20password%20show/hide%20have%20been%20implemented%20in%20web%20UIs%20as%20checkboxes%20under%20the%20password%20area%20and%20as%20eye%20icons%20in%20the%20field%20itself%20in%20apps.%20%20I%20don't%20have%20any%20testing%20data%20on%20which%20approach%20would%20be%20more%20recognizable%20for%20users,%20but%20in%20my%20extensive%20testing%20experience%20with%20other%20UIs,%20people%20tend%20to%20first%20click%20on%20the%20biggest%20target,%20which%20in%20this%20case%20seems%20to%20be%20the%20words,%20even%20though%20those%20are%20probably%20not%20actionable%20in%20this%20design.%20A%20good%20argument%20for%20the%20eye%20icon%20is%20that%20you%20might%20not%20have%20to%20localize%20it.%20If%20the%20icon%20looks%20big%20enough%20to%20be%20a%20button/icon%20and%20not%20just%20a%20glyph/indicator,%20then%20people%20will%20probably%20experiment%20with%20it.%20On%20a%20desktop%20system%20you%20could%20add%20rollover%20labels%20to%20it.%0A>%20%0A>%20Best%20wishes,%0A>%20%0A>%20Susan%0A>%20%0A>%20On%20Apr%2029,%202016,%20at%207:49%20PM,%20Spencer%20<spencerone@???>%20wrote:%0A>%20%0A>%20>%20Feel%20free%20to%20take%20a%20look%20at%20the%20existing%20proposal%20screenshots%20%5B0%5D%5B1%5D%20and%20make%20changes%20that%20would%20lessen%20the%20lock%20state%20indicator's%20appearance%20as%20a%20button.%0A>%20>%20%0A>%20>%20The%20crazier%20the%20idea%20the%20better%20(:%0A>%20>%20%0A>%20>>%20do%20without%20the%20%5Bsecondary%5D%20description%20in%20parenthesis%0A>%20>%20%0A>%20>%20Less%20is%20more.%0A>%20>%20%0A>%20>%20I%20hope%20these%20comments%20find%20you%20in%20good%20company%20(:%0A>%20>%20%0A>%20>%20Wordlife,%0A>%20>%20Spencer%0A>%20>%20%0A>%20>%20%5B0%5D:%20https://labs.riseup.net/code/attachments/download/1320/Greeter.States.png%0A>%20>%20%5B1%5D:%20https://labs.riseup.net/code/attachments/download/1344/Greeter.Encrypted.Storage.png%0A>%20>%20%0A>%20%0A>%20%0A>%20 "Répondre à ce message")
