Nautilus Undo Brainstorm

The goal of this page is to discuss some ideas about implementing an Undo/Redo feature in Nautilus.

Status update

Update Wednesday, 23 January 2008: (Amos) I just resumed my work on the undo feature. I'm currently porting my patch to gio/gvfs.

Motivation

From GNOME Human Interface Guidelines 2.0, Chapter 1. Usability Principles:

• Forgive the User

  We all make mistakes. Whether we're exploring and learning how to use the system, or we're experts who just hit the wrong key, we are only human. Your application should therefore allow users to quickly undo the results of their actions. If an action is very dangerous, and there is no way to undo the result, warn the user and ask for confirmation. Only do this in extreme cases, though; if frequently faced with such confirmation messages, users begin to ignore them, making them worse than useless.

  In all cases, the user's work is sacrosanct. Nothing your application does should lose or destroy user's work without explicit user action. Among other techniques, this can be achieved by auto-saving backups of documents, and allowing multiple levels of undo.

Unfortunately, Nautilus 2.xx doen't support any kind of undo feature.

Case study

Describe here situations where an undo/redo feature would be useful.

• Moving files.

  • Undo should offer to move them back to their original location.

  • Problems:

    • a new file might have been created in the original location, with a name identical to the old files. Nautilus should display the same dialog it would if the user tried to move the files back manually (maybe with a slightly different wording). It should offer to replace the new files, to skip the new files (in cases where there were several files moved), and to move the files back with changed names (eg, "File (old version)" or similar) if there are files with the same name in the directory.

    • when moving/copying directories one over the other, some files might be replaced (we should put them in the Trash). The undo operation should restore things in the original position, and allow renaming of files whose place was taken by newly-created files.

    • if the Trash is not available and it's needed to save old files, the user should be warned that the operation can't be undone.
    • if the original location of the files doesn't exist anymore (moved, deleted, renamed), we can offer:
      • re-create it
      • allow them to specify a new location
      • walk the undo tree and see if we can offer something else (eg, if the original location was renamed, we can offer to put the files back in the new location, or to undo the rename.) However, we always have to have another option, since the location might have disappeared from external causes.
• Deleting files to the Trash

  • Special case of Moving, should do the same thing but with changed wording.

• Copying files

  • Undo should offer to delete them (or move to Trash).

  • Problems should we have Redo to undo an Undo operation? (In this case, move it back from the trash.)

    • In cases where files would be overwritten by a copy, the old versions should be saved in the Trash. Same observation as for move if that can't be done.
• Renaming files

  • Undo should offer to rename the file(s) back.

  • Problems: If a different file with the same name appeared, Nautilus could refuse to rename it back, or, even better, should tell the user what happened, and allow them (i) replace the new file, (ii) cancel the undo or (iii) revert to the old name in the "rename mode", i.e. initiate a rename option with the old name, allowing the user to edit it. (Case (iii) is useful if the old name is long to write, and the user is interested in a small variation.)

• Changing thumbnails/icons/other appearance options. No problems here, except we might want redo too.

  • (Amos) I don't think that these operations need to be considered. If we implement a toggle-undo it will be dangerous to have them because a simple "change view" will cancel further and perhaps more important file operations.

• Ordering files. This is especially useful on the Desktop: if the user has carefully arranged their icons by hand and accidentally used an auto arranging feature (or sorting in a folder), they might want to undo it.

  • (Amos) Same as above

General ideas

• The undo menu should have the same options for all of Nautilus' windows. This way, even if a user deletes a file and closes the folder they can always undo that. But we can sort the menu differently when it makes sense, for instance putting undo operations relevant to the context at first, when it's possible.
• Special case: files in Trash should have as the topmost option "restore", even though there may be other more recent undo options.
• Other example: if I rename a folder, open delete a file, close the folder, and rena
• We can be as smart as we have time to implement with interdependent operations. For instance, when a user moves and partially overwrites a folder, deletes a file in the new folder, and renames some others, we can:
  1. (least helpful) allow undoing only the last operation (it's still better than no undo).
  2. allow undo only in the reverse direction (a: rename back, b: undelete, c: move files back and restore replaced files from the Trash if possible).
  3. we can tell that the rename and undelete are independent, and allow them both at the same time. If both are done, allow moving things back too.
  4. we can show the user the "timeline" and allow them to restore everything to directly before the move (thus undeleting, un-renaming and restoring everything). This is probably hard to do (from an UI point of view and implementation), but most useful.

Other implementations

In this section, undo/redo features of other file manager are presented and discussed.

Overview

1. No menu item, only keyboard shortcut (CTRL+Z). Info is shown on a tooltip only if an "Undo" button is added to the toolbar (ex. "Undo: Copy", "Undo: Move")
2. Each window maintains its own history. Closing a window destroys the history.
3. Window is grayed and disabled during the undo. It is possible to open another window only by launching another instance of the application.

4. The menu item shows "Undo <action>", for example "Undo Move", the statusbar shows a detail of which files are concerned (ex. Undo Move of 'myfile' and 'yourfile' and ...)

5. After an undo the action becomes in fact a redo; but there is no explicit redo

6. The menu item shows either "Undo <action> 'filename'" or "Undo <action> of N items"

One-level vs Multi-level undo

OSX Finder features a one-level (toggle) undo: only the last operation can be undone. After an "undo" the menu item changes to a "redo". Although simpler, there are situations where a "toggle" is not enough:

• copy/move operations that the user has performed in multiple steps.
  • Example: Joe is categorizing the photos he has taken with his digital camera, moving the ones he wants to keep to several other folders. After some time, Joe realizes that he made a mistake, and wants to move all files back to their original location. As the file were moved in multiple steps, a toggle-undo will not be sufficient.

On the other hand, with a toggle-undo it is possible to show a grayed-out Undo item in the menu like ("Cannot Undo ..."), with a multi-level undo this is not possible: a grayed-out item will render unaccessible all previous actions. A solution could be to have a multi-level undo and warnings shown before "undoable" operations ("The operation you are about to perform cannot be undone, and will clear the undo history. Are you sure to continue?" (Yes,No) ([] Don't show this message again)).

Copy/Move a folder over an existing one

• What happens when a folder is moved/copied over an existing one that has the same name? Example: you have a folder 'a' containing items '1', '2', '3', '4' and a folder 'b' which contains a folder 'a' with items '1', '2'. You copy or move the folder 'a' contained in 'b' in the same location as the original 'a'.

  Konqueror TODO

  Dolphin TODO

  Explorer

  • The following dialog appears:

    • 

    Clicking on "Yes" or "Yes to all" merges the contents of both folders. This action cannot be undone (this action is not "logged" by the undo at all; the undo menu is unchanged and still shows the previous operation).

  Finder

  • The following dialog appears:

    • 

    Clicking on "Replace" the whole folder is replaced (existing contents are not merged), meaning that contents of the original folder cannot be recovered. The Undo menu allows to Undo the copy/move (i.e. "Undo Copy of 'a'"): the undo action deletes the copied directory, or moves it back to its original location. A redo, redoes the copy/move.

Conclusion

Blueprint for undo in Nautilus

In this section, put the blueprint for the undo/redo implementation

References

http://bugzilla.gnome.org/show_bug.cgi?id=167501 (includes a prototype patch)

http://bugzilla.gnome.org/show_bug.cgi?id=362718

CategoryUsability