Feature: Autoexpand for scraps

When I am writing something, and the mark finishes just outside the scrap I'm writing in, the scrap will gain a pimple to encompass what I just wrote.

Implementation: Collect all of the points in the last stroke, find the maximum bounds in all four points, and draw an ellipse that encompasses that region. Must be minimal, must look natural.

Electronic paper surfaces

Something odd I've just noticed, the physical consistency of my 19" AMW LCD screen is the same as paper, while my tablet PC's screen is as slick as glass. A complaint that I've heard (and share) is that tablets don't feel like paper, so it's awkward to write on them. If only there was a very thin sheet of clear paper that I could apply over the tablet PC to make it rough, I'd be much more willing to use the tablet PC for every day note use.

I've also read about the problem with consistency in several papers. I wonder what if there are any rough plastic surfaces I could attach to my tablet screen...

Question to self

Does more notes equal more creativity?
Does encouraging more sketching equate to more creativity?

Enough Free Space to Feel Creative Freedom

Just a quick thought that came to mind while reading a DENIM publication. A feeling I get when am working with a small monitor is feeling cramped. Does this space vary from person to person? Is there an optimal monitor size and resolution (x/y) that feels good?

I shove an object until it's at my peripheral, and then my main work is centered on my center of vision (fovea). Exactly how much space do I need to not feel cramped. Does the noise that exist in my peripheral vision affect my ability to give attention to the center of vision?

Note to self, update later when I have time with research on the above questions.

Update: I was reading Francois's (from Stanford) thesis, and he wrote that one group preferred not to use LiveBoard (a digital tool) because it couldn't fit all of their ideas successfully. They said a proper tool should include at least 100 different ideas.

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