Consistency in Save Confirmation Dialogs in Gnome

For slice of readership to whom this type of thing is relevant, I have compiled an overview of of the inconsistencies in file-save confirmation dialogs in Gnome. There is also a page with screenshots of the dialogs in question. I’ve posted the overview to the Gnome desktop development mailing list for discussion.

If you don’t know or care about (or any combination therein) what I’m talking about, I thank you for your patience.

 

11 thoughts on “Consistency in Save Confirmation Dialogs in Gnome

  1. I think the Gnome HIG has it right for the basic, single-file alert — for left-to-right languages, and in a right-handed world.

    I would’ve gotten to this alert by either closing a window or closing the app, and I may have done it either intentionally or by mistake. In order, my options address those circumstances nicely:

    1. “Close without saving” addresses (a) “I know what I’m doing, don’t want those changes, and want to close, maybe *because* I want to revert to the last saved version”; or (b) “I’ve lost track of where I am; reverting to the last saved version is acceptable.”

    2. “Cancel” addresses “Whoa, what’d I do? Did I hit Ctrl+X instead of Ctrl+C (or Ctrl+Z)? Did I forget to save? (Or, ‘Was there a second window open? Oops.’) In any case, can we just forget whatever I did?”

    3. “Save” addresses (a) “I know what I’m doing, want everything saved as-is, and I’m too lazy to Save-then-Exit”; (b) “Thought I’d saved everything but, if I didn’t, just go ahead and save. The current state is what I want in any case,”; or (c) [dangerous, but available] “My boss walked in (or there’s a fire alarm, etc.) and I gotta close *now*. Just do it. I’ve got bigger fish.”

    So, left to right, (1) perhaps wasteful, but safe; (2) completely safe; (3) intentional commit, hence safe.

    I’m kinda drawn to “Discard Changes” in place of “Close without saving”, but I admit that having the word “save” in the first and third options/buttons — bookending “Cancel” — sort of squares the circle and makes the options less daunting for the uninitiated. It’s better.

    For multiple open-window alerts, sign me up for the Apple HIG approach. I’ve reached these alerts through error or laziness (that is, I could’ve saved each window before closing, but chose not to), so an additional, primary dialog is the price paid by the lazy and the insurance that the mistaken need. Plus, once the user is past the primary dialog, they get the familiar single-window alert for each instance. It’d be good if each affected window were brought into focus before popping the dialog: some “documents” may be unnamed, so I’ll need to see them to make my decision.

    I hesitate to say “documents,” because it’s a bigger issue than that. Consider Synaptic (screenshot).

    You marked some packages for ‘apt-get install’, agreed to the dependencies, got distracted, returned to Synaptic and want to just umark everything and quit. Not an option. That’s a hassle, and can be dangerous. Anyhow, it’s another close-alert circumstance that calls for three options — and has nothing to do with saving files.

    Roel: I’m okay with gFTP reversing “OK” and “Cancel”, and explicitly requiring “Overwrite”, though it did take some getting used to. Safety first, I suppose — though reloading that remote resource and seeing no changes *is* perplexing at first. A bigger problem with gFTP, imo, is its inability to switch between ASCII and binary modes for batch transfers involving both. I’d thought the mode shouldn’t matter for *NIX to *NIX transfers (especially using SFTP), but it seems to.

    Lately, I keep desktop links to remote resources and do everything via drag-and-drop in Nautius — foregoing gFTP, avoiding corrupted bulk transfers, and receiving familiar Gnome alerts. “Nautilus -> File -> Connect to Server …” creates the desktop link. Just make sure to give it a reasonable name, because you can’t change the properties afterward (Nautilus 2.8.1). And, of course, be sure to choose “SSH”; “Public FTP” is the default.

    It’d be great if Nautilus had a two-paned, Commander-style view for operations like these, though. Only when I really want that do I use gFTP any more.

    LQ

  2. I’ve got to agree with Roel here: I don’t care what you label the damned buttons, just keep them in the same order!!!! The idea of HIG is that you have a *consistant* user interface, so you don’t have to stop your train of thought in order to make a decision about what to do about a dialog. If all dialogs have the buttons in the same order, you don’t even have to read the buttons, once you learn the interface.

  3. Yay! I feel good knowing that someone is taking care of this.
    Soon, I’ll be able to click though save dialogs without looking at them, something that’s cost me many dcouments in windows. 😉

  4. well done Steven!

    I belive the same report can be done for ‘confirm overwrite’ dialogs after an ‘save-as’ action. Some apps just ask wheter one wants to overwrite a file or cancel saving and some additionally include a button to return to the filechooser (choose new file name).
    I’ve noot checked what the HIG suggests, but personally like the possibillity to return to the filechooser.

  5. I enjoy reading through this informal place. I will surely visit you again to see if anything new appears on it.
    Good luck for the future.

Comments are closed.