Upon saving the user edit page, users are confused that their changes may not be submitted. This is because they see the password confirmation field again, and some fields may be pre-filled by the browser.
Ever since I've started running a Drupal site I've received complaints from newbie users struggling with changing their password. Finally, I've been able to identify one of the issues:
Newbie users can easily get confused when they click [Save] and the User|Edit form comes back to them, seemingly begging to enter and confirm the new password again, especially with a theme where the confirmation message is (too) discreet. If the browser is set to fill in the password, then it's even more confusing, because the Password field will be filled in and the Confirm password field will be empty, as if the confirmation somehow failed.
As an easy fix, I propose to redirect to User|View after saving, like we do for nodes, for example. For the normal user there's no point in staying on the User|Edit page.
For an administrator it could occasionally be useful to remain on the User|Edit page while trying out various settings. If we consider this an important feature, then we could make the redirection depend on not having the 'administer users' permission.
This does not require any string changes and if it's accepted, I'd like to see it back-ported to D7 and D6.
Edit your user profile.
After a user edits their account redirect to the the view of the account. This will be consistent with what happens when editing other entities.
Write a patch.
Add a test.
Review.
Rejoice.
Yes, the user is redirected to the view of their account after editing the account.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | user_edit_redirect.1524438.3.patch | 3.7 KB | salvis |
| #1 | user_edit_redirect.1524438.1.patch | 2.92 KB | salvis |
Comments
Comment #1
salvisHere's a patch.
Comment #3
salvisMissed one test, try again.
Comment #4
iaha commentedI agree that this is a usability issue, but I think it's just as confusing to redirect back to the view. Also, if confirmation messages are not prominent enough to be noticed in a theme, that seems like a more widespread issue with the theme to me.
In my mind, a password reset is a common enough "lay user" process that deserves its own form and I think burying it in the middle of the catch-all user settings form is where the confusion lies.
Comment #7
Leeteq commentedAgreeing with @iaha in #4, and there are also other practical (positive) side effects of placing the password change fields on its own tab/url.
Comment #8
mgiffordUnassigning so someone else can take it on.
Comment #11
dpiConverted to issue template, added summary.
Comment #18
avpadernoComment #23
quietone commentedI talked to aaronmchale about this in #usabiltity. They suggested checking what happens when editing other entities. I checked node, term and menu link. After saving changes to those content type one is redirected to the view of that entity. So, it seems that the user entity is the odd one out and that the suggested change here should be done to be consistent.
Although there is a patch here, it is outdated so I am setting this to Active.
Comment #24
aaronmchaleWe reviewed this issue at #3277946: Drupal Usability Meeting 2022-05-06.
I thought it would be valuable to get the input of the wider group at the meeting, so presented this issue and the proposed resolution of redirecting to the View page instead of staying on the Edit page.
The group was also unanimously in favour of doing this, both in terms of making user consistent with the other core content entity types, but also in terms of avoiding the confusion of users described in the issue summary.
We also discussed if there would be any impact on admin users making updates to multiple users, and after discussion we determined that this would not be an issue because it's likely that admin users would access the User Edit screen from the People screen and so in that case they would already be redirected back to the People screen thinks to the existing "destination" parameter in the URL.
We should take care to ensure that any change here does not break that existing behaviour.
Comment #25
benjifisherFor the record, the attendees at the 2022-05-06 usability meeting were @AaronMcHale, @bnjmnm, @ckrina, @rkoller, @worldlinemine, @shaal, and me.