Page History

Story

If I work on a set of items in a workspace, I can undo my last commandsactions. If I undo them, I can also redo them if I decided that they were actually working well fine for me.

If I'm unsure which command action would be undone or redone and or on what items it will would be applied, I can use a undo/redo function to show me the name of the command action and to highlight all items in the current view, which it would run on.

Description of desired behavior

Undo/redo

...

As is the case with the clipboard, undo/redo belongs to the workspace-level functions. Each workspace thus has its own command history, which records which command was executed in that particular workspace on which items and what the arguments were. Two command histories of two different workspaces are separate and not merged on a higher level.

Switching workspaces

If the user switches from one workspace to another, the command history is flushed, even though the state of the workspace as such is preserved.

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: Undo/redo is used instantly, while you work on a set of items. If you add a folder in asset management, move a couple of images into it, then realize you actually don't need it, you could call undo multiple times. On the other hand, if 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 might call undo on the "add page", but you won't switch back to asset management and call undo there to undo the "add image" - the distance between the two tasks is just too large. You rather call "delete image" than trying to figure out, what undo would do.

So the undo/redo has a similar character as the clipboard: it is a local tool and used in a limited, temporal context.

No restrictions on undo/redo

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 shownSince the command history not only contains the command that was executed, but also records the item or items it was executed on, it is always clear what has to be undone or redone. It may be, however, that the current selected view or displayed item subset can't visualize the action. If you undo an "add image" while looking at the subset of videos, the image will be removed again and you get a notification, but the view won't show the change.

Preview of undo/redo operation

If a user right clicks /taps or tap-and-holds the undo or redo function, a tooltip will name the type of function as well as the shall show the name of the command action to be undone or redone (e.g. 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 ). It will also highlight all items in the current view affected by the operation, if possible. This 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