Sliders and undoing?

Question

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.

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?

Answer 1

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

Answer 2

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.

Example.

• 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