Author: tchou Date: To: Tails user experience & user interface design Subject: Re: [Tails-ux] Encrypted Storage
sajolida: > Lunar:
>> > tchou:
>>> >> Just to say it again, to make it clear that I disagree with one tiny point :
>>> >> - I think that most of the time wrong "password" are *passphrase* typo
>>> >> (and kind of long)
>>> >> - In the case, my point is that i think it's better to keep the wrong
>>> >> passphrase and make it possible to read it (with the "show passphrase"
>>> >> button) and fix the typo. We can add a "clear" button too.
>> >
>> > Let me rephrase to make sure we understand one another: you are saying
>> > that most of the time errors in passphrase are just typo. For that
>> > reason, you advocate that we should not erase the whole field in case of
>> > errors because it gives a chance to correct the typo and proceed with
>> > login.
>> >
>> > [Please correct me if I got it wrong.]
>> >
>> > I agree on the first assumption. I do typos in my passphrases all the
>> > time.
>> >
>> > But then? I don't want to take the chance to have my passphrases learned
>> > by bystanders looking at my screen. Once I made a mistake, I can't learn
>> > where is the typo by looking at identical black circles. So starting
>> > again from the beginning is the only option.
>> >
>> > If someone is confident that they are safe having the passphrase
>> > displayed on screen, they can always click the “Show passphrase” button
>> > before entering the passphrase and fix typos while they are typing it.
>> >
>> > Not clearing a wrong passphrase would make the greeter behave
>> > differently from all software on the Tails desktop from the quick look I
>> > had at it.
>> >
>> > Sadly, I haven't been able to find this question mentioned in GNOME HIG.
>> > Maybe that's worth opening a bug there?
> I tend to agree with Lunar on this.
>
> I've never seen a password interface behaving like this and I suspect
> this to look like a fancy idea that ends up being a bad one (first of
> all because it's unusual). So honestly, I don't think it's worth "trying
> to fix" password entry fields this way; or at least I fail to see why
> our particular context is different from every other password field I've
> see in production so far.
>
> We can probably find hints about password entry fields in other HIG
> (Mac, Microsoft) and probably UX research in the academic literature.
> But I won't volunteer to do that or spend too much energy on this issue.
Maybe it's because of asynchronous communication, but I just said " So
I'm finaly OK with the current proposal".
