Swype vs. Swiftkey - Clash of the Betas

One of the positive aspects of owning an Android phone is the ability to replace the keyboard with third party keyboards that believe they can do better than the original.  Back when I used Windows Mobile and Sony's Clie running Palm OS, I enjoyed FITALY, which was a stylus-based keyboard which obliterated the QWERTY standard for speed typing.

But now we are in the touch-era, and even hardware slide-out keyboards are struggling to remain relevant against an onslaught of soft keyboards.

For your typical Android device this means you can use Google's keyboard, you can use it's voice-to-text abilities, or you can use one of the many keyboards available from Android Market.   Two of the ones that are getting the most press these days are Swype and Swiftkey.  Both claim to be the fastest way to enter text on your keyboard.  I've been using both to see which 'sticks'.  Here's my analysis of the strengths and weaknesses of the two products.

Let's look at Swype first.  The principle is simple.  You just drag your finger from letter to letter, and each time you lift, Swype guesses what word you were 'typing', puts it in, and adds a space.  If it is confused, it'll put up a menu and let you choose what you meant.  There are various bells and whistles and advanced techniques, but that's the gist of it.

SwiftKey is going to be the easiest to learn because it still has you tap out your letters one at a time, and it tries to figure out based upon common sentence usage and your own analyzed habits which word you MEAN to enter.  It shows you a continuously updated 'top 3' suggested words and at any point you can tap the word or the space to accept it and continue.

Both keyboards are capable of churning out text very quickly.  There is no doubt.  Swiftkey seems to want to prove it is reading your mind by guessing the next word before you've even typed a letter.  It's as if the little thing just wants to prove it knows you better than you know yourself.

Swype, on the other hand, says, "Look, I don't care you can't draw worth a lick and you just took a detour into two letters that aren't anywhere close to being in this word, I'm smart enough to know what word you MEANT" to type, and I'll put it in.

Again, both keyboards do a commendable job.  But unfortunately, there are some issues I take with both keyboards.

The big problems with these keyboards have to do with their inability to deal gracefully with very essential C's" of touch screen text entry:  Composition, Correction and Context.

Let's first examine composition Many words that are common are made less 'common' by changing their form.  For instance, the word "demanded" is composed of "demand" + "ed".  In the case of SwiftKey, typically you will type in the word letter by letter until you see "demanded" in the window.  But you may not.  You may just get "demand".  In many cases the two best guesses at other tenses are available in the touch buttons next to the 'primary' word, but sometimes it isn't there.  In this case, you are forced to type the entire word out.  You have saved nothing here.  In fact, it may take you more time because you are busy staring at the word hoping the tense you want pops up before you finish typing it.   Some words are long, and have many possible endings, and you are frustrated because the root is right here in front of you but you still have to type it all out. An example of a painful word might be "understanding".  If you don't see "understanding", the word "understand" might be right there.  But you won't get your "ing" version until you eliminate the 'Under', maybe 'understood', and other variations.  By the time you get to "ing" you've already put in so many letters, you just want to forget the whole thing.  Swiftkey doesn't have any way I can see of doing 'composition' E.g. accepting the base form, and selecting a from popular endings.  If I could type "unders" and see "understand", pick it, and then see "ing" and "s" or even "ability" as possible endings to "understand", I could tack the ending I want onto the word and be done with it.  So, when SwiftKey is on its game you can type incredibly fast. But for long word composition, it fails to do anything but slow you down and provide false hope.

For quick text messages and notes, however, the good outweighs the bad.  You might type "I am stopping at the store to buy some soda".  Let's see how many letter keys I need to enter it:  20.  There are 34 non-space letters.  It actually assumed I wanted to start my sentence with "I" and "am" was one of the three options immediately shown after I picked "I".  The word 'stopping' had to be typed in all the way to the "i", even though "sto" found "stopped" and "still" as well as the "sto" in case I wanted to indicate "sto" was really a word.

Where Swype is concerned composition can also be a problem, but since you're swiping the entire word in one single stroke, it is simply a matter of continuing through all the letters.  In those cases where SwiftKey correctly guesses your word after just a couple of keys, it can indeed beat Swype.  You type in a couple of letters, it guesses your word, you press space, and you're done, whereas you might still be drawing out your word in Swype.

Both keyboards struggle with added punctuation, though.  For instance, if I want to type "I went to pick up Michelle's dry-cleaning", I can get through the first several words pretty quickly with SwiftKey, barely typing a couple of letters per word.  I start with "Michelle" and get as far as the "h" before SwiftKey suggests "Michelle" as a word.  Problem is, I want "Michelle's".  Do I keep typing, and add the apostrophe myself?  Or do I complete "Michelle" in one keystroke and then deal with correcting.  I choose the latter.  SwiftKey puts in "Michelle" and a space. I have to now Backspace, then hold down the key with an apostrophe, which brings up a row of alternates, one of which the apostrophe, then pick it, then type "s".  This seriously slows me down.  I don't like backing up to type.  Ever.

How does Swype do with the same sentence? Not so great, either.  If you want a double character you need to 'loop' or 'squiggle back and forth' on the letter (this is lousy - SlideMe and ShapeWriter work in much the same way and were better about figuring this out).  I capitalize the way Swype tells me.  Start with the "M" and drag up above the keyboard, then back down to type "ichelle".  Then I utilize the Swype trick of dragging down to the key that is the period and apostrophe key, then back up to s.  This is supposed to tell Swype I want "'s" at the end.  Unfortunately, Swype puts in "Michels" for me.  I try it again, more slowly, and still get "Michels".  I'm not happy.  My speed is gone, and the word is wrong.  I will try it again:   This time I'm careful to loop de loop the 'l' to get two of them, and just lift after "Michelle".  Swype gets it right.  Now I drag from the period/apostrophe key to the "s" key and voila :  "Michelle's."  Only took 3 tries.

So in terms of composition, both Swype and SwiftKey blow it.  Swype just flat out blows it sometimes, whereas SwiftKey requires some painful backing up, holding down, etc. 

Another weakness of Swype is the fact that you don't know what you're going to get until you're done Swype'ing.  You cannot stop halfway through and see how you're doing.  And this hurts in shorter words.  Swype is aware of it.  They talk about the "pit/put/pot" problem.  The QWERTY layout causes this to be basically a straight line from the 'p' to the 't'.  Swype doesn't know which you mean.  You can 'hop' the letters a bit by making a sort of skipping Swype to each letter and that helps Swype know which you mean.  But some shorter words are notoriously frustrating.  "to" is almost always put in as "too" (in spite of the fact that it seems to stubbornly insist on two squiggled L's in "Michelle".  "If" and "Of" are similarly messed up.  Being able to see what you're doing as you go gives SwiftKey an edge here.  The shorter the words, the more trouble Swype is in.  They could have adopted an approach like the FITALY product had done and made a new keyboard layout which pretty much eliminated ambiguity on shorter words, but they must have felt like QWERTY was the way to go because people would know it, so you get the short term of win of ease of learning at the expense of longer term accuracy.  An option would be nice, though.

Next, Context.  What does the keyboard do in reaction to being activated for different kinds of fields.  Not all Android text fields are the same.  Some are user names, some are passwords, some are URL's, some are search fields, and of course, some are just plain text.  Swype wins here because it really doesn't care what kind of field you're in.  The text entry is the same.  SwiftKey is narrowly focused on things like email composition fields.  If you go to the Android Market and try to type in a search term, you won't get any suggestions.  You're just effectively using the stock keyboard for all the help you get.  Same is true for other kinds of fields, like search fields for the web browser.  I believe SwiftKey will improve this, but right now, it's like you have no alternate keyboard at all.

So, the shorter and more predictable the word, the more the game tilts towards SwiftKey, and the longer the word, the more Swype pulls ahead.

Neither product is particularly strong where compound words exist.  Let's say I wanted to type "ratrace".  I guess neither product will get the word right, so I will try entering "rat", not putting in a space, and then entering "race".  Both products effectively force me to back up after inserting the space (of course, I could turn off auto spacing, and lose way more than I gain in the grand scheme of things).  Swype will allow me to hold down on the space key FOREVER to temporarily turn off spacing.  In the time it takes me to hold the key down and turn off the 'spacing', I could have just backspaced and typed.

Finally neither product contains a microphone button for speech to text.  This is annoying if you occassionally want to use the Android 2.1+ feature of "Speech to text" in any field.  Since you can't activate the microphone, you are forced to Long Press | Input Method | and select the default Android keyboard to get to the microphone.  Hardly convenient.

The bottom line for me at this point is that I prefer Swype.  I am still using SwiftKey heavily, though, to see whether its 'learning' capabilities alleviate some of the pain of it constantly correcting me incorrectly, or forcing me to type in too many keys for longer words.  At this point I can hold my phone in one hand and thumb in a swyped sentence incredibly sloppily and still see it do a darn good job of guessing what words I meant to type.  SwiftKey guesses words, but requires a bit more care.

I'll write another blog post after more time spent with both, but right now, SwiftKey shows a lot of promise, but Swype still seems to have sweated some of the details out that SwiftKey has not.