Colin's Journal: A place for thoughts about politics, software, and daily life.
I’ve recently acquired a blackberry playbook by porting ExpenseClam to this platform. The physical format of a 7 inch tablet seems to work very well. It is still small enough that carrying the device around is very easy, and holding it in one hand is entirely comfortable. Meanwhile the screen is just large enough that websites can be viewed in their desktop format, without having to zoom in and scroll.
That’s the good news. The bad news is that the quality of available apps is very low. Most of the big name apps are missing (e.g. no Skype). There are many ported Android apps, but these work only partially. Native Android features are missing and they have a tenancy to hang.
Native apps that I have found suffer from a clunky keyboard implementation, and flaky UI widgets. The Web browser is reasonable, but occasionally suffers from unresponsive UI elements.
My overall impression is that the tablet would be far more useful and interesting if it was running Android ice cream sandwich. This leaves me wondering whether I want to get either a 10 inch tablet our something around the 7 inch mark.
To sum up: when writing this post, I started on the tablet, but the application hung, and I ended up retyping it on my phone. It is hard to see the playbook platform being a success given it’s current state.
For an app that only recently moved into the 100-500 downloads range, the paid version of ExpenseClam is doing remarkably well. As of writing this, ExpenseClam is number 65 on the list of top grossing apps in the Business category on the Android market.
Looking at the next lower ranked app however I think this is down to how the market treats apps that change categories. Number 66 is an app called SMS super faker, which appears to have always cost the same as ExpenseClam, but is in the 1,000-5,000 download range. According to AppBrain it switched from the Communication to the Business category on the 23rd of December 2010, 6 days before reaching the 1,000 downloads mark. The only explanation I can think of for having a lower gross revenue than ExpenseClam is that it has had far fewer downloads in its new category than previously.
Similarly number 70 (calendar scroll widget agenda) also has far more downloads than ExpenseClam, but has recently changed category.
The lesson to learn from this appears to be that changing category within the market is penalised, at least as far as the top grossing lists are concerned. Whether this impacts app exposure is another matter. How many apps are purchased as a result of browsing the lower echelons of the top grossing list, versus searching and picking from the featured and staff choices lists is unknown.
I’m struggling to decide on whether a NetBook or a tablet would be better suited for me. The tablet would be an Android one, probably the new transformer prime from Asus. It would allow me to test tablet specific designs for ExpenseClam and would provide a more convenient form factor for web browsing than my phone. The transformer also has a keyboard attachment, so writing blog posts and even some web site design should be easy.
A NetBook on the other hand would allow me to do Android development while travelling, and even at home on the sofa, rather than isolating myself away in the study.
In theory I could use VNC, or some other remote desktop software to control my desktop from a tablet, but in practise I expect this to be clunky at best. I could get both a tablet and a NetBook, however I know that when travelling I would only want to carry one, not two machines with me.
At the moment I’m leaning towards the tablet. While ExpenseClam works fine on tablets, it uses the same layout as for phones. I should be able to design a layout that really takes advantage of the extra screen space available on tablets. It also feels like a more modern investment than what is essentially a small laptop.
This post is a bit of an experiment as it had all been written on my phone using the latest WordPress app. Overall not a bad experience, mainly thanks to the Swype keyboard.
The Android Market continues to struggle in providing a great end user experience. To illustrate, here’s what I went through when purchasing Carcassonne tonight:
It’s fairly amazing that my own app (ExpenseClam) receives any purchases at all given the difficulty involved!
I should add that it was worth persevering – the game is rather good!
Yesterday I released ExpeneseClam, a business expenses tracking app for Android. Recording expenses on a smartphone can be a painful experience, typos are common, expense claims are not always made in chronological order, and there is usually little time to note down how much a taxi cost. ExpenseClam has a number of features to help make this easier. Simple things like auto-suggesting expense descriptions based on the amount entered can make it much quicker to record common recurring expenses.
One of the niftiest features in ExpenseClam is something that you will only stumble across if you travel a lot: it auto selects the default currency for a new expense based on the country you are in. This is done without needing user permission to determine location, carry out reverse geocoding or even internet access.
The secret sauce is Android’s TelephonyManager and it’s method getNetworkCountryIso(). This method returns the ISO code given by the mobile operator for the network that you are connected to (the Mobile Country Code). From this a Locale object can be created, which then allows the Currency instance to be created. None of this requires network traffic and it takes very little processing power to complete.
Changes in the default currency only happens when the country changes. This is to avoid frustrating users who have to enter expenses in a different currency to this default. The country derived currency is however prioritised in the list of currencies to make selection easier for what is likely to be a common choice.
Does the “Android Monopoly” really provide a challenge to the traditional OEMs? Is the answer to use virtualisation on the handset and put Android in a virtual machine sandbox while the OEM’s own O/S runs underneath it? That’s Andreas Constantinou’s proposal in his latest blog post at VisionMobile. I’m not so sure. Firstly let’s take a brief look at the history of the OEMs he identifies as losing out due to the success of Android: Motorola and Sony Ericsson.
Motorola’s success story pre-Android was the Razr. This was a huge phone in 2005 and dragged Motorola into second place behind Nokia. The success of the Razr had little to do with the software that it ran, and a lot to do with the very distinctive and stylish design. Motorola failed to innovate effectively off the back of this however, resulting in a whole series of similar phones and declining market share. It is only with their adoption of Android that Motorola has been able to rescue themselves from terminal decline in the mobile market. The Droid series of phones built for Verizon have been very successful for them, bringing the company (now split off as Motorola Mobility) back from the brink.
Sony Ericsson’s history contains more highlights than Motorola’s, but is also a mixed record. They have used a number of operating systems over the years, with Symbian (using the UIQ interface) and Windows Mobile both playing a part. Sony Ericsson has been able to differentiate with their Walkman and Cyber-shot brands, both of which relied more on innovation in hardware than software. Sony Ericsson have produced a range of Android smart phones, which has done much to restore their financial health (to the tune of €1.1bn).
Hardware has always been a major differentiator between mobile OEMs, marking a significant difference between the mobile and personal computing industry. This traditional strength is not undermined by Google being the driving force behind Android. OEMs adopting Android get for free the things they have traditionally struggled with: a best-in-class smart phone O/S, app store and cloud services. This allows them to focus on the part of the equation where they have seen past successes and that aligns to their core competencies.
The announcements coming out of Mobile World Congress this year (and CES before it) shows that there is plenty of room for innovation in hardware and software:
If Google is restricting what OEMs can do on the hardware and software front, I don’t see much evidence of it in the products that they are announcing, or an opportunity to do more by using virtualisation.
Two weeks ago I published my first application to the Android Market. LibraryThingScanner is an extremely simple application that speeds up adding books to LibraryThing. The app launches the Barcode Scanner application to scan the ISBN, followed by the web browser to bring up the relevant LibraryThing search page. The app does so little I’ve been in two minds as to whether it was worth publishing at all, especially as the LibraryThing website does not work particularly well on an Android phone (for example continuously popping up the virtual keyboard).
Once I’d coughed up the required $25 for the privilege of publishing to the market I found the process very straight forward. There are certainly some quirks, such as being able to upload two screen shots or no screen shots, but the level of information required was very low. It’s peculiar that I find uploading my software to the internet at large, with a potential audience of nearly two billion people, a minor step, whereas publishing onto the market felt like a more significant thing, despite the comparatively small potential audience of a few million.
I’m glad that I did take the plunge. There was an initial spike in downloads as soon as I published the application, reaching 126 downloads and 97 active installs in a matter of a few hours. Since then things have levelled off and the application is averaging 17 new active installs per day out of 35 new downloads. I don’t know how accurate the statistics are for Android market application installs, but they are much more useful than any number of downloads for other software I’ve published online.
Seeing the number of active installs slowly creeping up, seeing the ratings (very slowly) coming in and now receiving my first comment (thankfully positive) makes the feedback loop from users much more satisfying than the very occasional email I receive regarding my other software. It’ll be interesting to see how things carry on longer term and what kind of reaction anything else I may publish receives.
There have been a lot of articles recently accusing Google of dropping the ball with Android by creating “fragmentation” within the Android platform. This references either the number of base O/S versions (currently three versions make up 99.5% of active Android phones) or the fact that HTC, Motorola, Sony and others often put some of their own software on top of Android.
This trend of complaining about fragmentation has now extended as far as complaining about the iPhone OS (recently re-branded as iOS). This new complaint is that Apple has also somehow fragmented their platform by introducing new devices with different hardware capabilities, in particular screen resolutions and densities (think iPad versus iPhone 4).
While it makes developer’s lives easier to have a single hardware platform to target, it’s also something that we are not used to. From the earliest days of home computers there has been a huge variety of hardware and software to contend with. Today’s desktop landscape is no different – developers need to decide which basic platform (Windows, MacOS, Linux) and what versions (Windows XP, Vista, 7?) of those platforms they are willing to support.
The development of larger and higher resolution screens isn’t fragmentation – it’s progress. The Android platform provides a set of easy to use mechanisms that mostly make the extra size and screen density transparent to the developer. Similarly the SDK makes it easy to know when you are using a feature that does not exist on earlier versions of the platform. You can then either make it optional, or if you truly need such a feature, drop support for older phones and be glad that Google’s rapid pace of development makes your application possible at all.
When considering the mobile application environment today I think there are far more pressing issues than additional phone screen sizes to be concerned about. The 30% cut that Apple and Google take from every application sold, Apple’s active censorship of artists and arbitrary banning of applications are far bigger and more pressing issues.
In some respects I’m rather late to the Android / smart phone game. Many of my colleagues carry an iPhone, with a small (but growing) number carrying an Android phone some sort. After the first few weeks of using the HTC desire I can now say that I would struggle to go back to a normal phone.
The killer app for me is not the broad selection of applications, many of which fail to live up to their initial promise, but rather those few applications that keep me in better touch with the world. From news applications for the New York Times, Evening Standard and Guardian through Facebook, Twitter and email it’s much easier to keep up with the world as well as friends. When sharing a photo with the world is two taps away the barrier to doing so is hugely reduced in comparison to the desktop experience of going home, plugging in the camera, finding the right photo and finally uploading it.
The software on the desire has a few glitches on occasion, but for such a young platform with such grand ambitions, it is very usable and achieves a great deal. For example the automatic synchronisation of phone numbers from Facebook into the phone provides a huge amount of value. The amount of alternative software available for core functionality is less surprising than how well it integrates with the overall platform. It’s only rarely (and usually from HTC’s customization) that new software fails to fully integrate with existing apps.
In summary I’m extremely pleased to have caught up with the world and joined the throngs of start phone toting individuals.
Tim Bray’s assertion that IT professionals are implementing Enterprise Systems wrongly is a fairly seductive argument at first. The one sentence summary of his argument is:
The community of developers whose work you see on the Web, who probably don’t know what ADO or UML or JPA even stand for, deploy better systems at less cost in less time at lower risk than we see in the Enterprise.
He goes on to list companies such as Facebook, Google, Twitter, etc as examples of doing it the right way.
I don’t agree with his analysis. As commenters to the post were quick to point out, comparing a list of failed enterprise projects (including ones such as the NHS National Programme for IT that stretches beyond software solutions) to those few internet firms that have thrived is not instructive. For every Twitter (rumoured to be barely making a profit) there are hundreds of failed internet start-ups. IT department do not have the luxury to fail projects as frequently as start-ups fold. While governance of enterprise projects is often slow and cumbersome, it’s designed to improve the odds of success above this base level.
The assertion that UML and other enterprise IT tools and techniques are not used by internet firms is unsubstantiated. A quick search reveals that Google, Amazon and eBay have the enterprise role of “architect” among their job descriptions. I suspect all of the mature internet firms have similar roles, and use many of the same enterprise techniques as more traditional institutions.
As Erik Engbrecht points out, comparing the legacy-system ridden architecture of a typical enterprise to the “internet app is our company” environment of Twitter is also not useful. In many cases the quick dirty approach used to develop internet applications is the technique that creates the spaghetti architecture found within many enterprises.
There are undoubtedly lessons from internet companies that could be learnt by enterprise system professionals. Many of the technologies used in the enterprise are overly complex in comparison to internet based solutions. For example the poor use of SOA while integrating systems brings additional cost with limited benefits. However such learning is not a revolution, and will not reduce the complexity of implementing enterprise systems substantially.
Email: colin at owlfish.com