Page 1 of 1

Improve wording of buttons "cancel" and "Abort"

Posted: Mon Sep 01, 2014 9:09 pm
by GeorgD
Several dialogs have "not so helpful" button names, e.g. in v0.68
1) when "Edit IPTC-IIM/XMP" or "Batch Convert" already finished the action, the button "cancel" is odd, I always think "hu, what happened? I thought it did it finish but there's cancel?". Suggestion: Rename to close, that's fine before and after the operation.
2) In search, there are three buttons "View..." (grayed out during search), "Abort" and "Cancel". I don't understand the difference between "Abort" and "Cancel" (both close the search dialog); they shall be renamed to be more descriptive. After search finished, button "Abort" disappears, which I find somehow strange and I would prefer that it continues to exist but is greyed out like "View..." during the search.

Maybe you find more.

Re: Improve wording of buttons "cancel" and "Abort"

Posted: Thu Sep 04, 2014 9:41 am
by m.Th.
Maybe you find more.
Heh! :)

Old disease.

Besides that, great program nevertheless.

Re: Improve wording of buttons "cancel" and "Abort"

Posted: Fri Sep 26, 2014 10:28 am
by fractl
I am a new fan of XnView and this is just the suggestion I was thinking of - there are quite a few dialogs that could be tweaked to make the program look even slicker.

The one I particularly notice is in the "Change timestamp". The buttons are Write (and Write All for multiple selections) and Cancel. But once the timestamp has been changed, Cancel is not going to undo this, so the button should really change to "Close". This also is a helpful indication that the required task has been completed in case you didn't notice the mouse icon change briefly while it was working!

I'd also observe the dialog shortcuts need some tidying up. In the "Edit IPTC-IIM/XMP" dialog, there are 3 controls with the Alt+C short-cut "&Caption", "&Caption Writer" and "&Cancel". Then there are 2 with Alt+S: "&Special Instructions" and "&Save". For those of us who don't want to be wedded to the mouse the whole time this is quite frustrating, and it's a fairly easy thing to clean up. Once the tidying is done, a request for a shortcut on the Back and Next buttons (< and >) would be greatly appreciated! :)

Re: Improve wording of buttons "cancel" and "Abort"

Posted: Tue Sep 30, 2014 8:41 am
by xnview
Often Windows dialog use 'Cancel' to close the dialog...

So is it ok to change 'Abort' to 'Close' in these dialogs:
- Convert
- Edit IPTC
- Change timestamp
- Search
??

Re: Improve wording of buttons "cancel" and "Abort"

Posted: Wed Oct 01, 2014 11:24 am
by HanVroon
Hi Pierre,

It is indeed more understandable to have a Close button after an operation has completed.
Cancel buttons usually close windows without making changes. In this case the change(s) already were applied.

So, if I may reply to your question with my suggestion:

Batch convert:
After the convert action is completed, change the Cancel button on the Status tab to Close.

Edit IPTC-IIM/XMP:
After Save all is clicked (and the changes are applied), change the Cancel button to Close.
(Probably leave the Cancel button as it is when only Write (single file) is clicked)

Change timestamp:
After Write all is clicked (and the changes are applied), change the Cancel button to Close.
(Probably leave the Cancel button as it is when only Write (single file) is clicked)

Search:
There is no difference between Abort and Cancel during the search operation, is there?
After click on Search in the main window, the search begins in a sub window.
There are three buttons: View, Abort, Cancel.
- I would change Cancel to Close.
- I would leave all three buttons in place all the time, so the Abort button is also there after the search is complete.
- During the search:
  • View - grayed out
    Abort - black
    Close - grayed out
- After the search is complete:
  • View - black
    Abort - grayed out
    Close - black
Kind regards,
Han

Re: Improve wording of buttons "cancel" and "Abort"

Posted: Thu Oct 02, 2014 8:17 am
by m.Th.
+1 for 'Close'.

Having two buttons like:

{Save} {Close}
{Write} {Close}
{Convert} {Close}
etc.

gives to {Close} the meaning of {Cancel} if the changes weren't applied and the meaning of {Close} if the changes were committed. Much clearer IMHO.

Re: Improve wording of buttons "cancel" and "Abort"

Posted: Thu Oct 02, 2014 2:08 pm
by B.Douille
Change timestamp:
After Write all is clicked (and the changes are applied), change the Cancel button to Close.
(Probably leave the Cancel button as it is when only Write (single file) is clicked)
Even for a single file, if "Write" was clicked it's too late to cancel anything. The Cancel button should change to "Done" or "Close", meaning the change is committed and the user can either go to next picture or stop the tool.
Search:
... I would leave all three buttons in place all the time, so the Abort button is also there after the search is complete.
If you keep a 3rd button it should be active and trigger a different action, which is not the case (so the original quest).
What would be the value of having one button greyed while the other active and vice-versa :?: The user only have 2 choices :!:

Re: Improve wording of buttons "cancel" and "Abort"

Posted: Sat Feb 25, 2017 8:49 pm
by B.Douille
It seems my last comment just stopped the discussion so we stayed where we are for more than 2 years :(
Can we have the buttons in these dialogues changed as below?

The common vision is that in all these dialogues involving batch processing, what is missing is there should be a visible change once the process is complete. The simplest way to make it obvious is to see the appearance of buttons changed during and after processing.

I made a synthesis of all comments and defined a workflow that would match the requirements. Taking "Change Timestamp" as an example:
- When you open the tool, there are 4 buttons, 3 are active (in bold here): Write, Write All, Stop, and Close. The role of these buttons is understandable.
- If the user click the button Write All all buttons becomes inactive, except the button Stop. The role of this one is understandable as well. It allows to interrupt the process where it is, could be halfway.
- Once the changes are done, all buttons reverts to original situation. The button Close can be used to close the dialogue box or the user may change the settings to restart another sequence.

In the sample above and for all batch that processes definitive changes, the label Stop is better than Cancel: Such button would never restore initial situation,
Cancel can be used for the Search tool for example as the search can be interrupted and any time during and at the end of the search, with no consequence (then, 2 buttons should be enough).

Base note: Why 4 buttons in the example "Change Timestamp" above? Ignore the specific "single Write", just focus on 3 buttons, The Write All, the Stop and the Close. Advantage is if one click on Stop at the very end of the process: With a Stop button changing to Close at the very same time it would lead to closing the dialogue, letting the user interrogative: Is it a bug closing this window or was all the changes done already? With 3 buttons this would not happen.

Re: Improve wording of buttons "cancel" and "Abort"

Posted: Sat Feb 25, 2017 9:39 pm
by helmut
Good that you restarted this discussion, B.Douille. :)

Currently, there are two discussions that deal with naming of buttons, this one here for "Change timestamp" dialog and one discussion in In topic 0.84: IPTC window: Wrong workflow with multi-selection for the "Edit IPTC/IIM data" dialog.

These dialogs have in common that they can be applied on one or multiple images that have been selected previously in browser.

Single selection / Multi selection
EDIT: I just realized that the two dialog's behaviour depends on the whether you have selected a single file or multiple files. This is a good idea and feature. Single selection is a standard scenario and buttons must follow standard which is:
[Save] [Cancel]

The discussion below is for the case when selecting multiple files.

Apply / Save / Write?
First aspect of the discussion is about the naming of the "Write" or "Save" button. I think the correct naming should be "Apply". Why? When applying a change, the change is saved and the dialog remains open and allows for making another change. This is the typical scenario for "Apply" buttons.

Sensitivity of Apply button
Typical "Apply" buttons become sensitive when the user made modified values and there is something to "Apply". So only if applying would change the file, the "Apply" button should be enabled.
For our two dialogs here this means:
- If you press "Apply", the "Apply" button gets disabled. If the user makes a change in the dialog, the "Apply" button gets sensitive, again.
- When moving to the next file, the "Apply" button should be enabled, again, because the values haven't been applied on that file, yet. When moving back, the "Apply" button should be disabled, again. This means, that XnView remembers for each file whether a change has been applied or not.
- When pressing "Apply to all files", the values are applied to all files. Then, both the "Apply" button and the "Apply to all files" button are disabled, because there is nothing to apply anymore. Only if the user makes a change in the dialog, again, both buttons get enabled, again.

All / to all / to all files
The user can apply his/her changes to one or multiple files. For this, a second Apply button is available. In the other topic we agreed that "Write all" or "Save all" respectively is a wrong and misleading labelling of the button. Current agreement was to use "... to all files".

Close or close not?
When looking at Windows standard dialogs, they typically have three buttons: [OK] [Apply] [Cancel]. Everybody knows what these buttons do:
[OK]: Save values and close
[Apply]: Save values and do not close
[Cancel]: Do not save values (again) and close

I'm not sure whether this design was chosen on purpose or not, but our two dialogs have a "Save values and do not close" but no "Save values and close". From what I can see the advantage of a "Save and do not close" button is that the user has chosen a set of files and an action (Change timestamp or Edit/Change IPTC/IIM) and by using the button he/she can set values for this action for each single file. This allows for a quick workflow, but a standard use case has come out of sight: Select one or multiple files and an action and apply values to all those files and done.

Cancel or Close?
It's difficult to say whether the button for closing the dialog should be named "Cancel" or "Close". I'd say: If the user has unsaved values, the button should be named "Cancel". Only if all changes have been saved, the button could be renamed "Close", but there's no real. And "Cancel" can be understood as canceling the current "session" of renaming.

Stop button
The "Stop" button might be a good idea and would clearly show the user that the system is actually doing something. But you can achieve this by changing mouse cursor to hourglass (wait), too. Though, I'm not sure whether the "Stop" button is really needed and helpful: If you press "Stop" XnView might stop applying your change. But then you have half of the images changed and half not. And "Stop" is for long operations, only, I'm not sure whether this applies to "Change timestamp". On the other side: Who knows how long an operation takes and the "Stop" button doesn't disturb too much. So perhaps it's not too bad but I'm still undecided.

SUMMARY (for "Change timestamp" and "Edit IPTC/IIM data" dialog)
- For single selection I suggest:
[Save] [Cancel]
or
[OK] [Cancel]

- For multi selection I currently suggest:
[Apply] [Apply to all files] [Cancel]
"Apply" and "Apply to all files" should be enabled / disabled depending on whether values can be written or not.

Does this make sense? Other opinions?

Re: Improve wording of buttons "cancel" and "Abort"

Posted: Sun Feb 26, 2017 10:59 am
by m.Th.
"Cancel" is an answer. You will see it on the buttons.

"Do you want to save the data?"

Besides "Save" you cannot have a button "Close" here but only "Cancel".

"Close" is an action done if the same state will be preserved (no changes are pending, operation is complete etc.)

The standard convention is usually Ok, Cancel : http://stackoverflow.com/questions/2065 ... ndows-form

Also see here: http://ux.stackexchange.com/a/17510/33356 for a very good answer on topic.

Re: Improve wording of buttons "cancel" and "Abort"

Posted: Sun Feb 26, 2017 1:41 pm
by Gérard 91
Hi
I have no specific opinion on the names to give to the buttons. Although the present's one are not perfect, I have no real doubt about understanding what they are expected to do.
Just a suggestion when using the IPTC / XMP tagging process on many files: it will save a little time if exist option "save all and exit" or "apply to all and output". It will just be a saved click but applied a hundred times, it is a few minits saved.
Thanks to every one! I greatly appreciate the efforts of the community to improve this powerful tool, supporting Pierre.
Gérard