232357 - "Cancel" button in Switch Profile dialog should become "Close" after managing profiles

Status: RESOLVED EXPIRED

(SeaMonkey :: Startup & Profiles, defect)

Description

[Alex Eng]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040125

After modifying user profiles (i.e. create, rename, or delete) from the Switch
Profile dialog box (Tools | Switch Profile), the caption of the Cancel button
should read "Close".

Reproducible: Always
Steps to Reproduce:
1. Click on the Tools menu and then select Switch Profiles.

2. In the dialog box that appears, choose Manage Profiles.

3. Create a profile, rename an existing profile, or delete an existing profile
by choosing the appropriate button.  (One of the three actions will suffice.)  

4. Follow the instructions in the resulting dialog boxes.  Be sure to
successfully complete the operation (by choosing "OK" or "Yes" when prompted).

Actual Results:  
After any of the above three profile management actions are successfully
completed, the caption on the Cancel button is unchanged.

Expected Results:  
After any of the above three profile management actions are successfully
completed, the caption on the Cancel button should change to read "Close".

Leaving the button caption as "Cancel" after creating, renaming or deleting a
profile implies that whatever operation performed could be undone by clicking
Cancel.  On the other hand, "Close" implies that the profile management actions
are permanent, and that clicking "Close" will dismiss the Switch Profile dialog
box, and nothing more.

Comment 1

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040316] (W98SE)

AFAICT, the button is always labelled |Cancel|,
since the dialog opening at step 1, to the end.

Then the issue is simply to rename the button to |Close|,
not to deal with it being named |Cancel| or |Close| depending on the step(s).

Do you confirm this ?

Comment 2

[Alex Eng]

(In reply to comment #1)
> [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040316] (W98SE)
> 
> AFAICT, the button is always labelled |Cancel|,
> since the dialog opening at step 1, to the end.
> 
> Then the issue is simply to rename the button to |Close|,
> not to deal with it being named |Cancel| or |Close| depending on the step(s).

No.  Even if the user didn't do anything, the button label should still be
initially "Cancel", as per generally-accepted UI design standards.  When the
dialog box appears, the user instantly sees this as a "bail-out" cue in case
he/she later chooses not to interact with this dialog box any further, or pursue
any changes made in the available dialog box options.  (In the case of the
Switch Profile dialog box, the only option is "Don't ask at startup".)  Most
dialog boxes (for example, the Preferences dialog), have the "Cancel" button
always labelled as such when the dialog first appears.  Initially labelling it
as "Close" would be confusing, since at the initial state (when the dialog first
appears, and before the user changes any dialog box options), "OK" and "Close"
would be functionally equivalent.

However, changing the label from "Cancel" to "Close" after the profile
management tasks have successfully completed makes sense, since those tasks
can't be undone so instantly as "Cancel" would lead the user to believe.

Comment 3

[Serge Gautherie (:sgautherie)]

(In reply to comment #2)
> 
> (In the case of the
> Switch Profile dialog box, the only option is "Don't ask at startup".)
> 
> However, changing the label from "Cancel" to "Close" after the profile
> management tasks have successfully completed makes sense, since those tasks
> can't be undone so instantly as "Cancel" would lead the user to believe.

I understand :-)

But then, after making management changes, the button would change to |Close|,
but the "Don't ask at startup" state (if changed) would not be saved by
"Closing", would it ?

I don't know much about "generally-accepted UI design standards";
then, I would prefer either to rename the button to |Close| and make the "Don't
ask at startup" state always persist (no "Cancel" feature)...
or mark this bug as ("Invalid" or)"Won't Fix"...

ccarlen:
Any thoughts ?

Comment 4

[Alex Eng]

(In reply to comment #3)
> But then, after making management changes, the button would change to |Close|,
> but the "Don't ask at startup" state (if changed) would not be saved by
> "Closing", would it ?
> 

Good point.  In such a situation, the button caption stays "Cancel" if the user
changed the "Don't ask at startup" state, regardless of whether the profile
management tasks completed successfully or not.

Sigh.  This dialog box would then become complicated and confusing from the end
user point of view.  I can only imagine very complicated use case scenarios for
such a trivial dialog box as Switch Profile.  I think there should be a clear
separation of profile selection vs. profile management; in that case, the "Don't
ask at startup" and the "Use Profile" button shouldn't be visible at all in
profile management mode.  The old profile selection dialog from Netscape 4.x is
a better design, IMO.

Comments from UI design experts are welcome!

Comment 5

[Alex Eng]

An additional comment to what I just wrote.....

(In reply to comment #4)
> Good point.  In such a situation, the button caption stays "Cancel" if the user
> changed the "Don't ask at startup" state, regardless of whether the profile
> management tasks completed successfully or not.
>

Arguably, this would be bad design, because the "Cancel" button applies to the
"Don't ask at startup" option, but not to the profile management tasks that were
performed.  The user can cancel out from the dialog and the checkbox option will
be unsaved, but creating or deleting profiles won't be undone.  

At this point, I'm thinking that this is more of a UI design issue affecting the
entire dialog box rather than a debate over the caption of a single trivial
button.  I'm comtemplating closing this bug and opening a new one for further
discussion on the UI of the *entire* Switch Profile dialog, but I'd like to hear
additional comments/suggestions first.

Comment 6

[Serge Gautherie (:sgautherie)]

(In reply to comment #5)
> (In reply to comment #4)
> I'm comtemplating closing this bug and opening a new one for further
> discussion on the UI of the *entire* Switch Profile dialog, but I'd like to hear
> additional comments/suggestions first.

I did not read your two last comments in depth,
nevertheless, I would suggest to file that new bug, and make it block the
current one for the time being.

Comment 7

[Conrad Carlen (not reading bugmail)]

I think that the profile switching UI should be separate from the profile
management UI. "Switch Profile" should be next to "Quit Mozilla" since, really,
it's a shortcut to quit and restart with a different profile. Profile management
is a separate thing and, IMO, belongs in the Tools menu.

Comment 8

[Serge Gautherie (:sgautherie)]

(In reply to comment #7)
> I think that the profile switching UI should be separate from the profile
> management UI.

Sounds good to me;

alex:
Can you file that new bug, when you get a chance ? Thanks.

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420