Design idea for phones & tablet keyboards

I hate typing on touch devices.

I own an Android phone and an iPad and typing on either is not an enjoyable experience. The iPad's sheer size makes the experience a bit more tolerable, though I hate that there is no feedback when I press a key as this increases my mistake rate. The phone on the other hand does provide feedback by vibrating on keypresses (apparantly the feature's called 'haptic feedback') but due to the cramped keyboard I am forced to edit wrong characters way too often.

One common mechanism for making typing less painful is smart prediction - if the typing mechanism can detect which word I am trying to type and corrects any wrong letters, then I can still type with a decent speed. This has two major drawbacks, however: the language I am using has to be supported & properly selected and uncommon or jargon words can actually take longer to type because I have to outsmart the smart prediction - which (subjectively) seems especially dumb on the iPad.

There are various alternate typing mechanisms available for the Android devices (hooray for an open system that allows experimentation! Boo at Apple!) but so far none have met my expectations - some of them rely on various forms of word prediction and suffer the drawbacks mentioned above while others employ radical redesigns of input methods requiring me to learn new tricks and usually turning out impractical even when I do.

So I was thinking of a rather subtle enhancement to the existing most common input method. Let's assume we can define a small number of short, recognizable vibration patterns and make our mobile device emmit them. About 5 should probably be sufficient. Now let's assign them to keys on a QWERTY keyboard with haptic feedback so that no two neighbouring keys emit the same sequence (this would work equally well on a non-QWERTY keyboard and the vibration patterns could even be assigned algorithmically to support arbitrary keyboard layouts). Suppose that most people would not be bothered by the different vibration patterns and would continue using the keyboard as before. But in time, many would learn to connect specific vibration patterns to specific keys. We wouldn't expect them to know the by heart which key emmits which vibration pattern, but we would expect them to notice "Oh, that didn't feel like an R".

Now comes the only radical design change to the keyboard. We would introduce a correction key. This key would have two requirements: it should be easy to press no matter what hand position you are using and it should not be easy to press another key by mistake. This could be achieved by various means, e.g. by making the key very big or by utilizing one of the physical keys on Android devices (the Search key seems to have no typing related function and even seems a suitably named match). The function of the correction key would be the following: it would remember the last typed letter, but also the next two most likely candidates based on the position at which the finger actually touched the keyboard. When pressing it, the last typed character would be replaced with the next most likely candidate and the device would vibrate the pattern of this replacement character. So the user could think "Ok, now that DID feel like an R" and continue typing. In case that still wasn't the right key, pressing the correction button again would present the second alternative. After this, the list would start looping among the given choices (original guess - first alternative - second alternative) again in case the user accidentally overshot.

Assuming the user isn't a very sloppy typer, the second guess should be correct in large number of cases and the third guess could mop up the majority of situations. As we're not relying on the user's language or keyboard type, this mechanism could be effectively applied to most typing situations. As Android is open source I'm very tempted to find some source code for a simple keyboard and start hacking away, alas time is a commodity in very short supply for me at the moment. This blog post should help me remember my idea if I am ever left with a time surplus but is also a chance for people to give me their comments on the idea, should anyone ever happen to find it.

HTML experiments - hinting line breaks

We had an issue at work today: how do we insert line breaks into long words without introducing any extra characters? The problem at hand was that we had a few long filenames that wouldn't fit into table cells. Browsers break longs words along hyphens, but our filenames contained underscores as well which were good candidates for line breaks in our case. We didn't want to display a filename that differed to the name of the downloaded file in order to prevent user confusion.

We tried a few solutions, including inserting empty <span> elements into the file names, but this only worked in certain browsers. The solution was found in good old Unicode: it has a Zero Width Space character which was exactly what we needed (or so it seemed) - relevant documentation here. In HTML, this character is obtained by using ​. We would insert one of these after every underscore and voila, long filenames would break where necessary.

As I've hinted above, this solution didn't turn out to our satisfaction - the link's underline would hide the underscores and make the file names look, well, wierd. So in the end we used the very simple solution of substituting underscore with empty spaces. Even though the displayed file name wasn't equal to the actual name of the downloaded file, it sure looked to most users.

Because we engineers want to play with newly discovered toys, I threw together a small Javascript block of code that inserted a zero width space after every letter of text on arbitrary webpages - reading narrow randomly broken columns of text became a headache inducing exercise :)

Which Groovy version does my Grails have?

(dear reader, this list is long outdated - please go to https://objectpartners.com/2015/05/14/list-of-groovy-versions-for-each-version-of-grails/ for a list that's regularly updated!)

As this is my first blog post, hello world!

Now that the formalities have been dealt with, here's a question I've had today: what version of Groovy does my Grails installation contain? Ok, that one is easy, hardly worth blogging about, but here's the quick answer anyway: start your favorite Groovy/Grails shell (two obvious candidates are grails shell and grails console) and execute the following:

println org.codehaus.groovy.runtime.InvokerHelper.version

But unfortunately, my Groovy version did not support a feature I wanted, so the next question was, what version of Grails would I have to upgrade to in order to get my feature? After some digging on the Grails JIRA, I compiled a table of Groovy/Grails versions that hopefully will help somebody else as well.

Grails version	Groovy version
1.3.7	1.7.8
1.3.6
1.3.5	1.7.5
1.3.4	1.7.4
1.3.3
1.3.2	1.7.3
1.3.1
1.3
1.3 RC2
1.3 RC1
1.3 M1	1.7
1.2.5
1.2.4
1.2.3
1.2.2	1.6.8
1.2.1
1.2
1.2-RC2
1.2-RC1
1.2-M4	1.6.5
1.2-M3
1.2-M2	1.6.4
1.2-M1
1.1.2
1.1.1
1.1
1.1-RC2
1.1-RC1	1.6
1.1-beta3
1.1-beta2
1.1-beta1
1.0.5
1.0.4
1.0.3
1.0.2
1.0	1.5