Issue: Improve the navigation in newpassword view #365
Comments
GabrielNagy
added a commit
that referenced
this issue
Jun 25, 2024
Instead of showing both prompts from the get-go, and having Enter submit
the form straight away (and only being able to navigate through it with
Tab), such as:
Enter your new password
> ****
>
We now render a single input if the user has just been shown the form:
Enter your new password
> ****
When pressing Enter -- provided that the password passes our quality
checks -- the form changes to:
Enter your new password (confirm)
> ****
>
This makes it clearer that we want the user to re-type their password. As a
result, Tab navigation is no longer supported, and the form can only be
advanced by pressing Enter.
Fixes #365 / UDENG-3112
GabrielNagy
added a commit
that referenced
this issue
Jun 26, 2024
Instead of showing both prompts from the get-go, and having Enter submit
the form straight away (and only being able to navigate through it with
Tab), such as:
Enter your new password
> ****
>
We now render a single input if the user has just been shown the form,
with an updated prompt:
Enter your new password
New password: ****
When pressing Enter -- provided that the password passes our quality
checks -- the form changes to:
Enter your new password (confirm)
New password: ****
Confirm password:
This makes it clearer that we want the user to re-type their password.
As a result, Tab navigation is no longer supported in non-skippable
views, and the form can only be advanced by pressing Enter.
For skippable views (i.e. with a button), Tab only works if the password
is not filled in. This avoids opening a can of worms regarding to what
fields we should be showing or not based on whether password fields are
filled in. Thus, the skippable experience becomes:
Enter your new password (3 days until mandatory)
New password:
[ Skip ] // Focusable
and
Enter your new password (3 days until mandatory)
New password: *****
[ Skip ] // No longer focusable, have to finish filling in the form
// (or clear it)
Otherwise, I believe we should keep the form as simple as possible,
without the possibility of jumping back to the previous password field
once it was filled in, at the sake of improved maintainability.
Fixes #365 / UDENG-3112
GabrielNagy
added a commit
that referenced
this issue
Jun 27, 2024
Instead of showing both prompts from the get-go, and having Enter submit
the form straight away (and only being able to navigate through it with
Tab), such as:
Enter your new password
> ****
>
We now render a single input if the user has just been shown the form,
with an updated prompt:
Enter your new password
New password:
> ****
When pressing Enter -- provided that the password passes our quality
checks -- the form changes to:
Enter your new password (confirm)
New password:
> ****
Confirm password:
> ****
This makes it clearer that we want the user to re-type their password.
As a result, Tab navigation is no longer supported in non-skippable
views, and the form can only be advanced by pressing Enter.
For skippable views (i.e. with a button), Tab only works if the password
is not filled in. This avoids opening a can of worms regarding to what
fields we should be showing or not based on whether password fields are
filled in. Thus, the skippable experience becomes:
Enter your new password (3 days until mandatory)
New password:
>
[ Skip ] // Focusable
and
Enter your new password (3 days until mandatory)
New password:
> *****
[ Skip ] // No longer focusable, have to finish filling in the form
// (or clear it)
Otherwise, I believe we should keep the form as simple as possible,
without the possibility of jumping back to the previous password field
once it was filled in, at the sake of improved maintainability.
Fixes #365 / UDENG-3112
GabrielNagy
added a commit
that referenced
this issue
Jun 27, 2024
Instead of showing both prompts from the get-go, and having `Enter`
submit the form straight away (and only being able to navigate through
it with `Tab`), such as:
Enter your new password
> ****
>
We now render a single input if the user has just been shown the form,
with an updated prompt:
Enter your new password
New password:
> ****
When pressing `Enter` -- provided that the password passes our quality
checks -- the form changes to:
Enter your new password (confirm)
New password:
> ****
Confirm password:
> ****
This makes it clearer that we want the user to re-type their password.
As a result, `Tab` navigation is no longer supported in non-skippable
views, and the form can only be advanced by pressing `Enter`.
For skippable views (i.e. with a button), `Tab` (and `Shift-Tab`) only
works if the password is not filled in. This avoids opening a can of
worms regarding to what fields we should be showing or not based on
whether password fields are filled in. Thus, the skippable experience
becomes:
Enter your new password (3 days until mandatory)
New password:
>
[ Skip ] // Focusable
and
Enter your new password (3 days until mandatory)
New password:
> *****
[ Skip ] // No longer focusable, have to finish filling in the form
// (or clear it)
Otherwise, I believe we should keep the form as simple as possible,
without the possibility of jumping back to the previous password field
once it was filled in, at the sake of improved maintainability.
Fixes #365 / UDENG-3112
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there an existing issue for this?
Describe the issue
In the newpassword view the password creation / update looks like:
It is not clear what is expected from the user, neither if it is the creation of a local password and its confirmation.
The prompt must state the expected action clearly as well as the to navigate the field.
Steps to reproduce it
.
Ubuntu users: System information and logs
No response
Non Ubuntu users: System information and logs
Environment
/etc/os-release)/etc/os-release):Log files
Please redact/remove sensitive information:
Application settings
Please redact/remove sensitive information:
Relevant information
No response
Double check your logs
The text was updated successfully, but these errors were encountered: