BruTile @ the Surface

Once we got the basics running I tried to edit the XAML to make it look better. This turned out to be harder than expected. The surface has once again its own default designs, which in my opinion are worse than the WPF standard designs. The default look is grey and square. So I wanted to change it to something more akin to our other touchtable applications: white and round. However Paul used a ScatterView component to display the layerlist and the geodan logo. He had read that one can just drop components in a ScatterView, without the need to embed them in ScatterViewItems. This is true, but it is a nightmare for the (non-initiated) designer. What happens is that the grey-square design of the ScatterViewItem is drawn beneath any layout you come up with for your own item. This is a very puzzling behaviour, although not entirely unexpected once you know that the ScatterViewItem exists.

Once I solved this issue I could seriously try to change the layout of the ScatterViewItems. Here however real glitches appeared. We use rounded borders and dropshadows for our items. As you can see below there are (at least) two issues:

Rounded border on the Surface don't work

The dark rectangle in the top of the image is actually a shadow of  a ScatterViewItem which for some reason doesn’t start below it. However this makes it easy to see the first glitch in the rendering. As you can see there is a thin dark line near the edge, which makes a weird square corner at the corner. This shouldn’t be there and when you resize the ScatterViewItem down, the shadow becomes darker (as it should have been in the first place) and the line is not visible anymore. If you don’t use rounded corners on the shadow the line is still there, but harder to notice because it is exactly following the edge of the shadow.

The second annoying glitch I’ve found is the gap between the border and the content. If we zoom in a bit on the layercontrol you can see there is a pixel space between the border and the content:

A gap between border and content

So far I haven’t been able to eliminate the pixel wide gap. It doesn’t look bad in our application right now, but in general it is bad that there is such an uncontrollable gap. So I have the feeling that the Surface people are not a big fan of borders in general and rounded border specifically.

We spend quite some time calibrating, recalibrating and reading documentation from the invite only Microsoft site without any effect. In the end Vista asked us to install an update and to reboot the Surface. When it was rebooted we ran the ‘Surface Shell’ application from the Desktop and suddenly it worked!!

The Surface, or at least our version, comes with a set of code examples. We tried several to see how well it works and found out that especially the Grand Piano demo is a crowd drawer (mainly due to the sound probably). The Piano is a limited set of piano keys in perspective view. ‘Pressing’ a key results in a tone, just like a real piano

Playing piano on a Surface

The sensitivity of the Surface is well balanced. The Surface doesn’t notice fingers which are hovering just above the surface and you don’t need to apply any pressure to get noticed once you touch it. We’ve built our own table using a similar FTIR technique and we had quite some problems getting that balance right. Also the Surface is using 5 camera’s where we used just one as such it’s resolution is better as well.

It has additional logic in the interpretation of the camera feeds. It has three different types of touches it can recognize: finger, blob and tag. From each type it gives a location, an orientation, an id and in case of the tags a value.

Surface information of a finger

The difference between a blob and a finger is the size and shape of the touch, for instance a small square object is seen as a blob and a larger oval object is seen as a finger. Furthermore the earlier white-only bias of the Surface we experienced is now changed to a no-black bias. This gives some interesting results; a black/orange marker on the surface is recognized as a single finger at the tip of the marker;

Fingers come in strange shapes

The Surface feels pretty responsive, but using the Data Visualizer you notice that the position of the touch as interpreted by the Surface lags behind the actual touch. In the demos it is not noticeable but we found a similar lag very annoying on the DiamondTouch. On that table we managed to get rid of the lag and hopefully we can do the same here.

There is the famous demo of the telephone on the Surface, where it gets recognised and you can drag and drop data. We tried it and noticed that it doesn’t like android phones; it just doesn’t see the phone. An (ancient) windows mobile phone however does get recognised for what it is: a blob;

Android on the Surface

Obviously the Surface doesn’t automagically recognize phones or any other object. The table comes with a set of fiducials which you can stick on objects. These fiducials get recognised as tags with a value and using that value you can do fun stuff in your software.

Update

I discovered that while it doesn’t respond to hovering fingers, it does notice hovering areas the size of a hand. Which is slightly annoying since in normal use you easily have your hand hovering just above the surface while one or more fingers touch it. It might be possible to filter this unwanted behavior in real applications, because the hand shows up as a blob instead of a finger.