How multitouch on the 5800 can work
This example might seem pointless because it doesn't do anything useful, but that's because the QWERTY keyboard hasn't been designed with multitouch in mind. Apps designed for multitouch would use it properly and do stuff that is useful.
The purpose of this example is just to de monstrate how the 5800 detects keypresses, so you can see how multitouch could work.
The beauty of this example is that you can try it out yourself on your own 5800. Just start an application that uses text entry and select the full screen QWERTY keyboard. Now, do the following...
Hold down Q, and the Q button lights up:
Hold down P, and the P button lights up:
Now, hold down P and Q simultaneously, and the button directly between your touches lights up (either R or T, depending on exactly how you're pressing Q and P):
All you need to do to have a simple multitouch interface on existing 5800 hardware is interpret touches exactly between two controls as simultaneous presses of both controls.
You might be thinking that this is silly because people could activate multitouch by accident if they do a single touch between two controls. However, there are ways to avoid this problem.
You could then tell the device to only record multitouch when another button is already active. This means that if someone touches the screen between two controls it won't activate multitouch by accident, because no other button was active at the time the touch happened. In theory this would prevent multitouch working with two truly simultaneous touches, but you would very very rarely put both fingers onto two parts of a screen at exactly the same time, it's far more likely that you would touch one part first and then another part. Also, application interfaces could be designed to discourage truly simultaneous touches.
You could also design apps in such a way that there's no point in touching the area between them, for example a racing game could have all the controls at the sides of the screen with the middle used for displaying the race itself.
The benefit of this technique is that it requires no extra hardware, and it could work with even the cheapest touchscreen devices, though it may require more careful planning of where on-screen controls go. This is old news really, many developers are already using this method, but most people don't seem to realise that this is possible.
This isn't as flexible as "true" multitouch, as it wouldn't be directly recording the true position of the two touches, but that probably doesn't matter much because the user wouldn't have to ever know how it works. Clever and careful design of app interfaces can make this method function in a way that is virtually indistinguishable from traditional multitouch.
The extra care needed for interface design may make life more difficult for app developers, but the much wider range of devices they could reach would provide them with far greater sales potential. Very few devices do support true multitouch, so any technique which allows multitouch on all touchscreen devices is potentially very valuable indeed. It would also make simultaneous development for multiple touch-based platforms much easier.
Nokia are already using this method in the recently-released Maemo 5 SDK using the name "two-touch", where you hold down your finger on one part of the screen while touching elsewhere in order to activate a status menu: the interface would be registering two simultaneous touches, which is multitouch (of a kind, at least). Nokia could just as easily implement this technique on future S60 touch interfaces, and app developers can already use this technique for 5800 games and applications right now if they want to.
UPDATE: AAS reader Micky! has alerted us to a video of a game that uses this technique on the 5800:
There's more though. As I indicated a few months ago, the timing of the keypresses and their 'release' could also be used. Extending the thoughts above, I can see how the user might:
- press and hold the screen at 'q'
- 0.2 secs later, press and hold the screen at 'w'
- 0.2 secs later again, release the screen at 'q'
- finally, release the screen at 'w'
There's more than enough information here for the touchscreen driver to pass on coordinates as appropriate, effectively giving multi-touch (more like 'dual touch', since handling three spots at once might get too hairy!) on a non-multi-touch, resistive virtual keyboard. In this case processing the text input "qw", even though both letters were held down at the same time for a while.
Is there a technical reason why this technique wouldn't work?