Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T100375 Improve user experience of Two-Factor process | |||
Resolved | Dbrant | T150899 Support 2FA in Wikipedia Mobile applications | |||
Resolved | Mhurd | T150699 [iOS] Allow users to log in with 2FA in the app | |||
Resolved | None | T150985 Update login interface | |||
Resolved | Mhurd | T154727 Design/UX tweaks to login related errors |
Event Timeline
Need to add coverage for additional error cases. I was not sure of the desired text, so I did not add additional rows to the "other system messages" section. I ran across the attached case while at a cafe. I imagine there are additional cases to cover, but we should have messaging for blocked usernames and blocked IP addresses and perhaps the reason for the block.
@cmadeo Reminder from planning meeting: consider overall form vertical height impact on layout when used in combination with larger dynamic text sizes. (i.e. moving progressive button down from title bar, landscape on phone - for larger keyboard - but longer form needing more scrolling, etc)
Also here: https://phabricator.wikimedia.org/T154725
Oh, we may also have issues if the alerts move inline if the keyboard is covering an inline alert (or if the user is landscape and had to scroll) the user would not be able to see the inline alert...
Discussed some of the issues surrounding this ticket with @Mhurd yesterday:
- The invalid username message that is returned to us does not have a specific enough message title or consistent enough messaging to replace it with an inline error message at this point.
- It might be possible to check for invalid usernames before the user submits their create account credentials. @Mhurd is going to look into seeing if the UN string can be checked after the user removes focus from the UN text box (so that we don't have to wait until the user taps on the 'Next' button)
- This sub ticket (T158253) defines when the inline (in)valid(ation) messaging should be shown for the password and retype password fields so that we don't have to wait until the user taps on the 'Next' button to alert users that their passwords don't match.
Finally, we'll be utilizing a system message for invalid username error messaging (see above) but will move forward with inline messaging for password confirmation (T158253).
I'll need investigate which of these are done. Per @Fjalapeno try to knock out as many of these as are presently possible to detect, file backlog ticket for any stragglers.
@Mhurd, per our meeting:
- Inline alert for 2FA verification fail
- Update red to #d33
- Update yellow to #fc3
- Updated green to #00af89
@Mhurd it still looks like the inline alert after the password confirmation on login is using orange instead of #fc3
@cmadeo hmm looks like login inline alert is using red...
Acct creation pwd match seems to be using the correct yellow...
Do you want the login invalid pwd inline alert to use yellow instead of red?
I'm sorry @monte, I could have sworn it was orange this morning! I might have checked before updating my app. My fault. Everything looks good to me.