Undo Tree, Transparent Overlay

Somethings I wanted to make a quick note on.

Undo Tree
After André's talk, two fellows asked for a demonstration and gave some really good criticism on how to better improve the use of the undo list (a guy and gal whose names I can't remember for the life of me, but Alex knows them well). They mentioned that they wished their progress was represented in a tree rather than a linear list. To them it looked like it was too much information. Alex also admitted that he didn't find himself using the undo list very much either in his own usability trials, the amount of states that he could select from was overwhelming. I've toyed with the idea of representing it in a tree before to show branching, but it wasn't until the guy with the beard made the point that people don't think linearly that it really ran with me.

Here's a concept of what I'm imagining a very *crude* implementation of the tree diagram would look like real time:
This would act like a widget, however it will eventually be represented. The idea in representation is really simple, a progression in the development will follow down a path from top to bottom. Whenever the user decides to back up and try something else, a "fork" is created in the representation. The tree contains several dots, each acts like a way point that the user can click to return to a state. The way points would be recorded automatically (I'll get to how these save points are decided later in this post). Ooo, quick thought, maybe when you click the dot, a bubble appears next to it that shows a snapshot of that state, and if you click the snapshot, it restores that state.

This is a large contrast to the linear representation of the undo history right now. In personal experience, the step by step undo list is good for regressing a few specific steps, but after that (aka 10 steps), I never looked at the undo history again. Alex suggested a more trippy approach to making an undo tree: have it so when you zoom out enough, you begin to see all of the other branches and undo history. It would be exactly like the tree I drew above, except the dots would be replaced by actual snapshots of what the state looked like. This could work, but maybe if it acted like an exposé type feature. This feature would be neat, but I'm having a hard time imagining a simple way of building this.

Salvaging the Linear Undo
Now I've also gotten suggestions about the linear undo. Adding something like landmarks to different save points. You can see these in the picture to the side, the parts that are marked "Anchor" would be the landmark or anchor points. Maybe the designer can mark these points as significant and go back to them.

Another idea is having the buckets refer to a point in the undo progression. Although, this is a really bad idea on second thought because then the link would be broken when the user begins to fork an idea. A quick idea is to allow dragging from the undo list to the buckets. Hrmm...

Another problem with the linear undo list is that it has a lot of data on it that the user doesn't care about. It needs a trimming of sorts. The most recent 10 actions will be saved precisely, but everything before the 10 actions will be pruned with the following suggestions. Here's a few ideas to trim down the amount of states necessary:

• Group consecutive marks to the same object.
• Remove all entries for translating objects, unless they "snap" objects together.
• Group together consecutive thickening and thinning of relationships.

I want to mention something about transparencies, but I'm out of steam for that right now. There's quite a bit of research about transparencies and their uses, especially in the field of architecture. I think there's a few lessons we can pull from these guys, but not in the phase we're in right now.

Past Works
Enhancing data exploration with a branching history of user operations