The Nokia 5800 already supports multitouch, sort of...

There is a demo video on Youtube from a hobby develper who has compiled an application that allows multi-touch on the 5800. I will see if I can find the link.

EDIT. Here you go..

http://www.youtube.com/watch?v=XndW7YlvYjU

this is just a property of the resistive touch screen. You can get the same effect on other touch screen phones, I just tried it on my sony ericsson G700 and the same thing happens (using the virtual keyboard, or using a scribble app). The operating system will only see it as one touch though, it isnt seeing two touches and merging them.

The operating system will only see it as one touch though, it isnt seeing two touches and merging them.

The phone IS seeing two touches and it IS merging them. It doesn't matter if it's happening at a hardware or OS level, the point is that it happens and it can be used to allow multiple keypresses. I've explained how it would work in the article, apps would just have to interpret single touches between two controls as multiple touches of both controls (in this case R/T could be interpreted as Q and P being pressed simultaneously). Accidental multitouches could be prevented by only allowing multitouch directly after a button has already been pressed (as multitouches usually involve one finger arriving at the screen first), and app interfaces could be designed to discourage touching the screen between two controls.

If I hold down the Q and P buttons on the 5800's keyboard, the OS registers it as R or T, even though I haven't touched R or T. The two touches are being merged into one which is exactly between them. I could alter the keyboard app to interpret R/T as Q and P being pressed simultaneously, and from a user point of view that would effectively be multitouch. Obviously that would be useless in the context of a keyboard because you wouldn't want to enter two letters simultaneously anyway, but in other applications this could be quite useful.

If I let go of Q without letting go of P, the phone goes back to registering P because that's still being held down. And if I press Q again while holding down P, it goes back to registering R or T. It all happens instantly, there's no delay or uncertainty.

Yes this is a property of resistive screens, and that's exactly why this has such great potential because it would potentially allow simultaneous keypresses on cheaper touchscreen devices.

I mean it isnt the OS that is merging them, it is the touch screen. The OS has no idea if you pressed R/T or the Q and P simultaneously - it just sees a touch midway between them. I totally understand you can make multi touch like games in this way, but you could have done this years ago on earlier touch screen phones too 😊

The problem with this way of doing things is that pressing top left and bottom right will effectively touch the middle of the screen, and pressing top right and bottom left also effectively touches the middle of the screen. So I guess its fine for having a button layout like in that youtube video, but its quite limited (good start though 😃)

I mean it isnt the OS that is merging them, it is the touch screen. The OS has no idea if you pressed R/T or the Q and P simultaneously - it just sees a touch midway between them. I totally understand you can make multi touch like games in this way, but you could have done this years ago on earlier touch screen phones too

I agree this isn't an OS feature, I agree this isn't new news (I said so in the article), but there are still respectable journalists and tech-savvy nerds saying that detecting multiple keypresses is impossible on resistive screens, which just isn't true. The example above shows you can detect it, as long as the app is designed carefully to avoid false positives.

The reason I'm posting this as a news item is that Nokia just released the beta SDK for Maemo 5, and it uses the above method to detect multiple touches in its own interface. If that's happening on Maemo, there's a good chance Nokia will use it on S60 too.

Users don't care if multiple keypresses are detected through the OS or the hardware, all they care about is whether they can press two buttons at once, which they can on the 5800 (and all other touchscreen devices) if the app is designed carefully.

Micky, thanks for the link, I've embedded the video in the article.

Oh, yeah. This sounds like Jack putting on bras and saying, look I'm Jill, sure I am.. Lame.

I'm not sure if this is available across all resistive touchscreens, but I've seen a Windows Mobile emulator that takes advantage of this functionality to provide a usable touchscreen only joypad, which certainly works on the HTC Touch HD / Blackstone, so don't give up on "classic style" gaming on the 5800 either!

Oh, yeah. This sounds like Jack putting on bras and saying, look I'm Jill, sure I am.. Lame.

No, it's more like travelling by bus instead of by limousine. It's less flexible, but it's a lot cheaper and within the reach of everyone's budget.

Watch the video, it works. The game responds to multiple simultaneous keypresses. That's multitouch.

It's not exactly the same kind of multitouch as the iPhone's, and it might not be as easy to program or as flexible in design terms, but it works.

I wonder what Apple's multitouch patent actually covers? If it was purely the concept of responding to multiple presses then the patent is worthless, because it seems programmers have been doing this on resistive screens for years.

It's actual practical use is limited to a certain style of UI... No doubt you will get phone manufactures saying their device supports "multi touch" when it truly doesn't.

No doubt you will get phone manufactures saying their device supports "multi touch" when it truly doesn't.

If a phone can detect multiple simultaneous touches, that is multitouch. It doesn't matter HOW it does it, all that matters is that it DOES do it.

It might not be as good as the iPhone's, but it's a heck of a lot cheaper to manufacture.

Saying only the iPhone counts as a multitouch device is like saying only plasma screens count as television sets.

If you call this multi touch then UIQ3 had it before s60 you can do the same thing on some of the pop-up menus in the UIQ3. you move the pop-up menu with one finger then if you touch somewhere else with another finger the menu stays at the center and you can even play with it by pressing a finger harder.

Paker, if this is common to all resisitive screens then some devices have had this ability before Symbian even existed. 😊

OK but UIQ had it before s60 😃

I'm not sure about all the Apple patents, but I'm pretty sure that they have patents on some of the actual gestures (e.g. "pinch" to zoom in/out).

I'm hoping that some of those gestures were already used on the big screen in Minority Report, but I guess that most of those gestures were 2 handed, similar to the demos of Microsoft Surface.

This is no use.
The phone can only register the single touch location. So if you touch both p and a and get g, the phone only knows g. The phone can't disciminate between a single touch of g and two touches on p and a. Therefore the phone and any software on the phone cannot do anything useful with this. Same goes for individual points, the phone only sees a single touch regardless of how it is achieved.

This is no use. The phone can't disciminate between a single touch of g and two touches on p and a.

If you actually read the article you're commenting on, you'll see that you CAN discriminate between a single touch and two touches by detecting if a first button was pressed immediately before the second one.

If you have a genuine single touch, no other part of the screen would have been selected when the single touch happens, and the phone could assume it was a single touch.

If you have a genuine double touch, then some other part of the screen would already have been selected before the second touch, and the phone could assume it was a double touch, and then it could work out which on-screen controls it could have come from.

And even if that didn't work, you could still use this method for multitouch because you could design an application where there is no reason to touch the screen between two buttons (which, again, is something I talked about in the article). If you don't have to touch the screen between the controls in an app, then it doesn't matter if the app can distinguish multitouches or not. For example, if you put the controls of a driving game at the sides, and there were no controls at all in the middle, then the phone could correctly assume that any touches in the middle must be double-touches of controls at the sides.

Therefore the phone and any software on the phone cannot do anything useful with this.

Yes it can, just watch the video if you want proof, and read the article to find out how the game in the video works.

Same goes for individual points, the phone only sees a single touch regardless of how it is achieved.

The phone sees a touch in a particular context, and it's that context that allows software to distinguish between a single touch in one place and double touches elsewhere.

@Unregistered: You're wrong. And it's because you're missing the timing elements. Every press down onto the touchscreen, or up off it again is registered in an event loop along with the exact time. It's then easy for the OS to work out (from the start coords of the first 'down' to the end coords of the second 'up'😉 which positions were pressed and in what order.

I know the above isn't quite what Tzer2 meant, but hey, it's what *I* mean!

@Steve, @Unregistered, @Tzer
Yes, the user presses Q and P at 0.2s delay.
OS receives:
* User pressed screen at Q coordinates
* after 0.2 s, user pressed screen at T coordinates (where in reality user pressed at P coordinates)

From this, the application is unsure if it was a second touch on T or if it was a multitouch on Q and P. How can the application distinguish this? Not enough information.

you'd have to look at the window server events to be sure, but you might be able to work it out because there wasn't any non-touch period i.e. no finger up on Q. Admittedly when it doesn't work out correctly it would be very frustrating for the user - it's already hard to figure out user input from a noisy touch input.

I guess someone needs to play with it and see how it feels. Multitouch would be nice on qwerty though, one of the things that makes it feel a bit weird is having to type discreet keypresses all the time.

Yes, the user presses Q and P at 0.2s delay.
OS receives:
* User pressed screen at Q coordinates
* after 0.2 s, user pressed screen at T coordinates (where in reality user pressed at P coordinates)

From this, the application is unsure if it was a second touch on T or if it was a multitouch on Q and P. How can the application distinguish this?

First of all, I think Steve is talking about something slightly different to the main article. I don't want to comment on Steve's method because I don't know anything about it.

Going by what is in the main article (which I wrote) it is possible to distinguish between multitouch at sides and single touch in middle:

1. User presses Q and keeps it pressed down.

2. User presses P while Q is still pressed down (which phone interprets as T).

3. Phone sees that it has a T pressed down, and checks to see if any other key was being pressed just before the T.

3. There was zero delay between another key and the T being pressed, so the phone now knows that it isn't really single T but actually a multitouch involving two different keys either side of T.

4. Because the last button before T pressed was Q, the phone can assume that one of the pairs in the multitouch is a Q

5. For a multitouch with Q to produce T, the other multitouch key would have to be P, because T is halfway between them.

6. The phone now knows that it is receiving a multitouch with Q and P being pressed simultaneously.

Whether this would work reliably on the QWERTY keyboard is unclear, because QWERTY has lots of controls which are all very small and very close together, so there might be frequent mistakes with neighbouring letters mistaken for each other. For multitouch by this method to be reliable, the controls would have to be bigger and spaced apart more so that the phone can be surer about which pair of controls produce which central touch.

But that is all irrelevant because this article isn't about doing multitouch on QWERTY. I mentioned the QWERTY example purely because it allows the user to see how the 5800 interprets multiple touches, people can try it out for themselves using their own 5800. (To be honest I'm not particularly bothered whether QWERTY gets multitouch, I think it's more important to see predictive text added to the 5800's QWERTY.)

To get back on topic, the article is about how multitouch could be done in apps that are designed to use it.

As I said in the article, even if distinction between single and multitouch was impossible, it doesn't matter because if an application has an interface designed for this kind of multitouch, the application doesn't have to distinguish anything.

For example, if an app interface has all its controls at the sides of the screen, the user will never touch the middle of the screen, so the application will never have to make any distinctions. All touches detected in the middle will be multitouch of the controls at the edges, because there are no controls in the middle.

And even if the user does touch the middle of the screen, the method detailed at the beginning of this reply can be used to distinguish between genuine single touches and genuine double touches.

The programmer of the game seems to have done pretty much what this article was talking about, by placing the touch controls at the edges of the screen.

You might say side screen controls are useless, but they're not, in fact side screen controls are extremely common, and they're very suitable for a device like the 5800 where the horizontal mode is designed to be used with two thumbs, while the vertical mode is only designed for use with one thumb (so no multitouch is needed).

Portable games consoles for example usually have controls on both sides of the screen, so doing virtual versions of these controls would work well with games. All kinds of other apps could use side controls too, such as media players etc.

Because the 5800 is designed to be used with two thumbs in horizontal mode, side controls would suit its ergonomics too. (One of the best media players on Nokia's internet tablets is called Canola, and it uses controls along the two edges not for multitouch purposes but purely to make it easier to use with thumbs.)

Hmm.... even Tzer2 doesn't seem to have grasped my idea/point. My concept works because the OS also knows when a point on the touchscreen is **released**

In other words, it could get the initial letter from the initial contact and the second letter from the second release. Other info in between is just irrelevant.

Steve
PS. Maybe I should just patent the thing and then make a million pounds!

Unfortunately i doubt very much this finding will have a future. Look at HTC Diamond or Touch pro - there are almost true multitouch sensor areas under the screen which are proved to work (videos on youtube or just download developers tools and see yourself). But zero applications were developed, in spite of existing SDK and popularity of platform and devices. Very sad.

hey it's really cool demo! yes, Nokia 5800 has so cool stuffs!
www.check2cash.co.uk

zooming wont work as the fingers go apart their intermediate distance is still the same point so the device cant recognize changing in position of two fingers on a line moving with same distance!!!
right???

There ir real to implement multitouch zoom on singletouch devices. If resistive screen takes middle point of two touches, that means that if we can trace one touch-down and if delay between next touch is shorter then specified value (must be lower then user-like touch)- is multitouch event. Movings of second point are show half-radius or circle with center in first point.

Unregistered wrote:zooming wont work as the fingers go apart their intermediate distance is still the same point so the device cant recognize changing in position of two fingers on a line moving with same distance!!!
right???

Technically you could zoom in and out - so long as one finger remains stationary you can track the motion as you move the other closer or further.

the game on the iphone that has the go and stop and the analog direction controls could in theory work anyway... as when you press on a single location it shows that location and when you use the joystick it can tell where the joystick should go even if it is representing a single touch as it picks up the user has pressed the "go" button and there was no delay between moving the joystick control, as when you press Q on the keyboard and move your other finger around it switches between all the numbers between so this theory could be used to make any game with 2 controls... i think it is possible to make a good multi touch game from this idea