Javia blog

I just participated to the first MoMo event to take place in Poland, Mobile Monday Warsaw. There were about eight presentations, of which I most enjoyed the NFC talk by Florian Resatsch from Servtag, and the MRIA (Mobile Rich Internet Application) talk by Alex Nerst of fring (both are start-up companies). The event was well organized, and represented a great opportunity to introduce a new product or make some local industry contacts. It seems MoMo will happen again in Warsaw in the coming months, and hopefully it will also get adopted in other Polish cities (like Krakow).

Congratulations to the organizers!

I describe here a simple technique that can be used by touch buttons (on a touch-screen interface) to improve, over time, the accuracy of the user touches.

Each button keeps track of the place where the user touch occurs. The touches which are close enough to the button centre are deemed sure touches, meaning that the button is pretty sure that the user wanted to touch this particular button and not a neighbouring one. For example, the button can use an embedded smaller circle or ellipse, called the sure area, and all touch that occurs within the sure area is a sure touch.

Each button averages all its sure touches that occur over time. When a certain number of such sure touches is accumulated, their average is compared with the ideal button center. If a systematic bias is detected (e.g. let’s say that the user generally touches with 3 pixels above the button center), the button records the bias and corrects it in future touches. (alternatively this can be seen as the button moving its center to the actual place where the sure touches occur in average).

The adjustment also affects the definition of future sure touches, as a touch is first corrected before being checked for happening within the sure area.

After the adjustment, the button continues to keep track of new sure touches as they occur, and to make new adjustments as needed.

This technique is most effective when every button keeps track of its own correction parameters. For example, a button which is located at the top of the screen may have a different bias (and thus need a different correction) than a button located at the bottom of the screen (or buttons located left - right may need different correction, etc).

This technique allows the interface to ‘learn’ over time the touch habits of a particular user (and to optimize itself for that user); but the interface is also able to adapt to a new user (if the device, for example, changes its owner).

For this technique to work, UI elements (such as buttons) must have access to touch events from outside their visual area on the screen. What the dynamic adaptation achieves is a separation and translation of the touch area of the button independently of its visual area.

The technique as described above supports the translation of the touch area, but can be easily extended to handle other transformations (such as dynamically growing the touch area of a button when the distribution of the touches shows too many touches close to its border, suggesting that the button is too small for the particular user).

When the touch area of buttons is segregated from their location (visual area) and is mobile (can move or grow/shrink), conflicts may appear between neighboring buttons. How to elegantly handle such ‘touch area conflicts’ is left as a thinking exercise to the reader or implementer.

While physical buttons were the standard for mobile phones in the past, it seems that the industry is gradually adopting touch-screen interfaces. The iPhone is the best example of a touch interface, but other manufacturers (e.g. Sony-Ericsson, Motorola) are also producing mobile phones with touch-screen interfaces (either exclusively touch-screen, or in addition to physical keys).

Talking about the physical keys, we can imagine that their design, shape and size was the result of elaborate ergonomic studies in order to make them as easy to use as possible (hoping that the trendy look of the device was not the only factor deciding the design of the keys).

Perhaps taking inspiration from the physical keys, the touch buttons usually have a rectangular shape (sometimes with rounded corners). But is the rectangular shape the best one? and if it is, which is the best width/height ration of the rectangle (e.g. a horizontal rectangle, a vertical one, a square, etc). Of course, the answer may depend to some degree of the particular device and the particular user, but perhaps there are also general characteristics of a good touch-screen button shape/size.

I describe below a simple experiment which allows to discover the optimal shape/size. Ask the user to touch a specific spot (’target spot’) on the screen, and record the place where the touch actually occurs. Repeat this many times. Afterwards, you can visualize the area where the actual touches occur, which likely is a shape around the target spot.

This area, the place where the actual touches occur when the user is trying to touch the target, describes the optimal shape of a touch button. It gives information about the size of the button — it should be large enough as to embed the area of the actual touches, and about its shape.

I expect that the touch area resulting from such an experiment describes an ellipse (a ‘flattened circle’). While this is not a big surprise (as it’s normal that the actual touch occur ‘around’ the target, and the ellipse is the generalization of a circle), there is valuable information in the ratio of the ellipse (how flattened it is), and in its size. While the ellipse can be covered with a rectangular button, the rectangular ratio should follow the ratio of the ellipse.

I just released version 1.3.0 of the Arity library, with a major addition: Complex Numbers. In addition to basic operators on complex numbers (like addition, multiplication, division), all the standard function are supported: trigonometric & hyperbolic, logarithm, exponential & power, factorial (Gamma), and even combinations, permutations and GCD. It is nice that many analytic functions behave better on the complex domain than on the real domain: for example, the logarithm is defined for negative arguments, asin() can take arguments greater than 1, and a negative number can be raised to any power (which results in NaN on reals).

Ever wondered how much is: e^(i*pi), log(-1), i!, i^i, sinh(i*pi)? You can download the arity-1.3.0.jar, and evaluate any expression like this:

java -jar arity-1.3.0.jar "e^(i*pi)"

An essential trait of Arity is that it works on MIDP devices (mobile phones) which have limited RAM & CPU. As such, it has a lightweight and efficient implementation. For example, the Complex class (implementing the complex operations) is done in a way that avoids new object creation, which is different from some other Complex Java libraries I’ve seen.

Enjoy!

I’ve just run my second marathon, this time in Krakow instead of Warsaw. In the 5 weeks before the marathon I have run a total of 4km, so I can say that I had zero training — I was wondering whether I’ll be able to finish the marathon at all.. and yes, I did it. I ran slowly, with a total time of 4:51 (half time 2:10). The weather was very cold, windy and rainy, I had to eat bananas all the time to keep up the body heat. It wasn’t easy, but I can say that the satisfaction of running it to the end (without training) was great.

Still, if you plan to run a marathon yourself, I recommend at least three 21km runs prior to the marathon — this can save you from a lot of pain and even injury during the real course.