I am looking to improve my open source project Retro Graphics Toolkit (for more information see https://github.com/ComputerNerd/Retro-Graphics-Toolkit ) and one feature that I plan to add is undoing/redoing. The issue is that my program makes heavy use of sliders. To illustrate this here is a screen shot of my program in action. Retro Graphics Toolkit uses lots of sliders

The reason I like sliders is the instant feedback and an easy way to communicate to the user that there is a minimum and maximum value for what they want to set for example (given that this program is for old game consoles) the Sega Genesis only supports sprites that are up to 4x4 tiles big so it is easy to limit the sprite size to 4x4. In this example (the sprite editor) as you drag the slider you can see the changes happen. Each time a slider is moved a callback function is called. I could add code to push the old value to an undo stack. The issue lies in the way people interact with sliders. Lets say the user drags the slider like this 0,1,2,3 ... until reaching their target instead of clicking on the proper place on the slider to get the right value. If I just push the change on the undo stack when undoing the changes it will be very annoying to have to undo ... 3,2,1,0 even though you just wanted 0. The best idea that I could think of (as of now) is to only push the old value to the undo stack after they use a different slider or do something else or after a timeout. I do not think this system is robust enough and I think there has got to be a better way. So with that said does anyone have a better idea on how to implement undoing for sliders? I though about having an apply button but I would find that to be very annoying. Or maybe even replace the sliders but with what?

  • Maybe just "commit" a value when the user stop dragging the cursor (mouseUp or something like that)? But it would not work if the user focus the slider uses the keyboard to change it :/
    – Leo
    Commented Jul 28, 2014 at 2:31
  • You could always try implementing a double slider, where one of the sliders is not editable but shows the last saved value. This when you can use a undo control directly where the slider control is to restore to the previous value. Not sure how it would work but worth a try?
    – Michael Lai
    Commented Jul 28, 2014 at 2:50
  • @Leo I do like the idea. I still feel that there has got be a good way to handle this but if not I will just resort to what I have described above but just for keyboards (timeout + do something else causes value to be pushed to undo stack). Commented Jul 28, 2014 at 3:08
  • Coding hint: Memento-Pattern / Command-Pattern.
    – Mirco
    Commented Jul 28, 2014 at 9:44

2 Answers 2


I don't think to many undos will be a problem.

If I nudge (pixel move) a selection in Photoshop, I would like to undo (and redo) in the same detailed level. If I have to push CTRL+Z (or Command+Z) 20 times - that's not a problem.

So. Push to undo-stack whenever:

  1. Mouse up (from the slider). The slider might have been moved a back and forth a lot with mouse down, but it's on mouse-up you push to stack.
  2. Key pressed Arrow left/Arrow right (if keyboard is supported for for incremental changes)
  3. GUI-button left/right for incremental change. I can't see this in your screen-shot, but perhaps you should add this? Moving the slider for quick change, and buttons for fine change is quite normal. Just like scrollbars.
  4. Move out of an edit field
  • Well it does appear as though that system is as good as it is going to get. Currently there are no small buttons to do incremental changes but if the buttons really do prove to add to the user experience I could add them however I think they are made redundant because keyboard editing is supported utilizing arrow keys for the smallest increment. I can see the justification for saving every keyboard change are you are trying to make precise edits. For moving out of edit fields that will cause duplicate data as both mouseup and arrow keys would already have that covered. Commented Jul 28, 2014 at 13:38
  • Ah. I thought you could alter the values directly in the edit fields. Commented Jul 28, 2014 at 13:43
  • For some reason I though by edit fields you meant the sliders as in when the user clicked away from a slider onto a different one it would cause a push to the undo buffer. Do you mean the numbers by the sliders? Those are not currently editable. I have though about adding a feature to be able to type in those. Commented Jul 28, 2014 at 13:45
  • Yes. I was thinking of the numbers to the left of the sliders. I thought that you could enter these and type directly. If these are mere labels - no worries ;-) Commented Jul 28, 2014 at 13:49

I think you need to make a reasonable compromise between the amount of control the user has to undo every step they make with the burden of saving every small change as a new step in the history. By saving every change to a single slider as an undo step could clog up your history stack. What if you have to put a cap on the history states in order to save on memory usage for example, if the user makes 100 changes to a slider before editing any other control then 100 steps in the history are wasted on all of these steps.

As a user I would also be annoyed by having to traverse every single change I made to a single slider before I used a different control. I would prefer to revert to the initial value it was at before I made my edits. I would sacrifice this control for convenience of being able to undo more quickly.

Also you want to avoid unnecessary confusion for the user. For example with a timeout, sometimes the users action will be saved as an undo action in the history but sometimes not (depending on whether timeout was hit or not). This may cause uncertainty with the user on whether what they have done can be undone or not.

I would go for saving the entire change to a single slider as 1 step in the history. Once the user makes a change other than on that slider, then a new step in the history is created.


  • User edits Slider A from 0 - 1 - 2 - 3 - 2 - 3 - 2 - 1 - 0 - 1
  • User edits Slider B from 5 - 6 - 7
  • User clicks undo, Slider B goes back to 5
  • User clicks undo Slider A goes back to 0
  • Yes I agree not using a timeout system is a good idea. I will scrape that idea. I think only pushing the old data to an undo stack upon a mouseup or keyboard even should eliminate most redundancy. Also I will have a history window that will allow the user go back to n times at once and even go back without applying some changes ahead of time provided that there is no conflict such as the user wanted to undo only a pixel edit even though that tile is now gone. They would have to undo the tile delete before they could undo the pixel edit. Commented Jul 28, 2014 at 13:42

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.