Review Request 126505: Do not show a warning color before the user even started typing

Elvis Angelaccio elvis.angelaccio at kdemail.net
Sat Dec 26 22:25:35 UTC 2015



> On Dec. 26, 2015, 10:17 p.m., Thomas Pfeiffer wrote:
> > Just one question: Why should a mismatch only be considered when the two have the same length?
> > Couldn't you show the warning as soon as an actual mismatch is detected, even if that happens before the confirmation password has the same length as the original one?
> > 
> > Example:
> > Original password is 1234
> > I type in the second field:
> > 1 -> nothing happens
> > 2 -> nothing happens
> > 4 -> Mismatch error is shown, because no matter what else I type, unless I change the third character in the confirmation, it's definitely a mismatch
> > 
> > This would be especially important for long passwords that are typed in masked mode, because it would save the user from typing e.g. 10 more characters before being informed about the mistake they made in the second character
> > Otherwiese it sounds good!

Nice, I didn't even think to detect a mismatch in this way. I will try tomorrow, should be easy to implement.


- Elvis


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126505/#review90126
-----------------------------------------------------------


On Dec. 24, 2015, 5:53 p.m., Elvis Angelaccio wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126505/
> -----------------------------------------------------------
> 
> (Updated Dec. 24, 2015, 5:53 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability, Christoph Feck, David Faure, and Thomas Pfeiffer.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> -------
> 
> As discussed in RR 125619 and 126426, the password verification field (in a KNewPasswordWidget) should not be marked as "wrong" before the user even started typing the verification password.
> 
> My revised approach is the following:
> 
> * the first time, no "warning color" is displayed at all. The user types something as password and then something else as verification password.
> * If a match occurred (e.g. pwd = 1234 and verification = 1234), we "enable" the warning color. So if the user "breaks" the match (e.g. changing the value in one of the two fields) the warning color will be displayed.
> * Otherwise, if a mismatch occurred, we also enable the warning color and we show it immediately. A mismatch occurs when the password and the verification password have same length but different content (e.g. pwd = 1234 and verification = 1233).
> 
> 
> Diffs
> -----
> 
>   autotests/knewpasswordwidgettest.h 43845128adec01aced4353c9f7986b7977829a2a 
>   autotests/knewpasswordwidgettest.cpp 297b88d5f18b9cd37f0d26d94e56f38870756f20 
>   src/knewpasswordwidget.cpp a1b59454a2c2d7c09ac32acec52d3fffa73f77fc 
> 
> Diff: https://git.reviewboard.kde.org/r/126505/diff/
> 
> 
> Testing
> -------
> 
> Autotests assert what described above. Gif pictures would explain the patch better than 1000 words, but I suck at creating them :(
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151226/ca0b50d3/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list