Alina’s blog

As the capabilities of mobile devices are getting closer and closer to that of portable computers, the only thing limiting their use as such is their size. It is simply impossible to replicate the possibilities of good sized QWERTY keyboard for data entry in a small mobile device.

Various workarounds has been thought up to deal with that. And one of the more interesting and promising is virtual keyboards or even virtual input displays, projected on the working surface. There is already a number of such virtual keyboard devices on the market and Samsung has a patent pending for use of projected virtual display in a phone.

But Nokia now has an even better idea described in a patent application called “Mobile device with virtual keyboard”.

Why do we need additional projectors at all? Most of the mobile phones already come equipped with optical sensors and cameras. Let’s use them to give us virtual keyboards:

The digital camera on the phone is used to capture the movement and position of user fingers, and project them on a virtual keyboard shown on the phone display, in real time.

The phone is also equipped with the sensors to capture the sound or vibrations, generated as the user taps on the working surface (e.g. desk or table) and convert them into an input commands.

The phone itself can come with a cradle to hold it in upright position while user is typing on a table. But that is not necessary. The user can just be holding the phone in one hand and typing with another. And if no working surface is available, the user can just imitate the tapping sound with his voice.

I use a first-generation MOTO RAZR as my mobile reference. It has an awful UI, and can't accept big content. I make sure that the site is usable on the RAZR, which is quite a challenge.

One big deal is the amount of data you transmit. Some people think that it's OK to transmit 100KB of page data, then hide 75KB with a media="handheld" CSS file. The problem is that the phone receives all that data, and the user has to pay for it in both time and money.

I've designed my mobile interface to present the site in very simple, hierarchical contexts. Each context can be navigated in small, easily-digested pages. Large pages are broken into a series of pages, so the user only receives (and pays for) the data in which they have an immediate interest.

I've found that the iPhone users actually prefer the full site, even though it is slow, so I present iPhones with the full XHTML, even though they are mobiles. I still need to test for Touch iPods.