We had a big hoo-hah this week over O2 mis-sharing customer phone numbers. They've been sticking them in the HTTP headers for trusted partners for years (a few services FP built used them), but it looks like someone misconfigured a proxy and they leaked out on the wider web. They've been found, had a public slapping, and apologised.

It's a shame, really, because identity is probably one of the last places where operators could really do something useful. They've long prided themselves on their ownership of relationships with their customers, and part of that relationship is their knowing who you are (more for monthly subscribers than PAYG, but still). I'm a bit puzzled as to why they haven't done more with this: one problem that the web has is a complete lack of innate sense of identity, which is why we all have to either remember lots of passwords, use software to manage different passwords for different sites, or have one password we use everywhere - and all of these situations are painful.

(Aside: I can imagine passwords being one of those things that we have to explain to our incredulous grandchildren as an artefact of a Less Civilised Time)

I get that for many people and many situations, this anonymity is a feature not a bug, but I don't see why anonymity and convenience have to be mutually exclusive. Operators, of course, know who you are: it's not called a Subscriber Identity Module for nothing. And, just as they missed the boat with location services 5-7 years ago (by gathering useful location data and either refusing to release it, or trying to charge £0.10 per location lookup, ruling out some classes of application completely and making most of the others commercially unviable), they're probably doing, or have done, the same with identity.

Imagine if when you bought your Orange phone, you could opt in to a service which identified you to web sites (Facebook, ebay, Google, Hotmail) automatically. Perhaps it could do this by presenting them with unique token, a bit like a cookie, which they could use to get your personal details from your operator (with your permission, of course). It'd be great for them (easier sign-ups and logins means more customers and more use), great for the end user (no passwords, hooray) and a decent proposition for the operator ("never forget a password with Orange"). If you're worried about security - well, you can lock your phone already and control physical access to it as well as you can your wallet.

This needn't involve sharing your mobile number - the unique token could be a one-way hash of the number, or similar: something guaranteed to be you and only you, but of no value to spammers if they catch sight of it. As a customer you could control which web sites could use it, and which didn't. Parental controls could be used to restrict logins to specific web sites from the phones of children. It feels like this ought to be useful.

There are privacy issues, true, but if you're using a mobile then you're already trusting an operator with your calling circle, communications, logs of text messages, web pages accessed… a whole pile of very private stuff. Is offering management of your identity on top of all this really a step too far?

One of the courses I'm really enjoying right now is Pervasive Computing. It involves playing with hardware (something I've never done to any real degree), ties into the trend of miniaturising or mobilising computing, and humours an interest I developed last year about the potential for mass use of sensors, and spoke about at Future of Mobile.

Dan Chalmers, who runs the Pervasive Computing course, has us playing with Phidgets in lab sessions, and very kindly lets us borrow some kit to play with at home, so I've had a little pile of devices wired up to my laptop for the last few days. The lab sessions are getting us used to some of the realities of working with sensors in the real world: notionally-identical sensors can behave differently, there are timing issues when dealing with them, and background noise is ever-present. At the same time we're also doing a lot of background reading, starting with the classic Mark Weiser paper from 1991 (which I'm now ashamed I hadn't already read), and moving through to a few discussing the role sensor networks can play in determining context (a topic I coincidentally wrote a hypothetical Google project proposal for as part of Business & Project Management, last term).

I've been doing a bit of extra homework, working on an exercise to implement morse code transmission across an LED and a light sensor: stick text in at one end, it's encoded into ITU Morse, flashed out by the LED, picked up by the light sensor, and readings translated back first into dots and dashes, then text. It's a nice playground for looking at some of those issues of noise and sensor variation, and neatly constrained: I can set up simple tests, have them fired from my laptop, and record and analyse the results quite simply.

Here's what the set-up looks like:

Note that the LED and light sensor are jammed as close together as I could get them (to try and minimise noise and maximise receipt of the signal). When I'm running the tests, I cover the whole thing to keep it dark. I have run some tests in the light too, but the lights in my home office aren't strong enough to provide a consistent light level, and I didn't want to be worrying about whether changes in observed behaviour were down to time of day or my code.

First thing to note is the behaviour of that LED when it's read by a light sensor. Here's a little plot of observed light level when you turn it on, run it for a second, then turn it off. I made this by kicking the light sensor off, having it record any changes in its readings, then turning the LED on, waiting a second, and turning it off. Repeat 200 times, as the sensor tends to only pick up a few changes in any given second. Sensor reading is on the Y axis, time on the X:

A few observations:

1. This sensor should produce readings from 0 to 1000; the peak is around 680, even with an LED up against it. The lowest readings never quite hit zero;
2. You can see a quick ramp-up time (which still takes 250ms to really get to full reading) and a much shallower curve when ramping down, as light fades out. Any attempt to determine whether the LED is lit or not needs to take this into account, and the speed of ramp-up and fade will affect the maximum speed that I can transmit data over this connection;
3. There are a few nasty outlying readings, particularly during ramp-down: these might occasionally fool an observing sensor.

This is all very low-level stuff, and I'm enjoying learning about this side of sensors - but most of the work for this project has been implementing the software. I started out with a dummy transport which simulated the hardware in ideal circumstances: i.e. stick a dot or dash onto a queue and it comes off just fine. That gave me a good substrate on which to implement and test my Morse coding and decoding, and let me unit test the thing in ideal conditions before worrying about hardware.

The Phidgets API is really simple and straightforward: no problems there at all.

Once I got into the business of plugging in hardware, I had to write two classes which deal with real-world messiness of deciding if a given signal level means the bulb is lit or not. I used a dead simple approach for this: is it nearer the top or bottom of its range, and has it changed state recently? The other issue is timing: Morse relies on fixed timing widths of 1 dot between morse symbols, 3 between morse characters and 7 between words… but when it takes time to light and unlight a bulb, you can't rely on these timings. They're different enough that I could be slightly fuzzy ("a gap of 4 or fewer dots is an inter-character gap", etc.) and get decent results. There should be no possibility of these gaps being too short - but plenty of opportunity (thanks to delays in lighting, or signals travelling from my code to the bulb) for them to be a little slow.

I didn't implement any error checking or protocol to negotiate transmission speed or retransmits; this would be the next step, I think. I did implement some calibration, where the LED is lit and a sensor reading taken (repeat a few times to get an average for the "fully lit" reading).

I ran lots of tests at various speeds (measured in words per minute, used to calculate the length in milliseconds of a dot), sending a sequence of pangrams out (to ensure I'm delivering a good alphabetic range) and measuring the accuracy of the received message by calculating its Levenshtein distance from the original text. Here's the results, with accuracy on the Y axis (lower is fewer errors and thus better) and WPM on the X:

You can see two sets of results here. The blue dots are with the sensor and LED touching; the green ones are with sensor and LED 1cm apart. You can see that even this small distance decreases accuracy, even with the calibration step between each test.

Strange how reliability is broadly the same until 50WPM (touching sensors) or 35WPM (1cm apart), then slowly (and linearly) gets worse, isn't it? Perhaps a property of those speed-ups/slow-downs for the bulb.

So, things I've learned:

• Unit testing wins, again; the encoding and decoding was all TDDd to death and I feel it's quite robust as a result. I also found JUnit to be a really handy way to fire off nondeterministic tests (like running text over the LED/sensor combo) which I wouldn't consider unit tests or, say, fail an automated build over;
• I rewrote the software once, after spending hours trying to nail a final bug and realising that my design was a bit shonky. My first design used a data structure of (time received, morse symbol) tuples. Second time around I just used morse symbols, but added "stop character" and "stop word" as additional tokens and left the handling of timing to the encoding and decoding layer. This separation made everything simpler to maintain. Could I have sat down and thought it through more first time around? I have a suspicion my second design was cleaner because of the experiences I'd had first time around;
• I'm simultaneously surprised at the speed I managed to achieve; there was always some error, but 50 WPM seemed to have a similar rate to lower speeds. The world record for human morse code is 72.5 WPM, and I'm pretty sure my implementation could be improved in speed and accuracy. For instance, it has no capacity to correct obviously wrong symbols or make best-guesses.

Things I still don't get:

• Why accuracy decreases when the sensors 1cm apart are run super-slowly. I suspect something relating to the timing and fuzziness with which I look for dot-length gaps;
• Why the decrease in accuracy seems linear after a certain point. I would instinctively expect it to decrease linearly as WPM increases.

And in future, I'd like to try somehow taking into account the shape of that lighting/dimming curve for the bulb - it feels like I ought to factor that into the algorithm for recognising state changes in the bulb. Also, some error correction or a retransmit protocol would increase accuracy significantly, or let me run faster and recover from occasional issues, giving greater throughput overall.

Update: I've stuck the source for all this on Github, here.

So I'm well into the second term of the Master's now. Last term was mostly things I'd done before: modules on Advanced Software Engineering, HCI and Business and Project Management (the last covering large-scale portfolio management: connecting projects back to overall strategy and issues relating to large organisations). A fourth module, Topics in Computer Science, exposed us to the pet topics of various lecturers: TCP congestion management, Scala, interaction nets, super-optimisation, networks, and more. I was pleasantly surprised by how current the syllabus is: we were using git, Android, EC2 and TDD during software engineering and the HCI course was very hands-on and practical. (On which topic: I have a write-up of my Alarm Clock project to go here soon).

This term is the exact opposite: pretty well everything is brand new. I'm taking modules in Adaptive Systems, Pervasive Computing, Limits of Computation, and Web Applications and Services - the latter being a rebranded Distributed Computing course, so we're knee-deep in RPC and RMI, with a promise of big-scale J2EE down the line. I'm also sitting in on, and trying to keep up with the labs for, Language Engineering.

Thus far it's Pervasive Computing and Language Engineering which are sitting at that sweet spot between "I think I can cope with this" and "this stuff is fun". They're both quite hands-on: for the former we're playing with Phidgets and learning about the practicalities of using sensors in the real world, something I've talked about recently but haven't done much with. Adaptive Systems is enjoyable, but quite deliberately vague - like Cybernetics, it's applicable in all sorts of situations but I'm finding it jelly-like, in the pinning-to-the-wall sense. Limits of Computation I have mentally prepared for a struggle with: it's mathematical, and maths is not my strong point (when taken beyond numeracy); and the Web Applications module is so far quite familiar, though I'm looking forward to getting my teeth into a project.

I can't emphasis how much fun this is. It's been years since I've been exposed to so much new stuff, and joining some of the dots between these areas is going to be interesting. That said I've still no idea what I'll be doing for my project in the third term; the idea of doing something Pervasive appeals strongly, but I'm waiting for inspiration to strike. If that doesn't happen I might return to superoptimisation and see if I can carve off a dissertation-sized chunk to look into, perhaps something around applying it to Java byte code…

If you follow me on Twitter then every so often you'll see a tweet crowing about some figure or other behind the Guardian Anywhere news-reading application we launched at FP. For instance, last month we distributed our 5 millionth copy of the Guardian.

The Guardian Anywhere has been available for well over 2 years now, and we've depended on the goodwill of the Guardian in allowing us to use their RSS feeds, their Open Platform and even some branding in our product. Even though they've launched their own official Android app, we haven't been quietly asked to remove ours - which is to their credit, given that there's no contract or other agreement covering this between Future Platforms and them.

Over the last few years there have been a few cases of third parties building on top of a platform, only for the platform provider themselves to launch a competing product or start restricting third-party provision of interfaces; Twitter is an obvious example.

There are compelling reasons for platform providers to do this, both commercial (keeping control of revenue opportunities) and customer-focused (ensuring that the end-user experience of your platform is one you're happy with). At FP we picked up a couple of projects for very large businesses that were unhappy with third parties owning the experience of their product, and wanted to do it themselves (OK, with our help).

So I thought it might be interesting to show the impact of the Guardian launching their official Android product on the stats for the Guardian Anywhere. Here's a nice graph showing our sync traffic over the last couple of years (a sync being a device connecting in to download a copy of the newspaper; most users do this once a day):

You can clearly see our traffic peak when the official product launched, but I'm surprised the subsequent decline wasn't greater. At the time I expected us to see the majority of our traffic drop off in a few months. Of course, it looks better than it is, because we would expect traffic to grow during this period. If you consider that (and take a mid-point projection of growth, at a rate somewhere between the huge take-up May-August 2010 and the average growth over the last 2 years), then it looks like so far we've lost somewhere between a half and a third of our traffic:

So it's slow decline, rather than immediate shut-down. I wonder if this is a familiar pattern to other folks who've found themselves competing with the platform they built atop?

A couple of weeks back, I started writing about a design project I'm doing as part of my MSc coursework. In the course of thinking about what makes mobile interfaces emotionally engaging, I came up with a half-baked theory that for evolutionary reasons long, languid gestures like strokes are more emotionally satisfying than the stabbing, poking motions we often use when, say, clicking buttons on touch-screens: "stroking, not poking".

I reached out to a few friends on Facebook to see if anyone could help me find some justification for this, and had a great response. A couple of publications stand out; firstly, from The Role of Gesture Types and Spatial Feedback in Haptic Communication by Rantala et al. (which Mat Helsby pointed me at):

and

Mat also pointed me at The Handbook of Touch, which has a few choice quotes including this one:

So, here's another one of them end-of-year posts. 2011 was fun. Lots of fun: a couple of weeks travelling around Japan with Kate, furry tendencies indulged at Playgroup Festival, LoveBox and Sonar Festival followed by a few days lounging in Valencia all stand out.

Leisure-wise I did just about enough running (barely keeping a 100km/month average) but Not Enough Aikido (once a week with a trip to Edinburgh to see two old masters: Sugawara Shihan and Bryan Rieger). I slacked off a little when it came to writing, too, with just a Summer workshop with Wendy and a few trips to Flash Fiction favourite Not For The Faint Hearted. 6 or so weekends were merrily spent airsofting at UCAP Virus, before their incredible hospital site was shut for demolition in December. I also manage to get up to London to see quite a few talks this year: Sherry Turkle by herself and with Aleks Krotoski, a couple of School of Life events, Richard Dawkins presenting The Magic of Reality, Guy Kawasaki, and the incredible show that is War Horse. Oh, and Robin Dunbar came to Shoreham in February.

Work gave me a welcome excuse for travel once again: I spoke at Mobile World Congress in Barcelona, briefly at LIFT11, introduced Kirin at Mobile 2.0 Europe and had a lot of fun at UXCampEurope in Berlin and the Quantified Self event in Amsterdam. In the UK I blathered on at the Online Information Conference, Mobile Monday, UX Brighton, the Future of Mobile, Telco 2.0, and a BBC internal day for their UX & Design team. And I had an amazing weekend at OverTheAir in Bletchley Park, and got to attend a few of the expertly organised Rewired State Hack Days.

FP shipped a succession of products to be proud of this year: Davos Pulse for CNBC, the Radio 1 Big Weekend, Glastonbury Festival, AA Breakdown & Traffic, TheTicketApp and Hotels on WebOS for LastMinute.com, and the Viz Profanisaurus for Nokia devices, to name a few. Our Guardian Anywhere app for Android went past 100,000 installs and is about to shift its 5 millionth copy of the Guardian, and we open-sourced Kirin, our approach to blending web apps and native code. Just before Christmas I popped into FPHQ for a sneak peek of a few projects that'll ship early next year, and they're looking good.

And big changes in October, when I sold Future Platforms to Vexed Digital and started on a Master's at Sussex University, which I'm really enjoying. All of which brings me to what's next…

At the end of this year my involvement with FP is ending, beyond contributing to the Vexed newsletter for a little bit, and popping up in public on their behalf very occasionally. And whilst I'll be at Sussex until August/September working on my dissertation, I'm already starting to think about what I want to do next. It's going to be something like this:

• Products, not service: I've spent my whole career so far building software to order for other people. That's been great for giving me variety (I've launched over 250 products), but I'd like to be involved both before the decision to build is made, and after launch. So next time I want to be in a product company;
• Consumer-facing: I'm interested in making things for real people to use in their everyday lives. I get a little dopamine rush when I meet someone who's used things I helped ship;
• Mobile or internet: I've spent my life working in one or the other, and every day they get closer. I still find them both incredibly exciting places to be working: we've still a great deal of work to do in (un)wiring our species together;
• Working in a cross-disciplinary team: over the last 5 years I developed an interest in the overall process of Getting Stuff Launched, and I still enjoy the variety of working with a range of smart folks with different skills, backgrounds and languages: designers, developers, testers, marketers, biz dev people, whatever;
• Big jobs: Flirtomatic is probably the most-used product I've worked on, with 5 million users. I don't think it too many; in future I'd like to go bigger;
• Elsewhere; I've enviously watched a few friends heading towards StartupChile, and have a hankering to try being somewhere else for a bit.

I think 2012 is going to be fun :)

• Ben Evans on Facebook and their 300m app users: "70% of mobile users and 30% of all users used apps to access Facebook". Completely in line with the figures we heard from Simon at Comscore in a Mobile Monday talk in July: UK web traffic to Facebook was growing slowly and app traffic to Facebook much faster. Projecting forward at the time it looked like apps would overtake web in September 2011;
• Retail has problems this year, can't say I think that coupons, virtual currencies, and shopper heat maps alone will be enough to save the high street. I found this concept from PayPal beautiful though: use shop windows even when the shops are shut. Helen has a nice thread going about this over at her blog. I think we'll see some really interesting work done here over the next few years as retail is caught between technology advances and economic troubles and has to adapt;
• I hope Project Spartan launches this year. It was due to launch "in the next few weeks" back in July, then in September, and it'd be nice to have the (mostly baseless) speculation of how it's going to change everything laid to rest;
• There's lots of talk of how lack of OS updates is a flaw in the Android ecosystem, I prefer the explanation that it's down to economic incentives: once they've sold you a handset, networks or device manufacturers have no ongoing revenue from you, so find it hard to justify ongoing effort on your device. Apple aside, device manufacturers don't tend to do a great job of services which provide this kind of ongoing revenue - Ovi is the most successful I can think of - so I like the idea of end-users paying for upgrades: a few pounds for a significant update to your phone doesn't seem unreasonable to me.
• A beautiful set of criticisms of Android 4.0 UI, in ICS paper cuts. Much more constructive than the "Google don't get design!" drivel;
• The web may not prevail, a post from Nick Brisbourne building on What the web is and is not from Joe Hewitt: "even though the open web is better, it won’t necessarily prevail". I wonder how long it will take for the traditional net.infrastructure to be sidelined - not long if you believe this post: "The Classic Web is beginning to look like a kludge. Mostly because it was"
• Nice to see a couple of deeply constrained social networks pop up to handle social networks of two: Between and Cupple are both for intimate 2-person sharing. Lovely use case (though I've yet to see Between actually work), and I wonder if buddy-systems might be useful in other situations: could we usefully deploy 2-person social networks for folks trying to give up smoking, lose weight, or otherwise improve their behaviour not in public, but with the support of a friend?

Something is becoming clear as I do more work on my alarm clock design project (which had its first user test today): prototyping touch UIs that rely on more expressive motions than single touches is tricky. In particular I'm working with direct manipulation of a clock, and want to test single-finger dragging gestures around a dial, and multi-touch gestures to expand or contract the selection of a time period represented on that dial.

It's hard to do this sort of thing on paper: if a gesture like a finger-drag results in a visible change of state (e.g. "click the centre of the wheel and it turns green") then you're shuffling stationary around, which is disruptive if you're trying to see how the interface feels, or testing it with someone else.

It's also hard to do digitally. Looking around, I see people who've had success using Keynote for prototyping on tablets - it seems to offer good fidelity and be fast to work with, but lacks the level of detail I'm wanting to play with. I want to be able to fiddle with the sizes of touch areas, ratios of on-screen motion to finger movement, etc., either to see if it feels good or tweak it until it is.

I've used the iMockups product to play with putting screens together on an iPad, and quite liked it - but again, whilst it's great for chaining screens together it lacks fine-grained control. Perhaps my expectations of what flexibility and control a prototyping tool should offer are out-of-line, and I'm mixing up my fidelities - trying to hi-fi stuff with lo-fi tools.

Nicholas Zambetti's LiveView product looks brilliant for taking digital stuff from a desktop and presenting it on a mobile screen; but I'd still need something at the desktop end which eases the process of putting together touch-responsive interfaces.

Given that I'm at a bit of a dead end, I'm going to try taking a very small part of the interface, mocking it up with actual code (so it works on a real device), and seeing if I can test that. My reasoning being that if I can take the most complicated bits, prototype and test them in isolation, I can produce components which individually perform well, test the transitions in and out of them on paper, and validate the UI that way. At the back of my mind is an idea around recording input from a real user and replaying it against differently sized interaction areas, to find ideal sizes, but that'll be later I think.

Let's see…

So, today… I wrote up the sketching from last night, and would still love comments from anyone who can spare the time to look through them. In particular I'd like to hear feedback on the detail of it all.

I spent a few hours this afternoon putting together a card-and-paper model of some of the sketches; something which I can put in front of real people next week to test the ideas. I'm not sure how well this is working: maybe I just need a few more screens in there before it'll start to feel worthwhile. I'm worried that some of the interactions I have in mind (e.g. 2-finger pinches) in some spots will be quite tough to model in paper, too. Let's see.

I've also been thinking about the visibility of analogue displays (after getting a bit worried that I'd prematurely rejected the idea of a digital one), and did a little test - taking photos of analogue and digital using my camera phone, from the bedside and end of the bed. Here they are:

I can't see a bit difference in readability, myself. And I think there's more room for improvement in the analogue clock than in the digital one - in that the white circle around the clock-face distracts from the lettering, and could be made less prominent. So I'm a little bit less worried about going analogue for the UI now…

…and here's another article I've written for the ladies and gentlemen of Vexed, for their Christmas newsletter. It's a seasonally-themed piece about mobile and retail.

Feedback gratefully welcomed!

I spent a few hours yesterday playing on paper with some ideas. Having gone through the survey and looked through academic literature on alarm clocks, I've a set of basic requirements. There's nothing particularly earth-shattering here, in fact they're quite dull:

1. The product will be an alarm clock application for the iPhone;
2. Its primary purpose will be to ensure that owners get up in the mornings, at the time they want to;
   1. To support this it will help them set their alarm accurately;
   2. It will also help owners remember to set it in the first place;
   3. It will allow owners to set a repeating alarm;
3. Its secondary purpose will be to assist its owners in ensuring they get into good sleep habits: enough sleep nightly, without needing to catch up at weekends.

I've identified some principles I'd like the product to embody. I'll list these out first, then explain them in more detail with some illustrative sketches:

• "Stroking, not poking";
• Promote mindfulness, rather than dictating;
• Make use of context;
• Presume grogginess;
• Sound is 50% of UI;

I'd love to hear any feedback you have on these, the sketches below or the process; part of the reason I'm posting about this project is to try and replicate the routine of regular presentation and constructive criticism that I've read Pixar have in place. I'm doubly interested if you work day-to-day as a professional designer.

"Stroking, not poking"

Throughout lectures this term, Graham repeatedly brought us back to the idea of emotion in UI, throughout lectures this term, and I have a half-baked theory which relates this to touch user interfaces.

Nass and Reeves show in The Media Equation that "individuals' interactions with computers, televisions and new media are fundamentally social and natural, just like interactions in real life". The same gestures that we use to talk to our touch-screen devices came from our flea-picking monkey-pasts. It seems reasonable to suggest that gestures which ApeMe associates with positive things, like grooming, will engender a more positive emotional response than gestures which ApeMe associates with negative things: like poking. (How often do you poke those you love in real life?)

This is pop science at its worst, I appreciate, and I've been looking around for papers which might confirm or disprove it, without success (anyone know of any?). But in the absence of evidence, I'm going to go with it anyway and see if it works for me.

What this means is that I want the UI of the clock to use languid, flowing gestures throughout most of its use - and stabbing, pokey gestures in places where either (a) the user is feeling negative towards the clock (like, when waking up and trying to turn it off), or (b) as punctuation at the end of an activity: a kind of gestural full-stop.

So, the app uses a large clock-face as its primary UI, and a mental model of multiple clocks laid out horizontally to allow for multiple alarms. On starting the app (bottom right), the user is welcomed and asked to drag down a new clock from just off the top of the screen, at which point (top left) they can set an alarm by dragging a finger around the dial. Perhaps the rate of movement of the alarm hand would vary depending on how close to the centre of the dial their finger is - I'd need to play with that. The only poking motion is the button to turn on the alarm: so the setting-ritual is a sequence of sweeps and a final stab.

To move between clocks, the user drags the whole screen left and right (see top right), to get rid of an alarm they flick it up and off-screen, back where it came from (mid left), and to add an alarm they scroll to the right and drag a new clock down (bottom left).

There's a big assumption here: that I will be using an analogue clock face. Every mobile clock I've seen so far uses a digital display, which makes me suspicious there's something I'm missing here. I know that 76% of survey respondents keep their mobile within arms reach or closer at night, and it should be possible to create a display which is visible enough at that distance, but still…


Promote mindfulness, rather than dictating

A secondary aim of this project is to make an alarm clock which helps its owner get the right amount of sleep. I've chosen to do this in a quiet fashion: rather than, say, alerting the user when it's time to go to bed (which might play towards the "alarm clock as tyrant" analogy which surfaced in a couple of papers: Wensveen 2000 and Zimmerman 2009), providing a simple, almost-background visualisation of how much sleep they've had, as measured by the difference between the time of going to bed, and the time they get up.

I'm making the assumption I can measure the former through a combination of signals: what time the alarm is set (many being set as part of the bedtime ritual), when ambient light levels change downwards significantly (using an on-phone light sensor), and when the phone is still (using accelerometer). There may be other signals I could use too.

I've looked at a few different ways of showing your recent sleep history: I'm thinking that yesterday, last week, and last month are the time-frames to look at. The first of these will provide most motivation to fix the "just-broken" (i.e. catch up now on last night); the last two give a longer-term perspective. Good habits over a month could imply the user is in a decent routine. Good habits over a week are worth measuring because they'll provide a bridge between short term and long term measurement: they give the clock a way of rewarding its owner for a few good days.

Visualisations could be done lots of ways - from the generated silhouette-landscape of Dream (mid right) and psychedelic Rainbow (top right) to more boring Bar charts (centre) or just sticking the figures on-screen (Say, bottom left). I suspect that I'll end up going with Say or Bar for the purposes of this project: (a) because the end-result of this will be a mid-fi prototype and not much more and (b) because my graphic design skills are ropey if not non-existent.

Another point at which it's useful to show how much sleep you'll likely get is during the setting of the alarm. Different people say they need different amounts of sleep (respondents to the survey ranged between 4.5 and 10 hours) too, and having a way to configure this in a direct-manipulation fashion without a settings screen would be nice. I hate settings screens, they're a purgatory for decisions that no-one could make.

So: when setting an alarm, show a shaded area to indicate when you ought to go to bed to get your full 8 hours, or whatever (top left): even if you can't get enough today because you're setting your alarm late at night, it'll provide some impetus to sort things out tomorrow. And to say "I need less sleep than that", let the user use two fingers to drag this window smaller (top right).

Finally, after setting the alarm tell the user how much sleep they're going to get (bottom left). This has a double-function: it's an opportunity to congratulate or criticise a sleeping habit, and double-checks that the user isn't setting their alarm to PM when they meant AM, or vice versa.


Make use of context

This is a slightly woollier one: I was looking at a few different things here - mainly the Stuff Outside The Phone - and at this point I started playing with faces: clocks have faces, after all, and if we want to build a positive emotional association with a device it's easy to hate, why not make it more human?

So if it's a person not a thing, perhaps he should notice when the lights go out and visibly go to sleep (top right), or smile when you pick him up (top, middle), or be sad when he didn't manage to wake you - perhaps by being totally ignored or snoozed too many times (bottom right)?

Using a gesture to interact with the clock might be useful, particularly when 50% of the use of the clock will be when its owner is in a groggy state, prone and struggling to focus their eyes - so using the device itself to silence or snooze an alarm might be appropriate (bottom right).

I also started playing with a social idea, but I think it might have taken me towards shoehorning too much into the product. If we know when you've gone to bed, we could tell a server (top, middle). And if a server knows when lots of people have gone to sleep, it could tell all those phones (top right), which could start displaying something quiet and ambient about how many other people are sleeping right now. I think these interactions are viable because they happen when the phone is often plugged in or on home wi-fi, and we can usefully ramp down the check-in times to conserve bandwidth and batter (and don't need to check in at all if the display has been off for a while).

Would this provide any social pressure to sleep properly? Kim, Kientz, Patel and Abowd wrote a paper on BuddyClock, an experimental product they had made to share sleep-state with a limited social network and felt that "social influence on another’s own behaviour indicates that the BuddyClock could be used as a persuasive technology to help others change their negative sleep patterns".


Presume grogginess

At least half of the time an alarm clock is being used, we know that its owner is confused, prone, and half-asleep; and from the survey I can see that about half of all respondents occasionally forget to set their clock, or mis-set it. What can be done about this?

Obviously the clock face needs to be readable. The button to switch off the alarm should be very visible: in the sketches here, it's also the only button, so there's no choice of where to click. It should (as a friend just pointed out to me in email) always be in the same position, whether the phone is in landscape or portrait "mode": you pick your phone up when you're prone, and having the button move around because the phone thinks you've turned it is just frustrating. The button should draw attention to itself, screaming "me! me!". I think this is also an appropriate time to allow the user to be aggressive and stab the screen of their phone.

What else? We could make an easy snooze gesture from shaking the alarm clock - I can imagine doing this in a frustrated "go away, not now" fashion myself. We can support users in making sure they get up at the right time by telling them the first thing they have planned to do the next day - i.e. by looking in their calendar for their first appointment, and floating it on-screen (mid right). On several occasions I myself have forgotten about an appointment when planning what time I get up, and Landry, Pierce and Isbell talked about such an approach in their paper Supporting routine decision-making with a next-generation alarm clock, though didn't discuss any findings.

Finally, we need to ensure that any alarm set is set to the right time. We could do this by showing the current exact time in the middle of the clock face whilst the user manipulates it (bottom left), or by showing whether it's AM or PM visually (bottom right).


Sound is 50% of the UI.

I've not done any work on this yet, but I think sound has two roles to play:

1. Obviously in the alarm itself: what's the best kind of sound to be woken up to? What can we do to the sound to engender a sense of urgency. Personally I reckon Polynomial-C by Aphex Twin must be a good candidate for a wake-up time: dreamy and etherial for the first minute with grating synthesisers poking in, then a beat kicking off. More research needed;
2. What about in the rest of the UI? If we're personifying the alarm, should it make noises when you set it (I always rather liked the gobblegobblegobble noise that Google Voice Search used to make when it was conducting a query)? Would this help in any way?

Phew. Thanks for reading this far. I'd really appreciate any comments or feedback you have on either the thinking or the process - particularly if you work as a designer.

I also need to work out a way of getting posts like this done quicker. I'd like to do more of them, to have more opportunities for feedback… but this has taken about 90 minutes.

So, I have results in from the survey I was running into mobile usage, alarm clocks and sleeping habits. The survey was live for exactly 24 hours and received 186 responses. Here's a summary for you:

• Demographically: respondents were 75:24:1 male:female:rather not say. Average age of a respondent was 34.96 years; 80.1% were from the UK, 6.45% from the UK, and 1% or less from a large number of other countries. 79% were in full-time employment and 28% had children living with them;
• Clocks and mobiles: 98% of them use some sort of alarm clock, 76% use their mobile as this alarm clock, and 85% of them have their phone visible from their bed;
• Why they get up: 90% said for work, 17% to look after the family, 10% to get up with their partner (they could choose more than one category). Men were slightly more likely to get up for work (92.8% vs 82.22% of women), women slightly more likely to get up for their family (20% vs 15.83% of men);
• Cost of failure: only 5% of respondents said it didn’t matter if they overslept. 72% rated it a medium level of problem or worse;
• Sleep habits: he average respondent thought they needed 7.78h sleep a night and that they were getting 6.69h sleep a night. 52% are catching up on missed sleep regularly. 8% described themselves as “dog tired”, 72% at a medium level of tiredness or worse;
• When they use alarms: no respondent used an alarm clock at weekends only. 81% use one on week-days, 29% use one every day of the week. UK respondents were slightly less likely to use an alarm clock every day (27.5% vs 37.84% for respondents from outside the UK). The average time an alarm is set for is 07:04;
• Making mistakes: men are slightly more likely to forget to set an alarm (55.4% vs 46% for women), whilst women are slightly more likely to set their alarm wrongly (48.89% vs 43% of men);
• How well it works: 28.78% of men and 42.22% of women don’t tend to get up when they planned to; 71% of respondents got up a while after the alarm goes off, and 42% snooze their alarm more than once;
• Device ownership and use: 53.7% of respondents owned iPhone and 32% owned Android devices. At night 67% have their phone charging, 94% have it switched on, and 75% have it connected to their Wi-Fi at home. Men are slightly more likely to have their phone charging at night (71.94% vs 55.56% for women). iPhone owners are slightly more likely to have their device connected to their home Wi-Fi (88% vs 75% for Android owners);
• Night-time rituals: 55% of respondents set their alarm around bedtime (immediately before, during or as they go to sleep). A surprising (to me) 40% use an automated repeating alarm feature;
• Impact of children: people in households with children are slightly more likely to not get up when planned (33.33% vs 28.3%), get up a while after the alarm goes off (73.5% vs 64.15%) and snooze more than once (42% vs 39.6%) - but it’s not a significant difference.

Interesting stuff (for me, anyway!) and thanks to everyone who helped out - some of you will be hearing from me again. And my conclusions from this are:

• As expected, the mobile phone and alarm clock are natural bedfellows;
• Most people get up for work, with a sizeable minority getting up for the family;
• Given that the alarm clock is the sole tool most people use to manage their sleep, it's surprisingly ineffective: most people are tired and have catch-up routines to manage this. Most people don't get up when they wanted to (as evidenced by multiple-snoozing behaviour and a direct question on this point);
• Slightly iffy because the differences are quite slight, but in general men need help remembering to set the alarm at all, women need help setting it correctly;
• It's reasonable to presume that the alarm clock is visible from the bedside, charging, turned on, and connected to Wi-fi;
• Alarm-setting is either a bed-time ritual, or (for a surprising number of people) handled automatically by the clock itself using a repeating function;
• There aren’t significant differences in the alarm clock-related habits of people living in households with children.

So, this - and a Google Adwords campaign I'm running to measure product interest from real people - is leading me towards a product which (a) is a great alarm clock and (b) helps its owner manage their sleep better, as well as getting up in the morning.

The alarm clock is a standard feature of mobile phones, and an incredibly popular one. More people use the alarm clock of their phone daily than send text messages or browse the mobile Internet; by this measure it's the most used feature of a phone, bar making calls. And yet of all the functions in your phone, the alarm clock is one of the most staid - unaffected by advances in technology, connectivity or our behaviour.

I've been looking at the alarm clock that shipped with my Samsung Galaxy S2. It feels over-complicated to an intimidating degree: separate options for Alarm type and Alarm tone, a selection of possible snooze settings, something called "Smart Alarm" which sits there on-screen bereft of explanation, and the ability to give your alarm a name. 9 input fields, just to say "wake me up"? This can be improved.

I've been thinking for a while that there's some interesting work to be done here, so I'm using a piece of coursework for my MSc to have a look at alarm clocks, from an HCI perspective. To kick this off I'm doing some research into how real people (that's you) use their alarm clocks, and how they manage their sleep-time. So I'd be awfully grateful if you could take a few minutes (literally) to fill out this survey on the subject.

This will be a design project (rather than a research or evaluation piece): I'm going to produce at least a couple of iterations of design for an improved piece of alarm clock software. Now, I've always admired what I've read of Pixar and their process of doing daily design critiques:

What I'm working on now is a solo project which won't naturally give me many options to get feedback, and there's no need for me to communicate aspects of the design to a wider group; but I'm still interested in understanding what it feels like to work in that Pixar fashion, and how it could improve the end product.

So I'm going to post regular updates of unfinished work here and invite comment; I think my readership is small enough that I know most of you, and I think you'll have some interesting opinions. And if you've read this far, please do pop over to that survey - it'll give the work I'm doing some grounding in reality.

Update: 3:25pm on Wednesday 14th December 2011, I'm marking the survey as no longer accepting responses now, after 24 hours. Thank you *very* much to every single one of the 187 people who kindly gave up a few minutes to help with this.

One of our assignments for Human-Computer Interaction was to carry out a formal usability evaluation of a game. Unsurprisingly my group chose a mobile game, X-Construction Lite, and did a study on it: first individual evaluations using a cognitive walkthrough (AKA "having a play") and referencing Nielsen's heuristics to find and categorise specific issues.

We then did a lightweight usability study by ambushing students outside the campus library and videoing them playing the first level of the game, in exchange for cake (pear tart from Real Patisserie, if you were wondering). Interesting exercise; it's a good game that seems to have gathered nearly 70,000 reviews in the marketplace (and to which we're all now addicted), but our testing showed up some consistent and fundamental problems with the gameplay.

We've submitted a full report, but you can see the presentation we gave summarising the project on slideshare here. Credit due to other team members: Andy Keavey, Queen Atifa Ododo, Mariana Rojas-Morao and Merve Yildirim.

I can't help but direct you to a photo of one of the other groups, showing off their Plants vs Zombies review in appropriate attire.

There's a little article I wrote for the Vexed Digital newsletter, over here on their web site. It's all about Kindle Fire and what it means for the tablet ecosystem and Google; I worked it all out the other week, and it only seems fair to tell you.

Ever heard of superoptimizers? No, neither had I, until a lecture with Des Watson as part of Topics in Computer science, a module I'm taking this term.

They're comically interesting: a brute-force approach to writing software. Instead of trying to work out the most efficient way to code your program, just try all the possible combinations of instructions; I mean, how many can there be?

Well, lots, actually - and that's one of the big problems with the approach, finding ways to cut down the space of possible programs you look through. But the good news is that superoptimizers have a tendency to find bizarre, curious ways of taking advantage of specific characteristics of the hardware which humans don't tend to notice. Show a superoptimized piece of code to a human being - even, say, an architect of the processor it runs on - and she'll scratch her head and wonder how it can work.

Anyhow, I've chosen superoptimizers as the subject for my end-of-term project, so here's a literature review I've written on the topic as part of my coursework, if you're interested in finding out more.

And thanks in advance for anyone who dares point out that code *I* write looks like it's been brute-forced into existence…

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.

A last minute booking: I shall be doing a panel session at the fascinating-looking Quantified Self European Conference this weekend, in Amsterdam.

Looks to be a great event, and I've been getting steadily more interested in this stuff since this talk I researched and gave back in 2009.

The modern mobile phone is chock full of sensors: accelerometers, GPS, microphones, cameras, altimeters, barometers, temperature - and more every year. Mobiles can see lots of things we can't, and give us new senses.

Lots of approaches to augmenting our senses are visual: the cliché of Augmented Reality apps is a camera's-eye view of the world with graphics overlaid. But at the same time, we're also easily distracted visually: interfaces that demand our attention can be counterproductive in some circumstances. Sometimes this happens to amusing effect: Microsoft riffed on it nicely in some recent advertising, and I love that the Geocaching have appropriated this problem with their hobby and stuck it on a T-shirt; but the consequences of distraction when you're driving really aren't funny.

The good news is that we're quite good at listening to things without getting distracted: the cocktail party effect demonstrates our ability to pay attention without conscious effort, and we consider the radio to be a standard part of a car. Plus it's considered entirely normal to walk around a city listening to music, nowadays: you'll get a few funny looks if you're glued to a phone screen, but white headphones are more than tolerated, they're a fashion statement.

I loved the work that BERG and Timo Arnall did with light paintings and wi-fi signals, and have been wanting to play with something similar for a little while. So at OverTheAir a few of us played with generating reggae from ambient signals, including Wi-fi; but we failed to get the Rasta Far Eye (as it was dubbed, in homage to The Great Upsetter) complete in time for the demos. This was all the more frustrating for my wanting a tool like this for my own use over the weekend, as I wandered around the beautiful Bletchley site trying to find somewhere with good connectivity to park myself.

So at the Power of Minds hack day being run by Rewired State this weekend, I gave it another go - constraining myself to watching wi-fi signals only, and regretfully dropping the reggae aspect of the original. It's an Android app which can look either for any open wi-fi networks, or track a specific network, and plays loops of music which get stronger and more percussive as the strength of the network you're looking for increases... or fade out into the background as your connectivity weakens.

I'm going to have a play with it over the next few days, try using it around town or on campus, and see if it's actually useful.

I think this class of thing might be handy for in-car usage, where attention should be carefully rationed - perhaps in this case tracking GSM signal strength would be more useful. When I last drove regularly I had a few occasions when I wanted to find an area of good mobile reception to make an important phone call, and this would help.

It's also occurred to me that most of the sound that phones pump out today is designed to alert the owner across a room - i.e. to stand out, be a little bit piercing, wake you up, or annoy. Once you're designing audio for ambient consumption or headphone use, I wonder if you'll need different sorts of sound? More research needed.

A couple of entries in one for the HCI Diary, today.

First: observation exercise and surveys.

As I wrote before, we were sent out into the wild to practice our observation skills. The brief was to pick an aspect of public transport and, working in a group, plan and carry out some observations of users and run a survey to gather some quantitative data, then compare the two and present back to the class.

Our group chose to look at the stresses of public transport for those travelling with small children ages 2-8. This involved spending 40 minutes at Brighton station one evening feeling incredibly creepy whilst we identified parents entering the station with kids and followed them through making notes on their behaviour. As an observer it was tough to know how much detail to note down; I tried to get as much as possible, on the basis that it would give us more to work with when doing analysis, but found the more I was writing, the less I was observing. A definite case for pair work, or in future taking notes using something like Griffin iTalk: I could comfortably read out observations and look like I was on a phone call, I think. Alternatively, working very carefully in pairs - one observing, one noting - might help.

This we followed up with a short survey posted to Mumsnet and sent to friends with children of a relevant age.

We ended up watching 5 families in the station, and having 6 responses to our survey. It definitely felt strange and creepy to be watching people: we weren't subtle and I'm sure a couple of them noticed it. As for patterns in behaviour: families tended to use seating in the station, sit for about 10 minutes, go and stand near the departure boards for a couple of minutes, then head to their train. We're not sure why they'd stand near the departure boards before boarding - they're visible from all parts of the station.

The other consistency we noted was the excitement of young children heading through the automated gates. The older kids made a big deal of trying to wander through by themselves (demonstrating how grown-up they were, perhaps?) and there was a tendency for groups to head through the manned gate: mother and children first, father (carrying the tickets, no doubt in case they were attacked by bears) last.

We correlated some data around wait times with that from our surveys; no-one waited more than 15-30 minutes for a train, the majority of folks less than 15 minutes. And about 60% of the survey respondents found ticket machines difficult or very difficult to use (though most used them anyway).

Once again, I found it hard not to be proposing solutions to problems as I saw them. I'm not sure, but I think that one of the keys to doing good observation might be training yourself to avoid analysing: just concentrate on what's around, stay aware, note it down, and plan to think through it all later. I'm led to think about six thinking hats and mindfulness.

The second piece of observation we've done recently was around video games. Pejman showed us a sequence of 10 short video clips of games: game-screen, biometrics of the player, and a video of the player running inset. We were invited to note usability issues and prioritise them; to my mind, they broke into three categories, prioritised thusly:

1. The player wasn't in control of their "character", and couldn't work out how to be. This either manifested itself as verbalised frustration ("how do I jump?"), or as staggered or artificial in-game movements (very noticeable in FPS games). This struck me as stuff that ought to be fixed;
2. The player was controlling their character, but in an unskilled fashion: they'd drive a car into the wall by the roadside, or jump up and down in a situation where they were trying to be stealthy. Practice would help here, as might instructions, training levels, or a rethinking of controls;
3. The player couldn't work out what to do. Going through this pain seems to be the heart of many games - without challenges, what are they - and I noted that in every case we saw, the player worked it out, after some initial frustration.

There were some positives, too: players seemed delighted to notice unexpected depth in the games (the ability to shoot out tires). And there was a little pattern of delight when they got high up and could see far around them (in FPS games), which felt like it might be deeply rooted in our evolutionary history: good visibility means safety, the ability to see threats or food a long distance around. What's not to like about that?