2 deleted 9 characters in body
source | link

The core reason that you don't want to do this is because, as a general rule, any time you override the standard behavior of a users device, you open yourself up to a bad user experience . . . particularly if you do it without any kind of notification.

Overall, within your application, standard control behaviors should continue to behave the way that the user expects them to behave.


Now, in this case, the change would not likely be known, since the password generally stays masked, but, both technically and experientially, there are ways that it could become apparent.

Example 1: many new technologies are allowing you the "show password" when entering it. This would quickly expose the altered behavior (sans any explanation). Best case, this causes confusion, worst case, they conclude that their keyboard is broken.

Example 2: if a users password were "abc123XYZ", there may be times when the user were to use caps lock for the last 3 characters (e.g., on a mobile device) and others when they want to hold down the shift key (e.g., when using a full keyboard).

If the caps lock were suppressed when the password was created, there is potential that the password was actually set to "abc123xyz", without the user ever knowing it, because they expected the key to function as it always doesnormally. Best case, this causes confusion, worst case, their account gets locked due to too many "bad login attempts", despite having entered in what should have been the correct characters.

The core reason that you don't want to do this is because, as a general rule, any time you override the standard behavior of a users device, you open yourself up to a bad user experience . . . particularly if you do it without any kind of notification.

Overall, within your application, standard control behaviors should continue to behave the way that the user expects them to behave.


Now, in this case, the change would not likely be known, since the password generally stays masked, but, both technically and experientially, there are ways that it could become apparent.

Example 1: many new technologies are allowing you the "show password" when entering it. This would quickly expose the altered behavior (sans any explanation). Best case, this causes confusion, worst case, they conclude that their keyboard is broken.

Example 2: if a users password were "abc123XYZ", there may be times when the user were to use caps lock for the last 3 characters (e.g., on a mobile device) and others when they want to hold down the shift key (e.g., when using a full keyboard).

If the caps lock were suppressed when the password was created, there is potential that the password was actually set to "abc123xyz", without the user ever knowing it, because they expected the key to function as it always does. Best case, this causes confusion, worst case, their account gets locked due to too many "bad login attempts", despite having entered in what should have been the correct characters.

The core reason that you don't want to do this is because, as a general rule, any time you override the standard behavior of a users device, you open yourself up to a bad user experience . . . particularly if you do it without any kind of notification.

Overall, within your application, standard control behaviors should continue to behave the way that the user expects them to behave.


Now, in this case, the change would not likely be known, since the password generally stays masked, but, both technically and experientially, there are ways that it could become apparent.

Example 1: many new technologies are allowing you the "show password" when entering it. This would quickly expose the altered behavior (sans any explanation). Best case, this causes confusion, worst case, they conclude that their keyboard is broken.

Example 2: if a users password were "abc123XYZ", there may be times when the user were to use caps lock for the last 3 characters (e.g., on a mobile device) and others when they want to hold down the shift key (e.g., when using a full keyboard).

If the caps lock were suppressed when the password was created, there is potential that the password was actually set to "abc123xyz", without the user ever knowing it, because they expected the key to function normally. Best case, this causes confusion, worst case, their account gets locked due to too many "bad login attempts", despite having entered in what should have been the correct characters.

1
source | link

The core reason that you don't want to do this is because, as a general rule, any time you override the standard behavior of a users device, you open yourself up to a bad user experience . . . particularly if you do it without any kind of notification.

Overall, within your application, standard control behaviors should continue to behave the way that the user expects them to behave.


Now, in this case, the change would not likely be known, since the password generally stays masked, but, both technically and experientially, there are ways that it could become apparent.

Example 1: many new technologies are allowing you the "show password" when entering it. This would quickly expose the altered behavior (sans any explanation). Best case, this causes confusion, worst case, they conclude that their keyboard is broken.

Example 2: if a users password were "abc123XYZ", there may be times when the user were to use caps lock for the last 3 characters (e.g., on a mobile device) and others when they want to hold down the shift key (e.g., when using a full keyboard).

If the caps lock were suppressed when the password was created, there is potential that the password was actually set to "abc123xyz", without the user ever knowing it, because they expected the key to function as it always does. Best case, this causes confusion, worst case, their account gets locked due to too many "bad login attempts", despite having entered in what should have been the correct characters.