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?

  • Option #1 doesn't seem good at all, I'd take that out of consideration. What about redo, do you plan on supporting that?
    – obelia
    Commented Nov 21, 2012 at 23:10
  • @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. Commented Nov 22, 2012 at 4:31

2 Answers 2


@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.

  • I agree, and personally have the same considerations in mind. It's really not an easy question to answer, so I wasn't sure my own decision is right. Thank you. Commented Nov 28, 2012 at 9:07

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.

  • Yes, we've thought of that (and we have a read-only history of changes already), but it seems to help a little, the main problem is still How to perform an undo while some actions can't be undone? I.e., looking at the history user will be able to see such actions, but how app should behave if user will choose to undo with some non-undoable actions in the chain? Commented Nov 22, 2012 at 11:40
  • Maybe simply perform an undo up to the last permanent / non-undoable action. The moment someone performs a permanent action, the stack items change from undoable to non-undoable, setting a new starting point for which to undo. Crude text visualisation for permanent (P) and undo-able (U) states: UUUUP -> PPPPP. Then, either decide to keep history when a user ads new undo-able states: PPPPP -> PPPPPUUU, or reset it PPPPP -> PUUU.
    – CJF
    Commented Nov 22, 2012 at 11:49
  • So, you're voting for the 2nd option? The problem here is that users will not know which action will cause the undo to stop (I mean not visually, but mentally: while doing something, you should keep in mind the order of the actions to be able to undo to the certain point in past). Commented Nov 22, 2012 at 12:02
  • 1
    In short yes. I wish I could suggest something better, but it's a difficult scenario. Maybe test it on your users. Observe their workflows. See how much overlap exists between using your plugin, and their core day-to-day actions. Based on this, decide if undo is necessary in the first place. If it is, then try to communicate as much as possible to the user (which brings me to my suggestion)
    – CJF
    Commented Nov 22, 2012 at 12:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.