Tom Hume

Steph's pointed to this interesting set of documents. I'm going to dip into them over the next few weeks, but particularly enjoyed hearing how they're structured:

"I have found that, having started this set of notes in 1990 in the (for me) novel medium of hypertext, it has been difficult to tear free of it: my attempts to lend hierachical or serial order have been doomed to failure. Further, as ideas and these web pages have evolved, it has been important for me to be able to reorganize my thoughts, grab a new leaf, shake the tree and regard it as the root. So the reader needs to be aware of this, that each page may be an attempt to put across a given concept serially, but if you are looking for an order of concepts and subconcepts, you have as much hope as you would with words in the dictionary. "

The Guardian have released figures for their iPad product - 17,000 iPad subscriptions, an unspecified number of Kindle ones.

I was trying to work out if this is good or bad. It's bad, because that's a small number (£2m gross revenue p.a. before Apple's cut). But with daily print sales of 211,511 in June, that makes iPad 7.5% of (print+iPad) readership.

I wonder how that compares to the percentage of Guardian readers who own iPads... my gut would be plenty of room for growth. I'm curious about those Kindle figures, which would reach a different audience... and I wonder whether there's any plan for a paid-for Android product?

Update: after a chat on Twitter with Benedict Evans: there are apparently 5.5m iPads in the UK, so iPad ownership here is 10%; not all those iPad subscribers are UK, of course, but it's a useful comparison. Not sure if we could conclude that iPad ownership in Guardian readers accords with that though, according to their own stats on readership their audience is roughly average in terms of age and gender, but skews towards being better educated and more likely to be AB than most. Accordingly I'd expect iPad ownership to be way higher - double? - for them.

A little coterie of Brighton folks wandered up to the Self-hacking day in London, run by some of the Quantified Self crowd. I've not been to the monthly London meet-ups, but have been following this kind of thing for a few years now, on a no doubt hackneyed path that started with Nike+ and took in Mappiness, 23andme, and recently Runkeeper.

The morning saw a few talks:

• Alec Muffet and Eric King of Privacy International, talking about security concerns. In particular, the terrifying-sounding kit the Metropolitan Police have acquired to take copies of data from mobile phones (and the outdated laws which allow them to do it), broken assumptions in our attitudes to security regarding devices we physically control, privacy policies and the need to think more carefully about any data one records being published;
• John Fass on data visualisation principles, calling for visualisation to be considered from the start and not tacked onto the end of QS products. John gave a good talk I failed to completely follow (and will try to watch again); but I liked his idea that the rise of info graphics reflects a panic about the quantity of data we're faced with;
• Ian Clements told the by turns inspirational and horrifying story of his diagnosis with terminal cancer, when he was given a few weeks to live… 5 years ago. Ian's been gathering data on himself since 1974, and has a stronger imperative than many QS folk. I was horrified both at the attitude of medical professionals (who aren't interested in his data, or in one case will take it but on condition they don't reveal their findings to him), and that there's software out there he'd like to use for analysis of his multivariate logs, but just can't afford.
• Ken Snyder gave an overview of a few trends: convergence of the wellness, healthcare and social Internet industries; multi-sensor devices, medical devices become more consumer-oriented, rise of smartphones, and wearables; and consumer trends around simplicity, more mainstream use of QS (shifting the focus away from power users, where it is today), getting the isolation out of self empowerment, and data ownership.

Then after lunch, a couple of break-out sessions followed. For the first one, I took part in a group talking about behaviour change: where, after all, is the value in all this measurement if it can't be used to effect improvements? We rambled through BJ Fogg, talked about the need to consider closely which habits to create, what "kicks" would contribute to setting them up, and what environmental clues might be used to trigger "kicks"; the role of social support and accountability (touching briefly on buddy systems - tiny 2-person social networks, and something I don't think we've seen enough of, digitally); and models of willpower as a muscle which can be exercised, vs being a depletable resource. Personality styles also emerged as important - how would a service adapt to usage by loss averse individuals, vs gain/reward types? And is the act of recording data itself useful - or would a completely automated system which required no participation from its user miss an important trick? Finally, someone brought up Nicorette as a good metaphor: a system which encourages good habits, and is then designed to fall aside in time, leaving the good habits in place. You don't see many digital QS services which encourage you to leave after a while…

The second session I found a bit less focused: we talked about archiving of data and wobbled between the value of deliberately constrained networks (which I'm sceptical over), Wi-fi vs LTE, and lack of nuance in privacy policy (we permission to organisations to use our data, but rarely constrain what they can do with it beyond sharing onwards).

A fab day, overall. I've been to a couple of these events now, and every time they feel really exciting: QS feels like a movement that is just going mainstream. Kudos to Adriana and team for organising and running the day, and thanks to Hub Westminster for hosting.

It's no secret that Amazon is shaking up the publishing industry. I've been watching a friend go through some interesting experiences with self-publishing recently, and he's given some figures and permission to write about it.

Paul's been writing (mainly crime) fiction for a little whole now, drawing on his experiences as a police officer in Brighton, and his slightly diseased imagination. After quite a long process of talking to traditional publishers about The Follow, a novel about heroin dealers in Brighton, he decided in November last year to start publishing digitally. There's still a bit of a stigma associated with this sort of thing - I think that an important part of a traditional book deal is the validation of a large publisher saying "we think this is good" - but with the novel sitting unpublished for a little while, why not?

He hooked up with Trestle Press and put it onto Amazon at a quite low price point of £3.69. By mid-February, he was selling a couple of copies a day.

In March, he dropped the price to £1.99 after taking The Follow back from Trestle, and publishing himself. Sales hovered at between 10 and 18 a week.

In May, Paul decided to stop promoting The Follow and see what he could publish next, but noticed that he could make it free for 5 days using KDP Select; he flicked the switch to see what would happen, and saw 3000 downloads in the first day: both a boost for the ego and not a bad promotional device: "Now thousands of people were reading my book, and it hit number 2 in the free Kindle chart."

Sales crept upwards after that. The next day he was the 400-or-so most published book on Kindle, and had sold 30 copies; the day after that he was ranked at 250; and a week after the promotion he'd sold 400 copies and was sitting outside the Kindle top 100 (and in the top 10 of the "procedurals" section, which I think is police fiction); sales at this point were about ten a day.

Reviews seem to have a direct impact on sales: after a negative review sales dip slightly, then increase again once a positive one comes through (perhaps the "most recent review" holds a lot of power).

Things I've noticed, watching Paul go through this journey:

• Most people I know who write do it for love, and to reach an audience. Digital publishing seems to offer both this, and the promise of some sort of return.
• I'm sure that a publisher knows how to market and distribute books better than the average author; but when the alternative is to not be published at all, digital self-publishing looks attractive.
• A promotion can build sales traffic, but it drops off shortly afterwards.
• The direct relationship between quality of reviews and sales.

There's been a lot of noise about Google's rationalisation of its privacy policies recently. I was late to the party as usual, but popped over to the dashboard to see what it knew.

My immediate impressions:

1. That's quite a bit of information; all the Android phones I've owned, apps I've installed, blogs, calendars, etc. Looking at it glass-half-empty: "this company knows a lot about me and I find that uncomfortable". Glass half-full: "I'm getting a pile of extremely useful services which I completely take for granted at no cost to myself". In practice I definitely err towards the latter;
2. I wonder how I could see the equivalent information other advertising networks, or Facebook, own about me? I suspect that I can't - anyone know different? - in which case Google are ahead of the others;
3. There were links to delete my Google buzz, location history, and web history. Individual products (e.g. Youtube) have the option to remove my history from them too. Removing history doesn't mean all the data has gone. Yahoo, in their more detailed but less clear privacy policy, are a bit more specific on how long this data is kept for ("Yahoo! stores this data in an identifiable form for up to 18 months"). I couldn't see how to delete this data, in any way, on Facebook or Yahoo!

Overall, I felt reassured, particularly after comparing to other parties who gather large amounts of personal data about me. Being able to go to one place to find out how it's used is definitely better than having to read 50 different per-product policies. I'd like to know more how long data is kept in either its original or anonymised form. I'd like Facebook in particular to present a similar view of what they know about me.

I've just had the pleasure of spending a weekend in Amsterdam listening to an interesting group of measurement-obsessed folks, at Quantified Self 2011. I was introduced to the QS movement a couple of months ago by a chance conversation with Colin Hayhurst, and it piqued my interest. As a former Nike+ user who'd seen the difference personal measurement made to my running habits (tripling the distance I regularly ran) and having participated in Mappiness for a year, I was looking forward to it - and wasn't disappointed.

Some scattered observations and notes, which will do no justice to the event whatsoever:

• Gary Wolf opening the event by showing us footage of a 1930s sleep-tracking machine, with pieces of string attached to a plotter pen and roll of paper. He pointed out that we all understood the "quantified" bit, but the "self" less so;
• Rain Ashford gave an introduction to Arduino and wearable computing. I couldn't help noticing that the sewable stuff she demonstrated tended towards an aesthetic of exposed wiring and circuitry: PCBs look dated to a steampunk degree. The epidermal electronics she showed off from the University of Illinois were fantastic;
• Sascha Pohflepp (who I notice had collaborated with Chris Woebken, one of the folks behind Animal Superpowers, a personal favourite of mine) did a nice breakout session on stories and data tracking - exploring the generation of autobiographies automatically ("auto-auto-biographies") from data captured by phones. "The future of writing will be the future of writing down everything", with the act of recording becoming meaningless as everything is naturally recorded: we're the last generation whose life won't be part of a perfect record. Sascha's been exploring these ideas through a project he called "the book of everything" which sounded like LifeBlog without the blogging: creating a narrative text automatically from on-phone data;
• Kiel Gilleade talked very clearly and entertainingly about lessons he'd learned from a year of gathering his own heart-rate data and streaming it publicly. Some of this covered awareness of health issues (e.g. his resting pulse failing to return to normal levels when sleeping, for a day after heavy drinking); some around data visualisation (time series graphs being rubbish for plotting lots of longitudinal data, coloured coded charts making more sense); and some around the social effects of such data sharing (friends contacting him, concerned to see his heart rate high when he's working hard);
• The team behind iYou showed off some of their visualisations of communications patterns gleaned from their iPhones, looking at how communication moved between SMS, voice and Facebook in different contexts and for different people; at how different media tended to be used for different types of communication (SMS for locative chat, Facebook for messages mentioning love or happiness); and at how different media took precedence at different times of day or night. Autocomplete dictionaries maintained by mobiles are apparently interesting repositories of frequently-used words. One lovely comment which emerged from a group discussion afterwards was the fragility of the notion of "owning one's own identity": it's constructed to a degree by those around you, the idea that you own it just doesn't hold;
• James Burke led an interesting session around quantifying relationships, which took us towards the difficulty of measuring something so completely subjective, rescuing the whole idea of doing so by pointing out that even if such quantifications are devoid of any objective value, they're useful for stimulating helpful conversations;
• Steve Dean did several talks, all of them excellent. One was a history and demonstration of Asmthapolis, a project to track asthma attacks on an individual level by providing inhalers which automatically record their use, generating data which can be useful on an individual level (for combatting subjective views of one's own condition) and societally for mapping asthma attacks and using these maps to inform investigations - as happened in Barcelona in the 1990s, when the unloading of cargo shipments of soya beans were subsequently linked to asthma break-outs. Some of the discussions in these sessions veered a little over my head (third order cybernetic feedback loops? emotional valence?) but Gary Wolf popped up to make a very interesting observation about the tension at the event between those demanding passive data collection (easy, transparent, all-seeing) and those for whom the act of actively recording was itself a source of joy.

That was day one :) Day two followed day one, as it so often does.

• Ian Li gave a nice lightning talk about design considerations for QS products: provide an immediate benefit to the user, respect that their information needs change over time, and help them analyse many types of data as it does so;
• Nancy Dougherty gave a fantastic overview of her experiments with self-made placebo pills to stimulate awareness of, and address, her moods: hacking her own psychology. The pills also contain chips which activate in the stomach and record readings of the inner state of her body, which combined with a patch she wore on her torso gave her a great deal of data to work with. And the whole experiment led to her adopting a mindset of greater control over her emotional state (including 10 minutes of emotional indulgence she noticed she was giving herself, before her placebos kicked in);
• A long and popular session by Maarten den Braber on QS business models raised a few interesting points, notably that many of the participants seemed to presume these models would be based around a Web 2.0-style service. A nice chap from Jawbone quietly gave his perspective on things (which, coming at it from a hardware angle, was a little different), and was clear that they see a market for selling "millions of devices"; and that for many companies this whole area of self-measurement was "the next battleground";
• Steve Dean returned to talk about the practicalities of behaviour change and strategies for achieving it - taking it a little bit beyond rehashing Nudge and towards the work of BJ Fogg - who was referenced several times, and moves a couple of notches up my reading list as a result; apparently quite a few of Fogg's students now work at Facebook, which employs many "hot trigger" techniques to stimulate repeat visits. The important thing seemed to be to provide a path of many individually small steps towards a goal, where intrinsic motivation is possible - rather than trying to continually beat or bribe your audience into behaving how you'd like;
• And finally, Laurie Frick ended the conference showing off her work, consisting mainly of handmade objects derived from self-tracking data - starting from the notion that visual patterns and the rhythms of the brain are somehow connected.

A really interesting couple of days, that's triggered a few ideas I want to follow up and given me a great deal to mull on. The audience was enthusiastic and unashamedly geeky - it all definitely felt excitingly early-stage, though whether in a post-Nike+ world that's accurate is another matter.

I couldn't help but notice that many QS projects rely on after-the-fact analysis of data, and that if you believe that measuring changes what one measures, more immediate feedback would seem to be a useful thing. Context of analysis also popped up again and again - editorialising seeming as relevant and powerful when applied to personal data as to news. And I saw a persistent disconnect between the enthusiasm of the attendees and the number of stories of this stuff going beyond the geeky individual into the mass-market, which is likely the challenge for the field over the coming years. I'm left mulling over how to get this into everyones pockets…

And for your reading pleasure, here's a pile of links which were lovingly thrown out throughout the weekend:

• Zeo sleep tracking;
• Photos from the weekend;
• ManicTime to track your computer usage;
• MoodJam by Ian Li, track your moods using colours;
• BJ Fogg's Behaviour Grid and Behaviour Model;
• InnerTube.me, a tool to aggregate and visualise personal informatics;
• Moodoscope;
• Heart rate monitors from Polar;
• Rapid-I, open source data mining software;
• Boozerlyzer;

Updated: Ian Li has mailed me with links to his design considerations presentation and one he gave on integrating visualisations with Innertube.me.

One of the most interesting talks at OverTheAir was, for me, hearing Andrew Betts of Assanka talk about the work he and his company had done on the iPad web app for the Financial Times, app.ft.com.

It's an interesting piece of work, one of the most accomplished tablet web-apps I've yet seen, and has received much attention from the publishing and mobile industry alike. I've frequently heard it contrasted favourably with the approach of delivering native apps across different platforms, and held up as the shape of things to come. Andrew quickly dispelled any notion I had that this had been a straightforward effort, by going into detail on some of the approaches his team had taken to launch the product:

• Balancing of content across the horizontal width of the screen;
• Keeping podcasts running by having HTML5 audio in an untouched area of the DOM, so they'd not be disturbed by page transitions;
• Categorisation of devices by screen width;
• Implementing the left-to-right carousel with 3 divs, and the detail of getting flinging effects "just so";
• Problems with atomic updates to app-cache (sometimes ameliorated by giving their manifest file an obscure name);
• Using base64 encoded image data to avoid operator transcoding;
• How to generate and transfer analytics data with an offline product;
• Difficulties handling advertising in an offline product;
• Problems authenticating with external OAuth services like Twitter or Facebook, when your entire app is a single page;
• Horrendous issues affecting 8-9% of iPhone users, who need to reboot their phones periodically to use the product (I picked this up from a colleague of Andrew's in a chat before the talk);
• Lack of hardware-accelerated CSS causing performance problems when trying to implement pan transitions on Android;
• etc.

All of this really drove home the amount of work which had gone into the product: app.ft.com took a full-time team of 3 developers at Assanka 8 months to launch on iPad, and that team a further 4 months to bug-fix the iPad and ready for distribution to Android tables. (It's not available for Android tablets just yet, but that's apparently due to a customer-service issue: the product is there).

Seeing the quality of the product, I've no doubt that the team at Assanka know their stuff; and given the amazing numbers the FT report for paying digital subscriptions and their typical pricing for subscriptions, I'm sure the economics of this have worked well for them.

But the idea that it takes 24 developer-months to deliver an iPad newspaper product to a single platform using web technologies is, to me, an indication of the immaturity of these technologies for delivering good mobile products. By comparison, at FP we spent 20 months launching the Glastonbury app across 3 completely different platforms and many screen sizes; but this 20 months included two testers and two designers working at various stages of the project; development-wise I'd put our effort at 13 months total. Not that the two apps are equivalent, but I want to provide some sort of comparative figure for native development. I'd be very interested if anyone can dig out how long the FT native iPad app took…

And the fact that it's taken Assanka a further 12 man-months to get this existing product running to a good standard on Android is, to me, an indication of the real-world difficulties of delivering cross-platform app-like experiences using web technologies.

It strikes me that there's an unhelpful confusion with all this web/native argument: the fact that it's easy to write web pages doesn't mean that it's easy to produce a good mobile app using HTML. And the fact that web browsers render consistently doesn't mean that the web can meet our cross-platform needs today.

Adam Cohen-Rose took some more notes on the talk, here.

(At some point in the coming months I promise to stop writing about web/native, but it keeps coming up in so many contexts that I still think there's value in posting new insights.)

I've written a few times about the general dissatisfaction I (and the team at FP) have been feeling over HTML5 as a route for delivering great mobile apps across platforms.

Back in June, I did a short talk at Mobile 2.0 in Barcelona where I presented an approach we've evolved, after beating our heads against the wall with a few JavaScript toolkits. We found that if you're trying to do something that feels like a native app, HTML5 doesn't cut it; and we think that end-users appreciate the quality of interface that native apps deliver. We're not the only ones.

Our approach is a bit different: we take advantage of the fact that the web is a standard part of any smartphone OS, and we use the bit that works most consistently across all platforms: that is, the JavaScript engine. But instead of trying to build a fast, responsive user interface on top of a stack of browser, JavaScript, and JavaScript library, we implement the UI in native code and bridge out to JavaScript.

Back-end in JavaScript: front-end in native. We think this is the best of both worlds: code-sharing of logic across platforms whilst retaining all the bells and whistles. We've called the product which enables this Kirin.

Kirin isn't theory: after prototyping internally, we used it for the (as of last night) award-winning Glastonbury festival app (in the Android and Qt versions) and have established that it works on iOS too.

Now, we're a software services company; we aren't set up to sell and market a product, but we think Kirin might be useful for other people. So we've decided to open source it; and where better to do that than Over The Air, just after a talk from James Hugman (who architected Kirin and drove it internally).

You can find Kirin on GitHub here. Have a play, see what you think, and let us know how you get on.

TechCrunch have been running a story about Diary.com adopting HTML5 for their mobile efforts. I found it quite a strange article, and it plays to some of the scepticism I've been experiencing recently around HTML5 as a nirvana for cross-platform app development.

To me, the article reads like a sequence of arguments against taking such an approach:

• Performance problems: "The performance of the Diary Mobile App… was the biggest challenge", "it wasn’t easy, performance was a huge issue at times it took days to figure out, and simple things like too much logging and poorly constructed ‘for’ loops actually made our app unusable during our journey."
• Reliance on third-party toolkits which are outside your control: "Sencha Touch is quite a beast and we’ve had to patch quite a lot of it to make it more performant and apply bugfixes", "we had some serious issues with the performance of Sencha Touch on some of the input fields that we had to provide fixes for"
• They ended up having to do native development anyway: "We built two Phonegap plugins; a Flurry API PhoneGap plugin for iOS (to be released open source in the future, and another to use the Local Notifications on iOS (also open source plans)"
• …and it sounds like they had to build a new API to service the back-end of the app (which admittedly they can probably reuse elsewhere): "We built an entirely REST API for which the app communicates with to make it as efficient and fast as possible"

This doesn't sound like an easy route out of the pain of cross-platform native development to me. Hats off to the Diary.com team who've made this work - HTML5 clearly hasn't provided a simple solution to their problems. And from a quick look at the reviews on the Android marketplace, end-users are reporting sluggishness in the app (something we've noted they really care about) and the lack of a native look-and-feel (see screenshot, right).

I don't mean any disrespect to the diary.com team by pointing this out - they've clearly done a great deal of hard work in getting this product out there, and put a lot of effort into working around the limitations of HTML5 as far as they could, but despite this effort these limitations are still noticeable. And it's not just diary.com who seem to have experienced this - the FT, who've blazed a trail with their web apps for iOS, haven't launched a web product on Android yet: which doesn't suggest there's a great cross-platform story here.

How much of the current enthusiasm for HTML5-on-mobile is driven by wishful thinking on the part of the industry? It doesn't seem to offer much to end-users, who are often the ones funding the content with their wallets or eyeballs, and who are increasingly choosing to access mobile content through apps, not the web.

I can't help but think back to all those companies offering "write once, port automatically" solutions for J2ME a few years back. I've yet to see one which demonstrated that it could do the job well beyond a certain, simple class of applications, and I'm starting to feel the same way about HTML5 for mobile. In particular I think the cost of porting is being underestimated (just as it was for J2ME) - web-on-iOS might be performant, but getting it going beyond Apple kit takes time and effort. To be fair to the diary.com team, the reviews I can see on the iTunes App Store are broadly positive - suggesting that on Apple devices HTML5 is a stronger contender, but weakening its case cross-platform.

I really really really want a pony, but that doesn't make it right for me to saddle up Mr Falletti and ride him around the office. And the fact that we want or need an easy way to do cross-platform apps doesn't mean the web will give us one. I'm leaning towards the same view I had with J2ME: you'll need a mix of techniques, tools and experience to do this well, you can't avoid dealing with the underlying platforms, and silver bullets are in short supply.

Thanks to James Hugman for his contributions to this post.

I started playing with the Songkick APIs a couple of weeks ago. Songkick is a lovely service I've been using for a couple of years, that tells you when your favourite artists are touring nearby. In much the same way as Nike+ and Kindle, it's made a big difference to my life by stimulating a specific behaviour: getting out to see live music.

The API lets you query their mahoosive database of gigs and artists fairly simply - I've open-sourced a Java library which I've written to access their REST API, and wanted to use it on a Real Project to prove to myself that it actually worked for something useful.

I've rarely gone to gigs by myself. It's always been a social experience for me, and nowadays in my late 30s I quite enjoy catching up with an old friend by heading out to see someone from Our Youth play live. A couple of long journeys and a lazy Saturday in Barcelona gave me a chance to finish SongkickFor2, a little web app which helps you find a gig to go to with a friend. It's pretty simple: tap in your and your friends' Songkick usernames, and get back a list of upcoming concerts you both might like. I link through to the Songkick pages for these concerts, where you can buy tickets.

The sole reason this app doesn't look dreadful is the markup, CSS and aesthetic mastery of Dom, whose flat I'm staying at and who I worked with in the early years of Good Technology.