|Open||None||T100375 Improve user experience of Two-Factor process|
|Open||None||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|
- Mentioned In
- rAPIOS6000b8996b90: Merge pull request #1286 from wikimedia/feature/auth-alert-tweaks/T154727
rAPIOS30dc231f8462: Merge branch 'develop' into feature/auth-alert-tweaks/T154727
- Mentioned Here
- T158253: Inline messaging triggers for password validation
T155835: Mobilefrontend doesn't allow raw HTML in toast messages
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).