I've been experimenting with the email service provider Mailchimp as a way of delivering email newsletters for the Oxford Oxfam Group (of which I am Treasurer). So far, I like it a lot. Today, I've been putting together a draft of the next email newsletter, and sending it to the rest of the committee (both as a test of email delivery and so they can see my draft). Lacking details in places, it seemed funny to go with the chimp theme and replace missing information with "OOK OOK EEP EEP OOK
OOK EEP EEP"(Noticeable for sure, or I just have an odd sense of humour, perhaps)
Result - most of my emails don't make it past the spam filters. But removing the "OOK OOK EEP EEP OOK
OOK EEP EEP" promptly puts that right.
Day 1 lesson 1 therefore - when the say "test your email before you send it" they really mean it.
Day 1 lesson 2 - spam filters have no sense of humour (or possibly don't like monkeys). Repeated nonsense words are really a bad idea.
The Software Usability Research Laboratory (Wichita State University) has done a study of how usable Twitter is for first time users. The trial showed up some interesting problems that the new users had, one problem area being Twitter jargon. And there certainly is a lot of jargon (tweet, RT, follow, follower, via, @Chris_JB, DM, hashtags...).
Personally, my impression is that Twitter delights in jargon and strange conventions. Maybe that is not surprising for a product that has emerged rapidly from being a bit of a subculture with its own house rules and terms. I would not have got far enough with Twitter to use it much without the TwitterBook (or #TwitterBook if I'm going to "hashtag it" - i.e. add a # so that Twitter sees it as a search term.). So the "in-crowd" nature of Twitter means well-deserved sales for O'Reilly and Milstein, at least (it's an excellent book - both from the information point of view, and a very cool and usable design).
The combination of Jargon and good books makes me unable to resist this quote :
"My name is Marcus Yallow, but back when this story starts, I was going by w1n5t0n. Pronounced "Winston."
Not
pronounced "Double-you-one-enn-five-tee-zero-enn"— unless you’re a
clueless disciplinary officer who’s far enough behind the curve that
you still call the Internet "the information superhighway."
Little Brother by Cory Doctorow (Pronounced...Oh, never mind).
See the same effect of jargon to be different from the mainstream?)
A hazard for fashionable and cool new products then - do you go exclusive or usable? [Assuming here that I'm not exposing myself as a clueless project manager who's far enough behind the curve that I still call Twitter fashionable and cool :-) ]
So, will Twitter abandon its jargon in favour of more usability as it (or its successors or competitors) become more mainstream? Or will things go the other way? I've now seen several forum posts where a contributor wants to comment specifically on an earlier contribution (say by me Chris _JB) and uses the @ sign to indicate this (as in "@Chris_JB - I couldn't disagree more...") A convention that has come from Twitter, I think.
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.
UXmatters have a well-argued discussion of the pros and cons of checking your design by user testing, as opposed to having an expert do a review. These methods achieve different things. For example, suppose you have a design including green navigation tabs, with a red colour being used to show highlighting. A usability reviewer should immediately point out to you that this design is not usable to anyone who is red-green colourblind, which is a point you might miss if you tested with real users, and none of them happened to be colourblind. On the other hand, expert reviewers can suffer from their own biases about how things ought to be done. The ideal is to do both - review the design from a usability point of view yourself (bringing in an expert if needed) and then try it on real customers. Real customers are the only way to get the authentic - and sometimes unexpected - voice of the customer. Among the things real users can do for you is to help you explore whether you've designed workflows in the way that the users (or most of them) expect.
Thanks to @IATV, whose tweet alerted me to this UXmatters article.
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!
This morning I did a double-take at my InBox, as I seemed to be subscribing to an email newsletter called "IT Security Bull". A more frank and honest title than many, one would think :-)
Almost a letdown to realize that it is just the way the title doesn't quite fit into the "From column in Outlook, leading to "IT Security Bulletin" being truncated.
For similar reasons I subscribe to "Tools of Chang":
..which ought to be a fantasy or marital arts epic, but us actually the very useful "Tools of Change for Publishing" Newsletter. I kinda like "Tools of Chang" though.
"Technical debt" is a nice metaphor for discussing the long-term costs of some project decisions. For example, imagine that you are building a complex website that has a tight commercially driven deadline (e.g. it must be ready to do business by Thanksgiving/Christmas). The way you would ideally like to do the project is not compatible with that schedule, so you decide to develop faster, deliberately choosing a solution that is less easy to support in future, is less extensible, less robust, requires more maintenance, or suffers some other trade-off. Just as if you had taken out a loan to finance the project rather than take it out of revenue, you are committing yourself to future expenses (cash, staff time, more imminent replacement of the system) in order to buy short-term progress. This might, of course, be entirely satisfactory if the profits from being live by Thanksgiving are attractive enough.
Of course not all debt is deliberate - just as you can work up a big overdraft by spending carelessly, a poorly run project could get deep into technical debt by inadvertently doing work that it will be difficult to support or extend.
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. 
