Well, today Apple are going to "unveil" the iSlate or iTablet. Once again they have been wonderfully adept at stoking a huge amount of enthusiastic speculation. Hats off to them for the marketing, but but I'm not going to write about it until the product is there.
Stoking speculation is fun and good for business, however. So imagine the excitement to come with these Apple products that, I can exclusively reveal, I have totally made up:
iLiner - thin, slivery shiny cruise ship
iPerdrive - futuristic propulsion system for cockney starships
iDoll - a child's toy, likely to be banned in fundamentalist families (engraving will be available from Apple stores if you want a graven iDoll)
iChair - device for feeding small children
iDahoe - device for cultivating potatoes
iCycle - new kind of 2-wheeled personal transport, combined with exercise equipment
iCon - perhaps the most quintessential Apple product. No-one knows what it's going to do, but it is shiny, desirable and sure to shake the industry
No good trying to get Apple to verify these rumours - they will, of course, deny everything.
This year, I've once again used the Oxfam Unwrapped system to send my clients my Christmas wishes, rather than sending printed cards. For those unfamiliar with Oxfam Unwrapped, Oxfam describe it like this:
"Oxfam Unwrapped offers a range of great gifts suitable for any
occasion – here’s how it works. You choose a gift, such as a goat. You
get a gift card to give to your friend or relative as a memento of the
gift.
The gift goes to someone who needs it. Whether it’s a cow to provide
milk and fertiliser, the tools and training to plant an allotment, or
safe water to drink, the result is that people’s lives are much
improved!"
I started doing this a few years back, feeling that I was getting through a lot of paper sending out cards. Nice as they are, they all end up in recycling by New Year. So sending out an e-present instead seemed a more useful and greener thing to do with the Christmas Card budget. What the recipients actually receive is an e-card (quite a nice one this year, with an interesting feature that you can click a button to respond by email - yes, metrics even at Christmas time!)
The feedback has been nearly entirely positive - the only negative was the first year, when I unimaginatively chose a goat. This somewhat dismayed those recipients who were vegetarians and against animal farming. (There have also been some press critique about buy-a-goat schemes that are poorly managed - for instance giving someone a goat who does not want a goat. Fundamentally, this is about whether you think the charity in question is competent. I think that Oxfam is highly competent.) So, no goats this year.
Here's what went in the stockings for projects completed this year:
For Professional Engineering Publishing, I was celebrating two projects. Earlier in the year, I project-managed a redesign of the house website www.pepublishing.com. We added a microsite for each of the academic journals published by the company, as well as refreshing the look. The just this month we've launched a new job site for engineering professionals www.topengineeringjobs.com . An Oxfam Unwrapped present of "helping to keep the Oxfam fleet of field vehicles going" was a suitably engineering gift.
At the Journals Division Oxford University Press, I worked on a new usage statistics system, and we had barely launched that in the spring before it was time to add features for the COUNTER 3 standard (COUNTER is a code of practice for the publication of usage statistics about academic journals and books). This included setting up for SUSHI, a protocol for disseminating usage statistics automatically. Some school books made a very appropriate Oxfam Unwrapped present for colleagues on those project teams.
And now it just remains to wish you, readers of this blog, a very happy Christmas and New Year!
I am running a 1-day course at the Publishing Training Centre, London in February 2010, and again in June. It is called "Moving to Digital" and is for people who already have one or more years' experience in managing print publishing and are now undertaking digital publishing projects.
Publishers with experience in print publishing who are now moving to a digital environment can find the transition challenging. Current knowledge and experience needs to be adapted to a whole new format and it is easy to either over- or underestimate the adaptability of one’s current skill-set.
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'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.
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. 
