Archive for the ‘Phones’ Category

Yesterday evening SwiftKey released a major update that adds new functionality giving more control of the keyboard layout to the user.  This functionality had been in beta for a little while which I decided not to join (the first beta run by them that I haven’t joined since the first one way back in 2010) because the new functionality is not something I would use.  I assumed that the addition of this new functionality would have no impact on my life.  I was wrong.

SwiftKey got a number of things wrong with this update because their basic assumptions were wrong.

  • They assumed that everyone changed the settings in the keyboard by using the shortcut on the keyboard and not via the app or the Android settings – wrong.
  • They assumed that everyone knew about the shortcut on the keyboard – wrong.
  • They assumed people would be OK to find that if they had modified the layout – within the constraints of what had been allowed in the previous version – that it would be OK to return some settings to default – wrong.

First of all I have never changed the layout of my keyboard since I set it up.  I have had no desire to and I can’t really understand why anyone would want to – a variable layout on a keyboard strikes me, personally, as very counter productive.  The few times I have wanted to tweak a setting (usually it’s the duration of the long press, to update the language packs, or to set up a new device) I have entered either through the app or the Android input settings – never through a keyboard shortcut that I didn’t even realize existed.  This is all from my own, personal, experience using mobile input devices including the iOS keyboard, the built in keyboards on multiple Android devices, Swype, SwiftKey and others.

SwiftKey with this one change ruined my user experience to the point where I will be looking at alternate keyboard solutions for both my devices.  And this could have been avoided simply by leaving access to the layout settings where they had been while adding access to the new feature.  It wouldn’t have required a lot more work and they would end up with fewer frustrated customers. What frustrated me even more was that I had to hunt through the FAQs on their site since this feature is not mentioned on the landing page.

SwiftKey has lost a customer who, up until now, was extremely happy and has often recommended their app.  I wouldn’t be surprised to find that I’m not the only person dissatisfied with this update who goes to look for a new solution.  And all because of a few invalid assumptions.

Advertisements

Nobody talks of “fragmentation” in the windows world. No one talks about “fragmentation” in the Mac world. Yet for some reason no one talking about mobile neglects to talk about “fragmentation” in Android.

Yes there are multiple versions of the OS out there and running on handsets, so what? There are still people – albeit a very small fraction of total users – running Windows 98 or ME. There are still people that run Tiger or Panther or even older versions of MacOS, so what? They run this because that’s what works on the hardware that they have or they need an app that won’t work on a more modern version or because they just don’t want to upgrade.

Developers programming for a desktop (and by desktop I mean, non-mobile) environment are used to dealing with multiple screen resolutions, different OS versions and all the other issues that can arise because of the choices that users make. People who develop for Linux have even more issues – there are so many variations of Linux out there that there are bound to be issues because you wrote and tested your application on Ubuntu but not on Red Hat. This is a part of the development world.

Just because Apple in its infinite wisdom has decided to create a closed system in the mobile space where only certain screen resolutions are supported and everything is very neat and tidy doesn’t mean that this is the best thing for users – or for developers. The truth of the matter is that people like being able to choose what’s best for them. The Apple system is fine – it gives a good uniform user experience and makes life a little bit easier for developers because they know exactly what they are going to be seeing on the handset. With that, it’s not right for everyone.

Android – with all of its issues – gives the user the choice of how s/he wants the phone to look and behave. The control of exactly what OS version is running. The choice of a bigger screen or a higher resolution. Yes developers have to work a little bit harder to take these things into account and yes this can lead to having an app that doesn’t work on one phone or another. Most developers, when they run into a phone specific issue go out and fix them – and usually pretty quickly.

Android is not a fragmented system. Nor is MacOS, Windows or Linux. each offers different options and capabilities to users and developers. Enough already with the F-word. Start calling it what it is – choice for developers. Choice for handset manufacturers. Most importantly, it’s choice for users.