Congratulations to the organizers!

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.

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.

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.

What was particular this time was that I trained… almost not at all. All my training this year was one 10km run and one 9km run (the reason being that the weather was rather cold this spring, while I enjoy running above 10 Celsius; not to exclude pure laziness though).

Given my lack of training, I was afraid I won’t be able to even finish it — it’d be enough to run a bit too fast in the beginning, and I’d be dead at 15km. But everything went well, I could maintain an even rhythm all along, running with about 10km/h without any breaks. I didn’t notice the two hours going by, it seemed as if it were a mere 15minutes. And the weather was great.

Some time ago I was wondering how this ‘mobile browsing’ experience can be improved, and at that point I was thinking that server-side page adaptation is the answer. In this approach, the web application generating the pages uses techniques such as User-Agent sniffing to detect that the client is a mobile phone, and returns a page specially-tailored for a mobile browser.

But now I realize that this approach is fundamentally flawed. It puts the burden on the web application developer to generate two parallel sets of outputs (one for desktop, one for mobile), and the hard part is keeping these two in sync. The problem is that the mobile version will get behind the desktop version, and the mobile user may be put in the paradoxical situation of wanting to browse the desktop version rather than the mobile version.

And the technology advances: my old mobile phone had a 128×128 screen, but now 240×320 is the norm for feature-phones (a feature-phone is the phone that is not as smart as a smart-phone). And the IPhone has a large QVGA screen (320×480). Such devices come closer and closer to displaying normal web pages, so the content-adaptation becomes less critical.

The solution that I see now is different: forget content-adaptation — instead design a single set of content, but take into consideration that a (growing) percentage of the users will be browsing from a mobile phone. So: keep the pages clean and streamlined, favour text instead of large graphics (text scales better), and keep the page size small.

Because the data connection on a mobile phone is slow, and often costs by amount of data transferred (not flat fee as on the desktop), it is important to keep the (total) page size small. This will greatly improve the browsing experience on the mobile phone.

In history there was a moment when most users were connected to the internet through a modem, with a maximum speed of about 5 KBytes/s. At that point, there was a lot of advice on the web on the lines of: keep the size of your web page under 10 KBytes — it would take so and so many seconds to download a web page of that size over the modem, etc.

I think it would be a good mind-set for present day web developers if they imagined that 20% of their users… are connected to the internet through modems again. So, forget the 1MByte (including images, ajax libraries, etc) web page, cause it takes 200 seconds to download it over the modem.

It’s true though, this new modem is getting faster…

Disclaimer: This blog expresses solely my own personal opinion — it is not endorsed by and does not represent the opinion of my employer.

So, everybody knows already that I am the author of the Arity Arithmetic Engine, a nice little open-source library for evaluating arithmetic expressions. In this library I put quite some attention on the elegant and minimal code, and on performance. The functionality is mainly split in two parts: compiling an expression (takes a string and returns a Function object), and evaluating the Function.

For example, compiling the string “g(x)=x^2″ produces a Function instance. Calling eval(5) on this function returns 25. These two operations (compilation and evaluation) are separated because you typically compile an expression once, but evaluate it many times (for example when plotting the graph of a function).

On a desktop computer, Arity can do about 50,000 compilations/second, and about 1,000,000 evaluations/second. So the compilation is about 20 times slower than the evaluation.

Why is the compilation so slow? well, you may be surprised, but the bottleneck during compilation is the parsing of a double value from a string (using the java.lang.Double.parseDouble(String)).
And Double.parseDouble() is not only slow, it also does quite some memory allocations (which again result in slowness when the GC is invoked to collect that memory).

One key advantage of the Arity library is that it compiles not only on JavaSE (desktop Java), but also on JavaME/MIDP (mobile Java). So last weekend I decided to measure its performance on my mobile phone (a modest Nokia 6300). I wrote a tiny midlet for the benchmark, and the result is:

On the mobile phone, Arity does about 500 compilations/second, and about 10,000 evaluations/second. So the 20 times factor between compilation and evaluation speed is the same as on desktop.

And the key information, the mobile phone is about 100 times slower than the desktop computer (from Arity’s point of view).

Still, 10,000 evaluations/second on the mobile phone is not bad, I am quite happy with this performance.

PS: go check out Arity: http://arity.googlecode.com/

I’ve taken out the arithmetic engine from Javia Calculator, re-written it, cleaned-up the API, packaged and released it under Apache 2.0 (open source):

Arity, the Arithmetic Engine for Java. Enjoy!

It works for both JavaME (MIDP) and normal Java (SE). I’m rather happy with the API and the code, it turned out elegant, compact and (as usual) very efficient. Hope you like it..

JSON, the “JavaScript Object Notation”, is a very simple notation for representing hierarchical data. It achieves what XML was supposed to do, and in a very simple way.

While the XML spec is hundreds (thousands?) of pages, the JSON spec fits comfortably on one page. Although the name suggest an association to JavaScript, JSON is in fact language-agnostic. There are JSON libraries for almost any language out there.

Sample JSON fragment:

{
"name":"John",
"tel":["+16051231234", "+48885003300"],
"address":{"street":"Dyamond 8", "city":"San Francisco"}
}

JSON has elementary values (strings, numbers; e.g. “foo”, 10), arrays marked by square brackets (e.g. [2, 4, 8]), and maps (also named ‘objects’) which contain key:value pairs between curly brackets (e.g. {”name”:”John”, “age”:”10″}).

Because of its simple and uniform structure, JSON is very simple to parse (this is a major advantage over XML). JSON is more compact then XML. JSON is more ‘pure’, more elegant than XML. And because of its ability of representing arbitrary complex hierarchical structures, JSON is just as powerful as XML.

While XML had all the hype, JSON is quietly getting the job done.

Follow-up: quite funny, only one day after I wrote this article, there was a similarly-themed post on CEO’s blog: JSON for data exchange (vs. XML).