3

I'm developing an application that has user based access.

Each user can change some settings for their profile (localization, timezone, the password, etc). I've chosen to perform autosave (a la Apple's settings) on each change. As soon as you click on a setting it is automatically saved. I'm pretty confident with this choice.

My question is: do you think that even a password change (with a confirmation box) can be handled that way or is better to have an explicit "change" or "save" button?

The dialog for changing the password is modal and it contains only two fields:

                          X
password: [           ]
confirm:  [           ]

If the password is too short or the confirm does not match, an error message is displayed below in realtime (the check is performed on every keypress).

The dialog can be only closed with the X on the upper left corner. On close the password is changed if the two field don't produce an error, otherwise the dialog remains open.

What do you think? Any suggestion?

UPDATE: I forgot to say that if the two fields are left blank, the dialog closes without saving a new password.

Improve this question

1 Answer 1

Reset to default
7

Let me get this straight.

On close the password is changed if the two field don't produce an error, otherwise the dialog remains open.

Effectively the user has no choice but to change the password? As long as the passwords don't match, the X doesn't do anything? So if he wants to close the dialog, the only way to enable the X is by changing the password? And I suppose there's no error message on this, on top of the one already displayed about the mismatching passwords. You're leaving him no option to reconsider, that's very bad usability.

A separate issue is the implicit saving. "X" means close, it never means "save and close", but it often does mean "cancel and close", or at least "close without saving". Only by trial and error will the users be able to figure this one out. And the fact that all the other settings are saved on click doesn't matter here because they don't bring up dialogs. The dialog turns it into a completely different game.

I say definitely go with a "Save" button. And if these are the real labels, then I'd rename the first to "new password" - because often users need to enter their old password before they can change it.

On top of that, I'd also show a success message after "Save" is pressed.

Leave the X enabled always, with the meaning of "close without saving". If you see that the user entered a new password and pressed X, prompt him: "your new password wasn't saved. Close without saving? [Yes/Cancel]". Or, possibly, [Close without saving / Save and close].

Improve this answer
2
  • I forgot to say that if the two fields are left empty, the password is not changed on X. The first field is named "New password". I agree with you that the X means "close and cancel", but is there a way to remain in the "autosave" philosophy in this case?
    – ALoR
    Commented Apr 22, 2011 at 23:05
  • 1
    I don't see one that would work well. But I don't think we should even be looking for one - passwords are a sensitive area, and if you do something by mistake, it may be hard to recover from or undo it. I think it's best to make things as explicit as possible in this case. Since the interaction takes place in a dialog, I don't think that users would feel that it's inconsistent with the rest of the app.
    – Vitaly Mijiritsky
    Commented Apr 23, 2011 at 7:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.