I think Dynamo is some sort of project here at IU, which is why the name popped into my head, but for now I am just using it as a name for this page, which is about dynamic motion of interface elements. As opposed to static motion, if you can imagine that. It's where interface elements move around you to achieve certain goals:
I have a DHTML demo here, but it's not exactly complete. You can't move the cursor with Javascript, but when the page scrolls, the mouse is supposd to scroll in the opposite direction. That way the mouse stays above the data, even though the view changes.
This principle... of tying the cursor to the workspace, not the viewport allows you to essentially have an infinite workspace within a small viewport and not need things like scroll bars. When the cursor gets close to the edge of the screen, the screen pans and you see more stuff in that area. It's not a new idea, computer games have been using it for ages. But I have never seen a system where the cursor is not tied to viewport coordinates, but workspace coordinates.
Put another way, usually, when you move an inch to the right, the cursor moves an inch the the right on the screen. And when you scroll, the mouse stays in it's position on the screen. But I'm suggesting that when you scroll (which should be done for you) the mouse stay with the data that is scrolling. So if the document scrolls up, the mouse goes up with it.
And it maps well to our eyes and hands. When we move our head, our hands don't track with the view, they stay with whatever they are working with. That said, they never very far, because 1) they are attached, and 2) when we move our hands, we usually use our eyes to track our them.
The demo liked to above of course is really only appropriate for emails for two reasons: they make sense to represented as a stack, and the title of an email is a very rich, useful representation. Documents are less useful in a stack, photos are useless in a stack, and web pages are nonsense in a stack.
That said, a similar idea could be exended to a two dimensional field of icons, which covers more area. I don't have time to create a demo, but if you imagine icons like so:
[0] [1] [2] [3] [4] [5] [6] [7] [8] [x] [x] [x] [x] [x] [x] [x]
When you mouse over [0], you would get a zoomed in version, and things would re-arrange like so:
[-------------- -full size pic- -----img0------ --------------] o o o o [1] [2] [3] [4] [5] [6] [7] [8] [x] [x] [x] [x] [x] [x] [x]
The little o's represent buttons for rotating, etc. So when you mouse down over the [1], you would get:
[0] [-------------- -full size pic- -----img1------ --------------] o o o o [2] [3] [4] [5] [6] [7] [8] [x] [x] [x] [x] [x] [x] [x]
And your cursor would stay in the same relative position, which is over img1, in its lower left hand corner. This means you can just mouse down again and you'll get 2, 3, etc... Just like in the demo above. Small mouse movements allow you to scroll through the entire set without losing your view of the entire set, and without moving you far from the image itself and the tools for manipulating it.
Of course, this idea is definately not tried, so who knows it it's true. I need to mock it up sometime. A variation which might be better for selecting long range targets would be to not change the layout of rows, so instead of what you see above, you'd get:
[0] [-------------- -full size pic- -----img1------ --------------] o o o o [2] [3] [4] [5] [6] [7] [8] [x] [x] [x] [x] [x] [x] [x]
Which maintains the original rows. I would still slide the subsequent slides over to the left margin though, as that allows moving through the set with linear mouse movements, instead of an awkward zig zag.
One thing to note about the 1d demo I mention above, is that moving up is kind of better than moving down, because the currently "selected" page doesn't move. The page you have just discarded just moves out of the way. This means you can start reading as the other page is scrolling away, so you can pretty easily read through the first few lines of several pages in one smooth motion. Coming the other direction, you have to wait for the new page to slide up, and then orient your eyes, which all takes time. It wouldn't be hard to switch this so that it was more convenient to go down (a more common activity) but I wonder if I could get it so it worked the better way in both directions.
The nice thing about the way I have it now is that titles can be right at the top of the page. If I were to reverse the behavior as I am suggesting, I would have to have titles at the bottom also/instead. You could get away from this by having pages "roll up" instead of sliding behind another page. Then you could have a sort of quantum interface thing, where you don't know if a page is rolled up or behind another page until you move in a certain direction, and observe it do one or the other.
That's scary confusing though.