Re: [Tails-ux] Encrypted Storage

tchou:
> 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".

Sure, I answered your first email without seeing the second one. Sorry
about that.