96. search+rescue use: search teams use google earth type application on a multi-touch device to map their search plans, send teams out, etc.
(sorry for multiple posts)

97. UML

98. Storyboarding

99 mashup editor (music and video)

can we keep going? If so…

100. Using real-world tools in digital applications. For example, if the fidelity was high enough, an artist could use real-world brushes to paint on a digital canvas, and the different shapes/sizes/textures of brushes would give different results on screen,as they would in real-life.

101 ‘spatial control’ of audio effects processing, a subset of the audio mixer mentioned before, specifically allowing reorienting the pan & depth location of multiple signal sources in stereo or surround mixing or reverb processing for example. Felt it needed addition as the first and most obvious use in audio is creating a comfort zone of audio control in the primarily analog control world of audio professionals by providing an MT GUI of an analog console that can be manipulated with both hands like a physical one, so I assume that use to be the previously mentioned audio mixing addition.

102. Interactive Digital Signage

103: A Virtual Sound Board with plugs on the back like a real one.

Instead of focusing on the specific uses of a multi-touch table I’d like to mention some interaction models where a multi-touch table would be superior:

1. Simultaneous interaction with multiple widgets.  This is the whole point of multi-touch table isn’t it?  Applications should strive to make this their primary means of UI.  Maybe you could call this the “SWIM” principle or something.

2. Spatial organization of data.  It’s like your desktop on steroid.  With ability to zoom in and out easily, you can pile your “stuff” around if you wanted, without fear that the pile would be unmanageable.  On my actual work table I have my drives in one corner, keyboards/mice in their own area on the drawer, power cords off to one side, Computers in one corner, Ethernet cables off to one area coded by color/length, etc.  This would more or less translate readily to how people work (or how I think they work, anyway).

3. Effortless zooming / panning.  While this is nice, I believe multi-touch applications should be coded in such a way as to REDUCE the need to constantly zoom and pan ... it looks cool as heck but it gets old fast if you actually HAVE to zoom / pan to get work done.

4. Multiple participants in one context.  This is actually a very strong point of many multi-touch implementations, but we have to think about the values that can be added by having multiple participants on the same context.  Out goes today’s assumption that you have ONE person operating the WIMPy context at a time (e.g., Windows’ “Switch User” concept implies one-user-at-a-time implicitly).

5. Complimentary activity.  While you can use #4 to get a lot of work done, you might benefit more if your activities are more aligned, e.g., extreme programming, or collaborative design ... multi-touch applications should try to make this possible via quick exchanges of information.  In various demos you see online, people pass off windows to one another, in real life, this would likely involve some kind of data interchange and it’s important that such interchanges, if required, complete very quickly so as to be imperceptible or else the benefits of #4 will be lessened.

nice puddles like your ideas