Multi-step undo with some actions which could not be undone

Question

We're developing a plugin for some web-based application. Our plugin somehow enrich the functionality of the hosted application and uses some of the provided UI for certain functionality like adding new issues (the hosting application is a bug-tracking system), etc.

At the moment we're figuring out how to implement multi-step undo (redo) within our plugin (which has it's own UI embedded into hosted app's UI). Everything looks pretty good for actions which are our own (and doesn't require any hosted app UI calls), but things become unclear in situations when user performs actions based on UI provided by the outer app. Specifically, some of the actions could not be undone in this case.

We've discussed several possible solutions, but every has it's own drawbacks:

1. Simply ignore such actions (i.e. skip) and let user undo undoable actions only. This behaviour is bad because throwing out some steps silently (or even with the confirmation) will lead to the inconsistent state at the end of the undo: some things will be undone and other will not. Confirmations will help a bit (users will be aware of what's happened), but system will be at inconsistent state at the end anyway.

2. Reset the undo history at every non-undoable action (i.e. it will not be possible to undo further). The problem here is that this behaviour will confuse users too since there is no clear way to know which actions will reset the undo history.

3. Do not provide undo for all of the available actions even in our own plugin, but make it available only for really harmful actions (like bulk remove, etc), which could happen accidentally, etc. This solution will be less powerful but seems to be more clear (we'll show the message every time undo will be available and, possibly, doesn't allow multi-step undo at all).

So, how do you think, which solution are more user-friendly?

Answer 1

@obelia, yes, it seems like implementing undo only will be a wrong strategy, so it should be able to redo all the previously undone actions.

In that case I'd say keep it simple with only one (or in some cases zero) undos. Then there could be a single area that would have 1 of 3 kinds of options:

1. undo
2. redo
3. can't undo

Again, a single element, perhaps a button, would always be displaying one of the above 3 message types. If it is "can't undo..." the button would be disabled. Hopefully, users would quickly enough learn operation names and the operations that couldn't be undone and unfulfillable expectations minimized.

I think having a multi-level undo stack that could be wiped out by a single undoable action could result in frustration and anxiety, so allowing (at most) a single undo helps manage expectations.

Answer 2

This could be something completely outside of your scope, but have you considered providing the user with a visual history of the actions? Similar to Photoshop's history panel. This way, you can highlight which actions took place, and additionally start to label those that are undoable and which are not. You effectively end up visualising the undo-stack (visually mixing in the non-undo-able/permanent actions at the right places), but at least the user knows what will happen or understand why undo only works up to a point.

I'm not sure if I explained that clearly enough, but I hope it helps.