Interesting data from Flurry (a smartphone usage statistics service) suggests that eBooks were 10% of what is in the iPhone app store back in July 2009, but had reached 20% by October 2009. Over the same period, the proportion of games declined slightly (17% in July 13% in October) . The data are published in the October 2009 article of Flurry's "Smartphone Industry Pulse" series
These data don't tell us about whether the books are being downloaded, nor whether they are being purchased (as opposed to being free downloads). Also, of course, there are many other places you can get books for your iphone (e.g. by using the free Stanza Reader). Nonetheless, asFlurry say "We take the spike in demand we noted from an earlier analysis, combined
with the flood of supply into the market as an early indicator that
iPhone as an eReader is real. "
I have recently been moving my timesheets and to-do lists to my iPhone. The iPhone apps I tried for this initially seemed to have poor usability, simply because they required me to do important things in an unfamiliar way. The awkwardfulness of doing something in a new way is both an issue and a red herring in usability studies, I argue.
For a Project Manager such as me, my to-do lists, calendar and timesheets are about the most basic of tools - equivalent to the carpenters hammer, saw and plane. I need an easy and reliable way of maintaining these kinds of information, and for a decade or so, I've kept it all on paper, using a loose-leaf planner from the Franklin Covey company. Over that time, of course I've got well into a routine. The paper planner has served me well, the only problem is my planner weighs nearly 2kg and is the size of a large textbook. It's also difficult to back up, always a worry for anything containing key information. Up until recently, it had to be paper - to-dos, calendar and timesheets need frequent quick updates and I could not always rely on being at a particular PC, or on being able to get online (to use files "in the cloud"). The iPhone changes that, being a truly pocket-sized computer.
The timesheet apps I have tried are iPunchclock and Easy TimeSheet (I have also been recommended iTimesheet but haven't tried that as yet). The first thing that I found disturbing was that both apps I tried are basically stopwatches - you touch a button to say you've clocked on, and then again when you stop or pause. There are then various features with which you can note what you were doing in the interim. Some editing is possible (e.g. if you forget to click stop & find the timer has been running all night...).Then, there are features enabling you to create a spreadsheet or other report and to email or otherwise export it for further work.
When I say I found it disturbing I should emphasize that I DON'T mean that this workflow is inherently bad - the whole point of this article is that it was just not what I was used to. I found it interesting that this made such a difference. For many years I have noted my start time, noted my stop time and then made any other notes. So this is how I would have designed my own timesheet app. (I did consider running my timesheets via a spreadsheet, and then I
could have done exactly this. But so far I've found spreadsheets clumsy
on the iPhone - not so much the spreadsheet apps, but the small screen
and so the feeling of painting the hall through the letterbox.). When you think about it, clicking start and stop comes to the same thing as writing down start and stop times. But still, I found the iPhone apps clumsy and difficult to use, and would certainly have reported this if I had been taking part in a usability trial. I nearly rethought the whole idea. A few days later, I'm settling down to using this stopwatch method and don't find it difficult any more.
When I turned to to-do lists, I tried FCTasks, (sticking with the Franklin Covey company). There is a helpful demo video of the product - embedded below.
Here I was on more familiar ground, but I did find one unfamiliarity problem. A feature of the product is that tasks are prioritized A, B and C (A are things that really must be done today, B are important but not so urgent, C is less important and so on. Ranking is competitive - your A1 task is the first you turn to, then you work through the A's and onto the B's. Here my problem is that I would typically assemble my to-do list, and then add priorities first thing in the morning as I plan my day. FCTasks requires you to state a priority immediately the task is created. Which is not a problem as soon as you get used to the idea of giving it a provisional priority and tweaking it later.
An interesting feature of both awkwardful problems I found (the unfamiliarity of the stopwatch; the need to assign a priority to tasks immediately) is that for all that the problems turned out to be very simple-sounding, it took me considerable thought to unpick what exactly I was finding difficult.
So, in both cases, I experienced problems of "awkwardfulness" (and awkwardful word that I like because it is so...awkward, and which I think I got from Douglas Hofstadter. If I recall, it turns up in Hofstadter's book Gödel, Escher, Bach: An Eternal Golden Braid ). Awkwardful problems are ones that provide a user with a temporary, personal usability problem based on the application not working in the way to which the user is accustomed (the application has to work in a way that does make sense to many users, or it is merely poor design). For a non-software example of awkwardfulness, consider the difficult initial days of attending a new job (or a new school) - suddenly all kinds of things that were easy to do in familiar surroundings are hard. You are forever having to ask "where is the photocopier?" "How do I book a meeting room?" or the equivalent.
Awkwardful usability problems seem significant for a while but would rapidly be overcome with persistence and familiarity with the application. The problem is that a lot of users just aren't going to persist, blaming the application for not being very usable.
I have just come across research from Greystripe about how parents let their kids use the parental iPhone. Parental iPhones are key for developers of
apps for younger children, who are unlikely to have their own machine. (The typical iPod touch user is a teenager or young man, and the typical iPhone owner is a middle-aged man, according to demographics I reported in an earlier post .)
The research "How Moms use their iPhones" Includes a survey of how the kids use Mum's phone (or "Mom's" since this is US data). 59% of Moms let the kids use their phone. Of these, 41% had bought games for the kids, and 20% had bought educational content. As regards age of the children, 29% of the moms had children between 0 and 4, while 43% had children between 15 and 17. The survey also covered the role of iPhones in shopping (use of the phone to make or email shopping lists, or to locate stores or compare prices and download coupons)
Thanks to @ruhanirabin whose tweet alerted me to these results!
Smartphone developers choosing to include the Flurry usage statistics tool in their apps tend to contact Flurry early in application development. So Flurry have a leading indicator of what app developments are getting underway. They have used this information to produce a lot of interesting stats about the smartphone market, in what they call the "Smartphone Industry Pulse (July 2009)" Data from Flurry features in my last post , but I also wanted to discuss their data on projects getting underway for Android and for iPhone.
In the first half of 2009, the number of Android projects incorporating Flurry increased - Android projects made up 10% in January, up to 20% in June (over 200 projects started in June). Flurry have this rather striking graph:
This graph looks pretty alarming for Apple, until one also knows that the total number of smartphone apps was increasing dramatically over this time. The following chart shows the number of iPhone projects - rising from 200 in February to just over 1,000 in July.
(The corresponding Android graph is available on the the "Smartphone Industry Pulse (July 2009)" post of the Flurry blog, along with much other interesting data).
Some thoughts about this:
First the caveat - these data are only about projects that include Flurry (possibly the pattern would be different if we had data about all the apps that don't plan to track usage)
Secondly - loss of market share by Apple is probably inevitable now that other players are in the market big time.But since when was Apple about market share? I see them as a sort of computer Bang & Olufsen - making highly designed, high quality and expensive stuff for the part of the market that likes it, and leaving other companies to scrap over the mass-market.
Lastly, I wonder how many of the Andriod projects are apps that are ALSO being developed for iPhone. As far as I know it is difficult and risky to develop the one app for multiple platforms (technical issues, and Apple are said to be sniffy about passing any app not built with their SDK ). So developers may be forced into running twin projects, just we we used to do in the late '90s to develop desktop apps for Mac and PC.
I have unhappy memories about developing for the cranky PowerMacs of that era! You could use file extensions that had profound powers on the Macintosh OS. On a good day that was excellent, but on most days you ended up with a gang of file extensions fighting each other like a sackful of cats until the OS keeled over. To make things more frustrating, patches to the OS would suddenly declare a particular file extension persona non grata and uninstall it. That happen to one of my projects just before it was about to launch. Hence the joke of the time - "Q. What does MACINTOSH stand for? A. Most Applications Crash, If Not, The Operating System Hangs." [For balance I should say that the counter-joke wasn't bad either: "Q. What does MICROSOFT stand for? A. Most Intelligent Customers Realize Our Software Only Fools Toddlers ] All that put me right off Macs until quite recently - and should remind me to be a bit patient with strictnesses Apple might want to impose about use of their SDK.
One more thing - if you include Flurry on an Apple application, do you have a MacFlurry? ;-)
Flurry provide a usage statistics service for smartphone applications, collecting data when the application is downloaded or used. As a result they have interesting data on the state of the smartphone market.
Eyecatching for me is the chart in the "Smartphone industry pulse July 2009" showing that customer use of eBooks is rising quickly and is second only to games:
The data probably underestimate the situation, as far from all eBooks will have Flurry embedded in them.
In another analysis "Mobile apps: Models, Money and Loyalty" Flurry have also looked at how frequently apps are used, and how likely users are to return to them after 90 days. That suggests that books are used intensely (maybe 10 times a week), but are not used much after 90 days. The customer has finished the book by then, presumably.
For the technically minded, Flurry describe the technical workings of their service thus:
Flurry Analytics places a lightweight agent into an application, so
that performance data are tracked, logged and reported back for
analysis. This information is confidential and available only to the
developer to analyze in aggregate. Individual user data is not
identifiable. Developers are provided a wealth of metrics around usage
behavior, any custom event they choose to track and technical
information about the device, firmware version, carrier and more.
I've finally found some demographic data for iphone and ipod touch users. The data come from a survey done by Admob and comScore, as published on the AdMob blog and reviewed by BusinessWire (which has figures not included in the blog post). The survey was in the first half of 2009 (presumably in the US, though this is not stated). I was after age data, which gives me this chart:
iPod touch ownership was highest among the 13-17 years age group (46%) falling sharply after age 25 (23% of ipod touch users were 18-24, 12% were 25-34 and 12% 35-49. After that it's single figures). iPhone owners are older - only 6% were 13-17; 20% were 18-24; 27% were 25-34; 31% were 35-49. This is pretty much what one would expect: iPod touches are cheaper and can be bought for a one-off payment (no ongoing mobile phone bill). So they are a possible (generous) Christmas or birthday present. In the UK at least, you still have to sign up for some hefty costs to own an iphone. So probably another case of "you can tell the men from the boys by the cost of their toys" as a friend of mine used to say. Speaking of men and boys, >70% of the owners (of both iphone and ipod touch) were male.
For other data (income, how mobile usage compares with usage of other media) check out the original article at AdMob
These data may go some way to explaining an interesting observation from "Just Another iPhone Blog" - "Do Crap Apps have legs?" The author comments on the curious popularity of "Crap Apps" - (applications that are trivial and/or puerile).
When I say I found it disturbing I should emphasize that I DON'T mean that this workflow is inherently bad - the whole point of this article is that it was just not what I was used to. I found it interesting that this made such a difference. For many years I have noted my start time, noted my stop time and then made any other notes. So this is how I would have designed my own timesheet app. (I did consider running my timesheets via a spreadsheet, and then I
could have done exactly this. But so far I've found spreadsheets clumsy
on the iPhone - not so much the spreadsheet apps, but the small screen
and so the feeling of painting the hall through the letterbox.). When you think about it, clicking start and stop comes to the same thing as writing down start and stop times. But still, I found the iPhone apps clumsy and difficult to use, and would certainly have reported this if I had been taking part in a usability trial. I nearly rethought the whole idea. A few days later, I'm settling down to using this stopwatch method and don't find it difficult any more. 
