'Done' button operation

I requested that the following posts be split off from the Community Applications thread.  It is a discussion of a modification of the operation of the done / cancel button

 

 

 

* About the Done button, we really should press for a behavior change.  I can't see how it can be justified to leave a page without saving changes, and it constantly causes confusion, seems non-standard.  Using 'OK' and 'Cancel' might seem like copying Windows, but would make it intuitive to more users.  It's good you expanded on how it works now.  We might even want to make it stronger, with a leading 'Warning!' in red.

I cannot agree more strongly with this point.  I always find the 'Done' button is easily accidentally pressed and changes lost.  One possible recommendation for change while still keeping the current style would be that it popped up a warning about 'unsaved changes' and asked if you wanted to lose the changes.  Another possibility would be that when the Apply button was enabled the Done button was changed to read Cancel.  This would probably not be difficult to do and would make the consequence of pressing it more obvious.

 

 

I was surfing around, and found a posting from RobJ / itimpi, thought about it and decided that they were 100% correct.  The operation of the Done and Apply buttons throughout unRaid are counter-intuitive for most people who come from a Windows environment where the done button also applies any changes.  While this plugin has always had a "You have unapplied changes" warning in it, pressing Done (like anywhere else in the UI) would effectively cancel the changes, not apply them (as Windows would).

 

To address this and make it less error prone for users, I've added a single line of code to the settings module which changes the Done button to be a cancel button when changes are made.  After applying the changes, the button turns back to be done again.

 

 

 

Updated to 2015.06.17b

To address this and make it less error prone for users, I've added a single line of code to the settings module which changes the Done button to be a cancel button when changes are made.  After applying the changes, the button turns back to be done again.

 

Actually a very good idea, I can make a global function which does exactly the above and individual plugin authors don't need to do this explicitely for each plugin. Something for an upcoming release of Dynamix.

 

* About the Done button, we really should press for a behavior change.  I can't see how it can be justified to leave a page without saving changes, and it constantly causes confusion, seems non-standard.  Using 'OK' and 'Cancel' might seem like copying Windows, but would make it intuitive to more users.  It's good you expanded on how it works now.  We might even want to make it stronger, with a leading 'Warning!' in red.

I cannot agree more strongly with this point.  I always find the 'Done' button is easily accidentally pressed and changes lost.  One possible recommendation for change while still keeping the current style would be that it popped up a warning about 'unsaved changes' and asked if you wanted to lose the changes.  Another possibility would be that when the Apply button was enabled the Done button was changed to read Cancel.  This would probably not be difficult to do and would make the consequence of pressing it more obvious.

 

 

I was surfing around, and found a posting from RobJ / itimpi, thought about it and decided that they were 100% correct.  The operation of the Done and Apply buttons throughout unRaid are counter-intuitive for most people who come from a Windows environment where the done button also applies any changes.  While this plugin has always had a "You have unapplied changes" warning in it, pressing Done (like anywhere else in the UI) would effectively cancel the changes, not apply them (as Windows would).

 

To address this and make it less error prone for users, I've added a single line of code to the settings module which changes the Done button to be a cancel button when changes are made.  After applying the changes, the button turns back to be done again.

 

 

 

Updated to 2015.06.17b

Sounds good.    Does the result feel more intuitive?

Sounds good.    Does the result feel more intuitive?

Not sure...I've gotten so used to hitting Apply everywhere in unRaid before hitting Done that I don't even think about it (I have made those same mistakes when I was first starting around here).

 

Why don't you try it and tell me.

 

* About the Done button, we really should press for a behavior change.  I can't see how it can be justified to leave a page without saving changes, and it constantly causes confusion, seems non-standard.  Using 'OK' and 'Cancel' might seem like copying Windows, but would make it intuitive to more users.  It's good you expanded on how it works now.  We might even want to make it stronger, with a leading 'Warning!' in red.

I cannot agree more strongly with this point.  I always find the 'Done' button is easily accidentally pressed and changes lost.  One possible recommendation for change while still keeping the current style would be that it popped up a warning about 'unsaved changes' and asked if you wanted to lose the changes.  Another possibility would be that when the Apply button was enabled the Done button was changed to read Cancel.  This would probably not be difficult to do and would make the consequence of pressing it more obvious.

 

 

I was surfing around, and found a posting from RobJ / itimpi, thought about it and decided that they were 100% correct.  The operation of the Done and Apply buttons throughout unRaid are counter-intuitive for most people who come from a Windows environment where the done button also applies any changes.  While this plugin has always had a "You have unapplied changes" warning in it, pressing Done (like anywhere else in the UI) would effectively cancel the changes, not apply them (as Windows would).

 

To address this and make it less error prone for users, I've added a single line of code to the settings module which changes the Done button to be a cancel button when changes are made.  After applying the changes, the button turns back to be done again.

 

 

 

Updated to 2015.06.17b

Sounds good.    Does the result feel more intuitive?

 

Just made the change, and it does make things more intuitive.

 

See added screenshots in my earlier post ...

 

 

I haven't played with the new 'Cancel' button yet.

 

However what you are describing only makes sense if both the 'Apply' and the 'Cancel' buttons close the dialogue.  If 'Apply' leaves the dialogue open, then some might expect 'Cancel' to undo any applied settings.

 

Personally, I like 'Apply' to keep the dialogue open, but then the other button should say 'Exit', 'Back' or 'Close'.

I haven't played with the new 'Cancel' button yet.

 

However what you are describing only makes sense if both the 'Apply' and the 'Cancel' buttons close the dialogue.  If 'Apply' leaves the dialogue open, then some might expect 'Cancel' to undo any applied settings.

 

Personally, I like 'Apply' to keep the dialogue open, but then the other button should say 'Exit', 'Back' or 'Close'.

Apply does keep the window open.  Once the changes are applied, then the cancel button doesn't exist anymore, and the done button appears.  But I see what you're saying...  I'll let bonienl make the decisions here, especially if he adds a global functions that all plugins and UI elements in unRaid can adhere to.

I haven't played with the new 'Cancel' button yet.

 

However what you are describing only makes sense if both the 'Apply' and the 'Cancel' buttons close the dialogue.  If 'Apply' leaves the dialogue open, then some might expect 'Cancel' to undo any applied settings.

 

Personally, I like 'Apply' to keep the dialogue open, but then the other button should say 'Exit', 'Back' or 'Close'.

 

As you can see in the screenshots in the earlier post, by default Apply is disabled and Done is displayed.

 

Making a change in a setting(s) will enable the Apply button and shows a Cancel button next to it.

 

When the Apply is clicked to confirm the change(s) it will go back to the beginning with a disabled Apply and enabled Done button

 

I haven't played with the new 'Cancel' button yet.

 

However what you are describing only makes sense if both the 'Apply' and the 'Cancel' buttons close the dialogue.  If 'Apply' leaves the dialogue open, then some might expect 'Cancel' to undo any applied settings.

 

Personally, I like 'Apply' to keep the dialogue open, but then the other button should say 'Exit', 'Back' or 'Close'.

 

As you can see in the screenshots in the earlier post, by default Apply is disabled and Done is displayed.

 

Making a change in a setting(s) will enable the Apply button and shows a Cancel button next to it.

 

When the Apply is clicked to confirm the change(s) it will go back to the beginning with a disabled Apply and enabled Done button

Guess I'll have to pump out another update tomorrow to disable the apply button...

Guess I'll have to pump out another update tomorrow to disable the apply button...

 

When Apply and Done buttons are part of a form element then the housekeeping of these buttons is done by Dynamix. You don't need to do anything special (of course the Done/Cancel part isn't there yet).

 

itimpi, are you feeling the power too?  I only have to express a wish, then you agree and add the details, and just like that the genies appear and make it happen! 

itimpi, are you feeling the power too?  I only have to express a wish, then you agree and add the details, and just like that the genies appear and make it happen! 

Power to the people 

 

Yes definitely like the revised behaviour.  It feels a far more accurate reflection of what is going to happen.

I think it makes the "Unsaved Changes" warning superfluous - what do you think?

IMHO changing the function/text of a button dynamically can be confusing to new users, but if you want to change it, ok, as long as everything is consistent: I don't want plugins operating differently than stock pages.

 

Here's the background on the "Done" button.  This was introduced pre-dynamix for really one reason.  When you delete a Share or delete a User, when webGui page is refreshed that Share or User is gone (because it's been deleted).  In order to provided feedback to user I wanted page to display "Share has been deleted" or "User has been deleted" and then a button that navigated explicitly to the ShareList or UserList page - and it didn't work to "go back" (well sometimes that worked, but depending on how you got to the ShareEdit or UserEdit page the navigation was confusing).  Also I didn't want someone clicking 'back' button on browser because that took them to the now-defunct edit page for that share or user.

 

Hence I introduced the Done button.  Now to get people used to clicking a Done button, I put that thing on every page and on most pages it just is the same as "back".

 

In windows you have "OK", "Cancel" and "Apply".  Ok and Apply both apply the changes; Apply stays on the window, Ok dismisses the window; and, of course Cancel dismisses window without applying changes.  I chose the word "Done" specifically so that it was different than windows.

 

Personally I never liked the Done button.  It's been a longstanding item on my own 'todo' list to get rid of it.  Instead I would have only Apply which is disabled unless user changes a field.  When user wants to leave the page he clicks Back on the browser or simply chooses another page from the main menu.  Never got around to this because there have always been bigger fish to fry on the todo list.....

Also I should add: in observing users running on OSX it's sometimes confusing to them that they have to click Apply to make changes happen.  This is because of course there's no such thing in OSX, when you change a preference it just changes.

 

Edit: I guess this was maybe the purpose behind "You have uncommitted changes" warning?

I think it makes the "Unsaved Changes" warning superfluous - what do you think?

 

That's already gone right?  Actually I think the entire Confirmations settings page should just go away.

Actually, you know changing something like this shouldn't be taken lightly because of pile of documentation written, past user experience, etc.

Actually, you know changing something like this shouldn't be taken lightly because of pile of documentation written, past user experience, etc.

Which is why this plugin is a good little test case.  The settings section will only be used by most users once (if at all).  Lets us play with some ideas to see how they actually work in the real world without making changes across the board.

Tom's point is right of course, any change to the general user experience should be weighed carefully.  This change though seems like a no-brainer, completely intuitive, removes a source of frustration, minimal doc changes, and easy to implement, transparently to other authors.  Anyone who has ever made this mistake and lost settings changes will immediately understand the change, and appreciate it, no documentation needed!  The documentation changes are small, not time critical, because of how intuitive it seems.  So it seems to me to be a very low impact change, except for the safety and usability gains.

Actually, you know changing something like this shouldn't be taken lightly because of pile of documentation written, past user experience, etc.

 

Certainly all these conditions need to be taken into consideration with these kind of changes.

 

Most importantly for me is consistency: use everywhere the same labels and let them do the same type of action otherwise you end up with confused users.

 

Actually the term "Done" is not badly chosen imho, we are not closing or exiting a window but simply finishing an action.

 

Should i undo my changes then?  Or leave them as an experiment?

 

Should i undo my changes then?  Or leave them as an experiment?

 

I believe you made the Done button change to Cancel when a setting is changed, right ?

 

You could leave it in as an experiment, it can always be changed later - if needed.

 

Yup.  That's it

Should i undo my changes then?  Or leave them as an experiment?

 

I believe you made the Done button change to Cancel when a setting is changed, right ?

 

You could leave it in as an experiment, it can always be changed later - if needed.

 

 

Instead of Cancel, call it Reset, then get rid of the Reset button on the left.

 

When user first navigates to page they see only

  (Apply)

  Done

 

The paren's mean button is disabled.

 

If they change any form field buttons change to:

  Apply

  Reset

 

If they click Reset, it undos all their changes and returns back to:

  (Apply)

  Done

 

If they click Apply, it applies their changes and returns to:

  (Apply)

  Done

 

If they click Done, well they're done!

 

Not sure if this is feasible to do.

 

With Reset all fields return to their value prior to the change and before Apply, but certain pages have fields/dropdowns enabled or disabled depending on the setting of another variable in the list. These are specific and individual cases which can not be captured in a single global action, which is required to make all pages work consistenly in the same manner.

 

 

Not sure if this is feasible to do.

 

With Reset all fields return to their value prior to the change and before Apply, but certain pages have fields/dropdowns enabled or disabled depending on the setting of another variable in the list. These are specific and individual cases which can not be captured in a single global action, which is required to make all pages work consistenly in the same manner.

After Apply you can't Reset, so Reset could just reload the page from the current settings.