Saturday, 5 July 2014

Learning Colemak step-by-step


Previously, I mentioned I'd decided to learn a modern, optimized keyboard layout. After much deliberation on the various options available, my chosen layout was Colemak.

There are two possible approaches I considered to learning Colemak:

1. Go cold turkey. Decide on a day to make the switch, then use Colemak exclusively. This would be the fastest method but would also be painful initially as my ability to type effectively would be gone for some time - possibly weeks - as I adapted to the new layout.

2. Piecemeal Transition. Colemak has a scheme designed to make the transition easier by changing only 3 or 4 keys at a time in a sequence of steps. This method is known as Tarmak. Although it may be a slightly slower approach, by allowing the user to adapt to relatively few key changes at a time, typing ability can be somewhat maintained during the transitional period.

I opted for the piecemeal transition approach, Tarmak.

So, I set up my keyboard for Tarmak-1, put stickers over the changed keys, and went to some typing test websites. First results: it was a painful experience - as though I'd forgotten how to type, even though only 4 keys had changed. Making even a modest change to the keyboard after so many years experience with Qwerty was surprisingly unsettling.

Tarmak-1 moves the all-important E, and also N, into optimal positions.

This initial period was the most difficult, and often frustrating. Typing required constant vigilance for any of the changed keys, which in this first phase, includes the very common letters E and N. As one of only two keys to switch hands, E is particularly difficult to re-adjust to.

But I continued on and it soon began to click. While I would still make frequent mistakes, there would also be moments that hinted at what was being gained. For example, both "ne" and "en" are very common letter pairs in English, and so some early satisfaction was gained when I was able to type these efficiently in their new positions on the home row.

After about a week, I moved on to Tarmak-2. At this point the three most common letters in English (E, T, A) are right under the fingers. I found this second step to be much easier, and adapted especially quickly to the new T position. It certainly seems easier to adapt to changes when they remain on the same finger.

Tarmak-2 makes the second most common letter, T, much easier to reach.

I think that Tarmak-2 is worthy of consideration as a layout on its own right. With relatively few changes, it already fixes the majority of Qwerty's flaws. For those thinking about changing layouts but are concerned that full Colemak is too radical a change, you could do worse than try Tarmak-2, and then decide later whether or not to continue to full Colemak.

Personally though, using an established layout that enjoys good support was a key part of my decision, so once again after a week or so, I continued to the next step...

Tarmak-3 moves R to the home row, but S also moves one space to the right.

Tarmak-3 moves R and S to their Colemak positions. I had the most misgivings about this step as I consider S to be one of the few keys that Qwerty actually positions well. And as expected, this change gave me problems, often hitting R whether I meant S. If I could change one thing about Colemak, it would be to leave S in the Qwerty position - the difference in typing efficiency is extremely minor but it would make Colemak easier to learn!

After a week with Tarmak-3, I was by now impatient to complete my Colemak journey, so I decided to skip Tarmak-4 and go straight to full Colemak. That meant a lot of keys changing at once, notably the I and O keys into position in the home row. Being a major change, again my typing suffered for several days. But on the upside: I had made it, after nearly a month spent transitioning, I was now a Colemak user and there was no going back, so I could now focus my attention on improving my typing knowing that all keys were in their final positions!

Tarmak steps 4 and 5 combined, resulting in the full Colemak layout!

I'll post an update on my thoughts on Colemak and the whole switching process once I have fully adapted to my new layout. I wonder how long that will take...


Sunday, 15 June 2014

Alternative keyboard layouts

It's well-known that the ubiquitous QWERTY keyboard is not a particularly efficient layout. It's one of those cases where a standard gets adopted in the early days of a new invention - the typewriter - and as people become familiar with the standard, the motivation for reform falls away.

QWERTY: no-one likes it; it doesn't care.

I have at times in the past thought about this issue and wondered whether it would be worthwhile to learn a different, better-designed keyboard layout. For a software developer, the keyboard is a critical tool, but the QWERTY keyboard often feels like it's working against you. There is large amount of finger movement required due to commonly used keys being harder-to-reach, while uncommon keys, such as J, K, F, and semicolon, are in the easiest to type, "home" positions.

However I had always rejected the idea of switching, on account of the drawbacks being to great.

Reasons to switch layouts Reasons to stick with QWERTY
1. More comfortable typing experience.
2. Reduced risk of common typing ailments, e.g. RSI.
3. Improved typing speed.
1. Existing typing ability on QWERTY adequate.
2. Learning a new system could be time-consuming and difficult.
3. QWERTY keyboards so dominate that it might be difficult to avoid them entirely.

For me, reason #3 was the killer issue for sticking with QWERTY. I was concerned I would need to continue use QWERTY, and trying to maintain the ability to type in two different layouts was out of the question.

But recently in weighing up these factors, the balance has started to shift. What about the drawbacks that prevented me taking action before? Well, they have become less significant. Pretty much all my typing these days is done on my own computers, so the need to sometimes revert back to QWERTY is eliminated. Also, should I need it, there is software available which lets you temporarily change layouts that can be run from a USB memory stick without the need to install anything.

Although some report faster typing speeds after transitioning to a new layout, for me speed is of secondary importance - I am more interested in potential gains of comfort and usability. If I am going to spend so many hours at the keyboard, I want to take whatever steps I can to make the experience as pleasant as possible. And while the learning curve is still an issue, there are layouts out there that make for a (relatively) easier transition from QWERTY, and my thinking now is that the long term gains would be worth the short term pain.

So, I did some research on some optimized modern layouts. Some, like Dvorak, are well-known alternatives but are an extremely radical departure from QWERTY, and hence harder to learn. Others, like Minimak offer an an easier learning curve at the expense of being less optimized. I also liked the approach of the Norman layout with its emphasis on ease of learning while being an fairly well optimized modern layout. There is some good analysis of various layouts at the Carpalx website.

In the end I decided to that the layout I would switch to was... Colemak. This is a modern, well-optimized layout which also retains several keys in their QWERTY positions. In particular, most of the bottom row is unchanged, meaning common shortcuts for copy, cut, paste, etc, remain in familiar positions. There is also a learning method available (called Tarmak) which switches a few keys at a time to make the transition easier.

Colemak: Better typing since 2006

My decision to choose Colemak over the other easier-to-learn layouts like Minimak and Norman was that Colemak is moderately well-known(*) and well-supported. It's comes built-in on my Android phone and I believe it's available in Mac OS X as well. It also has a small but growing active user community.

So, be it wise, brave, or simply crazy, my transition to Colemak has begun! More on my progress to come...

(*) Insofar as any non-QWERTY layout can be described as "well-known".

Saturday, 13 July 2013

Building Android projects with Gradle

I notice there is a lot of interest at the moment in the new Android Studio development environment, launched at the recent Google IO event. I have often found Eclipse to be often slow and lacking in robustness, so an alternative IDE being supported for Android development is welcome news. Upon reading about the changes in more detail, another significant piece of news is the new build system for Android projects, based around Gradle. So, I decided to take a look at Gradle in more detail.

Here are some intended benefits for the use of Gradle for Android projects:
- the use of the same build system whether in the IDE or the command line
- the benefits of improved dependency management
- easier integration into automated build systems

There is an additional advantage thanks to the new packaging format for Android libraries, the "aar" format. Previously, android libraries have usually been imported into the IDE so that their resources could be compiled into the app. But now Android libraries can be included much more easily, in the same way that "jar" files have been included in Java projects for years. This particular feature is long overdue but very welcome indeed.

Here is a gradle build script from one of my projects.
buildscript { //define the path to some pre-existing JAR libraries //required by the project LIBS_DIR = "../../../libs" //the android plugin for gradle should be obtained from the maven central repository repositories { mavenCentral() } dependencies { classpath 'com.android.tools.build:gradle:0.4.2' } } //declare the project is an android build apply plugin: 'android' dependencies { //also use the local maven repository to //look for dependencies repositories { mavenLocal() } //these are some jar files that are required by the app compile files("${LIBS_DIR}/hiscore/hiscore.jar") compile files("${LIBS_DIR}/GoogleAnalytics/libGoogleAnalytics.jar") //this is an android library (using the "aar") format which I have put in my local maven repository compile ('com.mopub.mobileads:mopub-android-sdk:unknown') } //the project definitions for the android build android { compileSdkVersion 15 buildToolsVersion "17.0.0" //The source paths below are not the new recommended project structure //I am still using the default Eclipse-like structure sourceSets { main { manifest.srcFile 'AndroidManifest.xml' java.srcDirs = ['src'] resources.srcDirs = ['src'] aidl.srcDirs = ['src'] renderscript.srcDirs = ['src'] res.srcDirs = ['res'] assets.srcDirs = ['assets'] } instrumentTest.setRoot('tests') } //declare the details for creating a signed release version signingConfigs { release { storeFile file("../keys/android.keystore") storePassword "######" keyAlias "######" keyPassword "######" } } //declare the release build should run proguard and perform signing buildTypes { release { runProguard true proguardFile getDefaultProguardFile('proguard-android.txt') proguardFile 'proguard.cfg' signingConfig signingConfigs.release } } }
Build the app from the command line can be done by running one of these commands:
gradle assembleDebug #for debug build gradle assembleRelease #for release build
I have previously used Maven for some projects, and found it very useful for managing project configuration, especially dependencies. But I also found it lacked flexibility for those cases where you need to customize your build for a special case. While in theory you could write your own Maven plugin, in practise most users won't do this and instead rely only on existing well-supported plugins. I often found myself using Ant rather than Maven, because it provides increased flexibility where you need to do some specific operation in a project, such as copy or modify a source file in some way.

Gradle appears to offer the best of both worlds: comprehensive support for a wide variety of common use cases via plugins, the same dependency support as Maven, but also the flexibility to allow custom modifications to your build script to suit whatever is the need.

I am convinced the Gradle is the way to go for Android builds. There are plenty of other cool features too, such as build "flavors", that I haven't even mentioned. I think this adoption of Gradle by Google is a hugely important step forward for Android. Now, I just need to convert over all my other projects to use Gradle too...