Story
If I work on a set of items in a workspace, I can undo my last actions. If I undo them, I can also redo them if I decided that they were actually working fine for me.
If I'm unsure which action would be undone or redone or on what items it would be applied, I can use a undo/redo function to show me the name of the action and to highlight all items in the current view, which it would run on.
Description of desired behavior
Undo/redo is an essential addition to Magnolia's user experience in the next major release. If a user is able to undo operations, this establishes trust in the UI and the application in general. It will also help in balancing the raise in complexity in the interface we'll face in the new version due to added functionality. If something is not entirely clear to me as a user, but I know I can try things out and undo them if they produce a result I did not attend to achieve, this profoundly changes my perception on how things work in Magnolia. Or how one reviewer put it:
Undo and redo... that's quite uncommon for a web-based CMS... but if it does what I think it does, that would make such a big change. How many times did I have to manually undo a small change I did just because I realized I applied it to the wrong page? I don't want to have to go and restore a previous version in such a trivial case.
A typical scenario for using the undo function could look like this: you add an image in asset management, then switch to your website and add a page you intend to use the image on, but then realize while filling in content that you actually won't need either. Right from where you are, you hit undo once to remove the paragraph, then to remove the page and finally the image I've just uploaded. Or you edit a paragraph on a page, then realize that the entire page needs to be reworked and quickly undo the change as you realize you need more time to think about it before even applying it on an author instance. With built-in image editing functions in asset management, undo and redo could actually even be considered an expected feature.
As is the case with the clipboard, the implementation of Undo and Redo functionality can be quite a challenge. In order to avoid a confusing user experience, an Undo/Redo framework has the following properties:
- Undo/Redo is restricted to the layer I'm currently working on and
- it offers a preview of the actions being undone or redone.
Undo/Redo is restricted to a layer
Conceptually, undo/redo uses an action history to record which actions were executed on what items and the arguments that were used. It is thus always clear what has to be undone or redone independently of where you currently are when you undo or redo an action. Why it might look at first glance that it would be desirable if there were no limits to the amount of actions that can be undone or redone from an action history, this is actually not the case.
In fact, every layer shall have and maintain its own action history. If you switch between layers, you also undo/redo actions recorded in a different action history. Layers are similar to applications and it thus would be unnatural and confusing to be able to undo a textual change applied in the page editing layer while working on the site structure in AdminCentral. Switching a layer also means switching the context you work on and thus actions executed in one context must not trickle through to a different context.
Note, however, there must be no restriction to undo and redo as long as you're only changing to a different view within the same layer. Changing to a different view does not represent a context change.
Please also note that the undo/redo function need not be present in a layer, but if it is present, every action you take is added to the action history and thus may be undone and redone at will.
Possible additional limits to undo/redo
Why it would be desirable from a usability standpoint, if I could undo and redo actions with no limits within a single layer - if you've ever used the action history in Adobe's Photoshop, you know how useful this can be -, this might actually be difficult to implement or undesirable for other reasons such as ensuring the integrity of a site.
The action history thus could be cleared whenever a safe point is reached. Possible safe points are:
- a page is activated: the action history is reset prior to activation. The next undo will undo the activation, but no further undo operation is available
- changes are confirmed by explicitly creating a new version in page editing. All actions executed prior to this cannot be undone, but all previous page versions could be used to return to previous states.
Note, however, that such safe points must be rare. A safe point is typically only reached if:
- an action is executed, which can be interpreted as confirmation of all executed actions before (e.g. create new page version)
- an action is executed, which may be regarded as end of a chain of actions (e.g. activating a page or starting a work flow)
In particular, the following actions do not represent a safe point:
- changing to a different menu item in AdminCentral (e.g. leaving website for asset management)
- leaving one layer for another one e.g. leave AdminCentral for page editing: the action history of the first layer is still preserved and shall be available again when you quit page editing.
Possible conflicts
Note that having multiple layers leads conflicts between layers. If you e.g. add a page and start editing it, but then switch back to the layer you added the page in and delete the page, the page editing layer is taken the very foundation it works on. Currently, this leads to an exception and an error message indicating that the page was probably deleted, moved or renamed. Likewise, undoing an action in one layer could lead to problems in another layer (e.g. undoing the add page in the example above would also cause problems in page editing).
Possible conflict resolutions could be:
- showing an error message in the layer that detected the problem (the solution applied today)
- locking content a layer works on and preventing deleting, moving or renaming any such locked content. A warning message would be shown instead.
Using Undo/Redo
Please consult the usage summary for a full definition of mouse, touch and keyboard usage definitions.
Providing feedback
A confirmation message is displayed if an action was undone or redone successfully, else an error message is shown.
Preview of undo/redo operation
If a user right clicks or tap-and-holds the undo or redo function, a tooltip shall show the name of the action to be undone or redone shall be shown. Examples are "Undo delete image" or "Redo paste 4 items". This feedback is essential to ensure that the user knows what he or she will cause when executing the action. Note that while such feedback could also be given on mouse hover, right clicking and tap-and-hold must be supported as well.
Optionally, this will also highlight all items in the current view affected by the operation. The effect disappears again if the mouse button is released or the tap ends.
Note that releasing the mouse button or ending the tap does not cause the undo or redo to be executed in this case - you have to click/tap the button again to get this behavior.
Storyboard
