Here we are with another riddle to be solved. Undo and Redo feature , it’s everywhere , you can come across to it on any software you use on a daily basis.It has become an inevitable piece of feature on every application.
But im sure that you do experience too that sometimes it does fail to understand how much of action to undo.And sometimes you stuck at where you’ve end up after undoing and become unable to redo.
Well… I’ve been thinking about how to implement an undo & redo algorithm for a freelance project i have been working on.It’s kind of a start-up web project and will be a new thing online.Thus i wanted to make sure everything matches users expectations and works efficiently. It has a practical graphical editing interface.If you are already familiar with a couple of graphical productivity softwares.You might have already experienced the difference between them in undo&redo feature.Everyone has a unique way of its own to handle the data.So to speak every application requires a different approach on redo & undo algorithm to match its user’s expectations.
I’ve thought of 2 possible techniques and a third one which is actually a combination of those two.

History Data logged for each action:

OBJECT , ACTION , POST_DATA , PRESENT_DATA
I guess those are self-explanatory…

[kml_flashembed movie="http://mclightning.com/wp-content/uploads/2011/06/unredo.swf" width="550" height="400"]

Method A :

There is no ruling or filtering in this method whatever user does added into history log.
Cons:
Even the sequential smallest amount of movements logged.
Thus it consumes too much of memory
And User has to click over and over again to skip back while undoing.

Pros:
It is possible to undo every action as it is logged no matter how small effect it had on the design.

Method B:
Rule:
if (
last_logged_action->object==present_action->object
&&
last_logged_action->action==present_action->action
)
{
last_logged_action->present_data=present_action->present_data;
}
else
{
// Log present_action as a new record.
}

Pros:
User can directly undo just before the first of the sequential action.
So it comforts user from clicking over and over again to the undo button.

Cons:
There is no way to go back into the somewhere in the middle of the sequential action.

So… Here comes the Third Method The combination of these two methods above.

Method A+B : Convenient name huh :D ?
Rule:

sensitivity=5;
if (
last_logged_action->object==present_action->object
&&
last_logged_action->action==present_action->action
&&
last_logged_action->present_data – present_action->present_data>sensitivity
)
{
last_logged_action->present_data=present_action->present_data;
}
else
{
// Log present_action as a new record.
}

I guess you noticed that sensitivity comparing line addition to Method B.
By presetting a sensitivity value for each action type we can decide when to go with Method A or Method B.