“Is it on the App Store yet?”

I’m preparing to find out, in a week or so, just how much of a hurdle the web versus native app issue still is on iOS.

When I originally launched ChangesThatStick.com in January, I had folks who were still waiting for the App Store icon to appear on the home page, months after launch. No-matter how much I explained… “It runs in your browser”, there seemed to be resistance.

Even the presence of a “Sign-Up” and a “Login” button didn’t make it obvious. You are already looking at it… click “Sign-Up”. Why would wrapping it up in a native app make it any more palatable than seeing it in a nicely-multi-tabbed browser? I even made it so that the app required no zooming, nicely sized itself to the device’s screen, and was usable by big fingers (often a complaint for web apps in iPhone browsers).

I think I understand this reluctance: It’s different. It’s unexpected. But, beyond making the whole “Add to Home Screen” prompts as obvious and friendly as possible, I suspect it’s just a matter of trying to turn the tide and get the masses used to web apps.

It’s an interesting psychological block. The ultimate divide between familiarity and a strange (but actually very similar) “new world” they feel reluctant to explore.

Seems to be a case of: Build it, and they will ask when it’s on the App Store 😉

You Have 3 Seconds To Entertain Me.

That’s roughly how long I reckon you’ve got when I look at your website / app / product landing page for the first time, before I move my attention elsewhere. Actually, that’s a little on the charitable side and it’s probably only if I don’t get distracted by something else… “Oooh, sparkles!”. Where was I? Oh yes, your landing page. It’s not an arrogant assertion about how important my time is versus your wonderful app, but rather a reflection of the average investment that a person will make in a new idea… and the conditions under which they’ll suddenly withdraw that investment.

Back in March, I wrote about the “friction” that causes potential users to ditch a new product before becoming a committed user of it: All of the things that stand in the way of them remaining interested, reading your landing page, following the signup procedure, focussing enough to “get” the app, making it a part of their life and turning into a regular user. That’s quite a few steps, quite a few hoops we, as engineers and app designers, are asking them to jump faithfully through. It’s no surprise that we lose potential users at each stage.

As part of my ongoing ChangesThatStick.com (CTS) re-write, I’m revisiting this issue and trying to remove as many of those points of friction as I can. After all, what’s the point in a re-write if I can’t improve it?!

One of the biggest obstacles I’ve addressed is boredom due to poor app performance. The prior incarnation of CTS relied heavily upon a connection to the server and performed (or didn’t perform) at the whim of that server, the Amazon Web Services infrastructure it runs on, your device’s connection to the internet (possibly a mobile or wireless connection), and all of the intervening nodes in between. On a good day, it looked slick and performant. On a bad day, you spent your time looking at a spinning icon… waiting… waiting… and probably giving up. The new version will work entirely in a browser, and will only need a connection to sync data with the server and other devices, which can be done later if the connection fails or is slow. All of this means that the app performs, gives rapid feedback, and doesn’t agitate users with every click or gesture. So, a significant cause of friction removed already, I hope.

The next obstacle I’ll focus on is the signup process. It simply must use social signup. Everyone has at least one of a Twitter or Facebook account, and a one-click signup — with some verification of the data that will be shared — means no typing, no thinking up a new password, and no additional points at which the (almost) new user is thinking “Do I really want to do this?”

The biggest obstacle, after signup, is whether the user “gets” the app. That means how well the app’s model (entities, concepts, terminology) fits with the mental model of the user who just signed up. If the app requires explanation, they’ll probably give up at this stage. I mean, who reads documentation anymore? Other than software engineers, I suspect no-one does. We all expect apps to fit into our heads and into our lives in an obvious, intuitive, even beautiful manner. That’s the kind of experience that wins a new user, gets them to keep using the app and, more importantly, compels them to tell other people about it. So I’m trying to align the CTS notion of “activities” and tracking of “goals” to the language that users might approach the app pre-armed with. Everyone who liked the idea of using it to change or improve some area of their life comes to the app with their own context. I want them to just get the idea that they record activities, then set some goals based upon them. What I don’t want them to do is need to visualise the entity diagram that I, as the app designer, have in my head! That’s too much work for most people. I’m learning never to underestimate how obvious the app must be. It needs dumbing down, on one hand, but with the corresponding addition of logic and rules and heuristics that make it adapt to the user from what little we know about them, on the other. Where a user needs to just get the app, the app needs to just know about the user, in some way.

Any mention of money also discourages users, and most don’t like to use something unproven that they fear they will be asked to pay for later. But, a portion of those who end up loving using an app for free are often willing to consider payment later… just not up-front, even as a concept. With this in mind, the app will essentially be free, but with a premium mode that unlocks certain restrictions (number of goals, monthly bandwidth usage… other factors I haven’t yet figured out). The main idea is clear though: Let folks use if for free, fall in love with it, and then discuss what it’s worth to them to open certain additional features, once it has a perceived value.

Of all the things I learned about friction with the first version of CTS, the biggest was how little I know about the real reasons that users ditch an app. For all that I can reel of the above factors, the only way of knowing what affects app adoption is to add analytics to the app and study what people actually do. I could go further and add A/B testing, but I think the first step is understanding who did what, and when. Who gave up on the landing page, mid-signup, post-signup, after an hour’s use, etc? All the things I think I know about app adoption are just ideas until I see them happening with real users.

Actually, an even bigger factor was simply my willingness to get the app out there. Getting a best guess out there, an MVP, letting people use it and studying what they do, is far better than presuming I know the features they want, or the ways they’ll use it. Far better to get a version out in the wild, with real people tracking real goals. With this most important point in mind, I’ve accelerated the rewrite and want a version out within a month. And then we’ll really find out what I’ve learned about app adoption, and friction… and I’ll write more then 🙂

The Unglamorous Side of Appealing Data Visualisations

20130710a-cropIt’s rather like the analogy of a swan on a lake; all calm and serene above water, but paddling like hell beneath. That’s what implementing data visualisations is like. Everything must look effortless, intuitive, appropriate, contextual… all things that require an awful lot of background processing, heuristics, and clever logic.

I’m about 75% of the way through my rewrite of ChangesThatStick.com and, this week, I’ve been tackling the various data visualisations which are key to the app’s ability to encourage and inspire people as they track and change habits and activities, or in-fact any aspect of their lives. All of these visualisations make heavy use of HTML5 Canvas, as this is a web app targeted at a range of devices.

The visualisations need to be simple enough that you can glance at them and get the gist, but complex enough to surface all aspects of relevant progress if you look for a little longer. Most users will not be familiar with interpreting charts or statistics, nor should they need to be. Colours need to be obvious (green is good, red is bad, everything else should be neutral), chart axes need to be appropriate (cover the value range requested, use “nice” interval values, be labelled clearly), and there needs to be just enough additional plain language to explain the non-obvious features without over-explaining and detracting from the simplicity.

Some people asked why I haven’t used a standard charting library for this. The simple answer: the charts they render are usually just plain ugly. The longer answer: I wanted these visualisations to be appealing, and that takes a great deal of subtle tweaking and fine-tuning. They also need to speak to a wide audience; something that the average charting library just doesn’t do.

Chart axes were the first challenge, as they must cover an appropriate range of values or dates for the features to be shown, with labels that fit the available screen space on a range of devices (iPhone right up to full-screen desktop browser). Axis features must appear appropriately, and disappear when not relevant. The date axis figures out whether there’s room to show day numbers, week markers, full or abbreviated month names, the year (if the year changes along the axis), etc. Numeric axes cover at least the requested range of values, but extend that range slightly so that “nice” units and intervals may be used, with labels that are readable, in the same units and to the same number of decimal places. Axes must redraw when the device orientation changes, if supported, or when a desktop browser is resized.

20130709b-cropCombining a vertical and horizontal axis together took some head scratching. Each axis is told what its maximum length will be, from the available screen space, and is asked to compute its depth (height for horizontal axis, width for vertical axis) depending upon the features it needs to fit in (values, labels, markers, etc), knowing that it may be asked to render in anything from 50-100% of that length subsequently. Once each has committed to a depth, this allows us to figure out how to fit both axes together in the available canvas space, following which we render them each in the space that each axis’ depth leaves for the other, aligning them so that they meet at the origin. What is left between them is the actual chart area to draw into, with each axis helping to map dates / values to pixel offsets along their length. Anything that falls outside of the chart area must now be clipped to hide it.

Numeric values in visualisations aren’t just numeric either. They are measurements: a combination of a value, a measurement type, and one of a range of units supported by that type. For example, 1cm is the value 1, the “length” measurement type, and the unit “cm”. Measurements may be displayed in any unit for that type (with conversions handled by the type), and in a range of unit schemes: cascading combinations of units we commonly recognise, e.g. “1 hour, 25 mins, 15 secs”, rather than “85.25 mins”.

Where features that don’t necessarily align nicely with an axis need highlighting, additional lines, arrows and text may need adding to a visualisation. For example, to point out how far a user still has to run to meet their daily running target, or by how far they’ve exceeded a maximum target. It’s no use expecting them to visualise this off the axis, and seeing an arrow annotated with “0.25 miles to go” makes it obvious. Annotations need positioning carefully alongside the main content, preferably in a smaller font, and perhaps set to be slightly transparent to avoid detracting from the main focus.

For devices with a higher pixel density (such as iPhones and recent iPads),  we can get away with using slightly smaller fonts and thinner lines whilst still being readable. And, in-fact, we need to do that in-order to fit everything in, because the overall screen dimensions are smaller than on a desktop. But those smaller fonts would look blurred on a desktop, and very thin lines can look sketchy, hence the minimum readable font size and minimum line thickness need to be appropriate to the device.

All of the above were needed for this relatively simple, non-technical app. Simplicity, it seems, comes at a price beneath the surface. But, I’m hoping the hidden work I’ve put into this makes the results much more appealing, and much more useful when people come to visualise their own progress. They really don’t need to be aware of all the paddling going on behind the canvas, and that’s how it should be.

And now, I’m returning to the slightly less-visual aspects of the app, in an attempt to get it finished this month!