Re: [Tails-ux] Revamped greeter preview ISO available

Delete this message

Reply to this message
Autor: sajolida
Data:  
A: Tails user experience & user interface design
Assumpte: Re: [Tails-ux] Revamped greeter preview ISO available
Susan:
> Apologies for my hiatus! I had something urgent to attend to. I'll try to work
> my way backward as needed from this message.


That's ok. On this particular project we're all doing this as volunteers
with no deadline and it's being going on for more than a year. So we're
used to long hiatuses :)

> Have you seen how 1Password does this? You type into the form analogous to the
> 3rd screenshot of yours, below. It has only a lock on it. When you finish typing
> the password and press Enter, the lock animates and moves across the field,
> unlocking itself like a little zipper or something.


Nice!

> Now that I see the four designs I'm quite worried that the lock and the word,
> when on the same button, are sending conflicting signals. For that reason I also
> prefer 2 and 4. I think 3 could work fine if we took the word off the button as
> 1Password does. (I'm counting the files from the top down.)


A difference between 1Password and our design, if I understand correctly
the screenshot, there's nothing else to do on this screen than entering
a password. So you are forced to enter it and then press Enter to
continue. In our screen, entering this password is only one option. You
might not unlock your persistant storage, or you might unlock it and
configure more things before starting Tails.

I initially felt like this made a difference in how verbose things
should be regarding the "Unlock" action. But we also agreed on
performing "Unlock" anyway when people click "Start Tails" if a
passphrase has been entered (to be forgiving). So this might allow us to
omit the label on the "Unlock" button to avoid conflicting messages.

I'm attaching two more mockup without the "Unlock" label, and no icon on
"Relock". I will use this PDF to do my tests and I invite Spencer to do
the same. We can always iterate and refine once we have some results.

> I am hopeful that user testing can discover whether the unlocked encrypted
> paradox is a problem. Maybe if you called it an encrypted container, your mental
> model would propagate. "Persistent storage" is accurate but not very evocative.


Right. That's something else I wanted to discuss with you. We've been
hesitating for a while on the terminology around "persistence".
"Persistence" is the insider jargon but we felt we needed something else
to show to the user. I'll try to explain you all the issues behind this
soon, but not today. (But I like "container"!)

Susan:
> 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.


There will definitely be some visual feedback on the open/close moment
but I also want to be very careful and not design things that would be
very complicated to implement or require Alan to code super custom
widget. So I'd like to have his take on what's easily possible in terms
of animation before designing something.