[kde-guidelines] Password Field

Björn Balazs b at lazs.de
Sat Dec 7 09:44:33 UTC 2013


Am Freitag, 6. Dezember 2013, 22:27:20 schrieb Thomas Pfeiffer:
> On Friday 06 December 2013 15:20:23 Aaron J. Seigo wrote:
> > On Friday, December 6, 2013 14:58:32 Björn Balazs wrote:
> > > Actually I am not such a big fan of the double entry security myself. If
> > > I
> > > should have switched e.g. Caps Lock on, the two passwords are actually
> > > the
> > > same - even though I won't be able to enter the password the next time
> > > correctly.
> > 
> > that’s a really good point.
> > 
> > hell i’ve managed to mistype a password the same way twice before :P
> > 
> > > What do you think - would we still need the double entry of a NEW
> > > password,
> > > when we can choose to show the password inline?
> > 
> > probably not, though typos can still make it in. would need testing over
> > time, but i like the idea of the “just show me my damn password” :)
> 
> What we have to prevent is people creating a new password with a single
> masked entry, especially since in the rare cases where you set a password
> locally (which is where that HIG would apply mostly), there is no "I forgot
> my password" option. I am open to any solution which does that.
> Just completely disabling the masking wherever a new password is set and
> preventing changing a password while the field is masked would be a viable
> solution, thought it would mean that people cannot set new passwords while
> in a public space.
> Personally, I would even be okay with showing a re-type field only if the
> original field is masked, but showing/hiding the re-type field when the
> original one is masked/unmasked might feel weird.

So we should add to the styleguide that a recovery is preferable to a double 
entry? If there is no recovery option possible, we should first enforce that 
user do have any keyboard modificators (Caps Lock) switched on. And then?

I do not like a jumpy interface which offers two password fields when entries 
are invisible and only one when they are visible. Then I would prefer to 
always go for two fields as to say: Look, this is important!


> > > This was actually the start for my thoughts. When designing on the
> > > networkmanager, this horrible 'show the password' line simply gets in
> > > the
> > > way all of the time :) - so a more compact solution would be great.
> > 
> > +100
> 
> I'm fine with an inline masking control. As long as we do have that control
> and people notice it, I don't have a strong opinion on where it's positioned
> or what it looks like.

So how do we proceed? Ask Nuno for a design? Who would provide the code that 
others can embed?

> > > > > The coffee shop next door uses a whole, less meaningful sentence as
> > > > > password. Something like 'diekuhliefumdenteichundfieldannrein'.
> > > > > Would
> > > > > be
> > > > > hard to make sure that it was typed right when I see the last letter
> > > > > only.
> > > > > And it couldn't get validated by the waitress.
> > > > 
> > > > "i like Björn’s suggestion of something in the line itself."
> > > 
> > > Kai Uwe pointed me to the fact that Windows 8 is using something like
> > > that,
> > > e.g. [1].
> > > 
> > > I am really not sure whether we need this 'show last digit' thing -  I
> > > would like to hear other opinions about it.
> > 
> > imho, it should be sth we add only if it turns out to be actually needed.
> > 
> > > simply suggest to keep the last setting and hence have no configuration.
> > > There is not a lot of potential harm, because (at least if I look at the
> > > screen) I immediately see whether the password is shown or not. I can
> > > then
> > > easily toggle the state.
> 
> +1 for not having a config option.
> 
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines



More information about the kde-guidelines mailing list