Back in December of last year, I did an HCI project around designing an alarm clock. I wrote about it a little bit here, and - in an attempt to duplicate a design-crit process I've seen elsewhere - solicited some really helpful feedback from some of the readers of this blog.

For one reason or another the project took a little while to get marked, but we had it handed back this week. It's unlikely to be of interest to anyone, but given that quite a few of you helped, I've put the report (all 50mb of it!) here. It's been given a provisional mark of 83%: not shabby, but not amazing either.

Overall, I felt a bit "meh" about what I'd produced, for a few reasons:

1. It didn't really conclude with what I felt was much of a design. I'd tested a few ideas but with 3 test subjects, didn't feel I drew many conclusions;

2. As noted in the report itself, I didn't get much value from doing a mid-fi prototype (which was mandated as part of the project). I think I would've done better to explore more ideas as lo-fi sketches, and move to hi-fidelity when getting them onto a real device. I felt that some issues test participants observed could be explained by the deceptive fidelity of the prototype;

3. I referenced, but didn't feel I ever tested, "stroking not poking" (Warning: "bad workman" ahead). Throughout the project I struggled to find tools which would let me prototype the fine-grained touch interactions (e.g. drag a hand around a clock) on a real mobile device. At the time I presumed that they exist somewhere but are proprietary. Since then I've heard rumour that even within Apple, iOS app prototyping is done with Keynote. I evaluated Keynote and found it wanting - so I missed a trick there, I think;

4. I think I'd made my life harder for myself by doing some research up-front in the form of a survey (reasoning that I know nothing about sleep habits, and ought to). There was a 2500 word limit for the project, and reporting the survey ate into this. One very reasonable criticism from the marker's feedback was that I could've gone into more detail on the literature; I'd originally written much more, but cut it down for the final version. A lesson learned: this project was supposed to be either research or design; I shouldn't have tried to do both.
   

Some good stuff did come out, though: I was surprised to observe that analogue clock-faces are easier to read from a distance, compared to digital displays. The survey validated my original suspicion that the high-cost-of-failure associated with oversleeping, combined with the high frequency of oversleeping, indicates there's a worthwhile problem to be solved here. And in future I would use the combination of "Omnigraffle exporting to HTML" and LiveView to quickly test UIs which needed fewer unusual touch interactions.

Thanks to everyone who lent a hand - the 186 people who filled out my survey, and everyone who commented on the blog or sent me emails. In particular Nick Richards and Dave Whiteland were awesomely helpful :)

We're heading into the last few weeks of term, and project deadlines are looming. Well, not quite looming (this term's projects for postgraduates all have to be handed in during the first week of next term), but I'm off to San Francisco with Kate for a couple of weeks of holiday over Easter, and I want to get as much as I can out of the way before then.

They are:

1. An Enterprise Java Beans app for Web Applications and Services; pretty dull stuff; I've never really done any larger-scale EJB before and there's not a lot of room for going off-piste in this project, it's a set thing we just have to make;
2. For Pervasive Computing, I'm planning to build on the work I was doing with morse code transmission over LEDs and light sensors, and do an exploration of how to optimise the performance of said transmission without getting into error-correcting codes or statistical language models: just sticking to the hardware and sensor properties, and seeing what can be done at a low level. This'll be fun, because I'm pretty ignorant about hardware;
3. Adaptive Systems is the real doozy: I'm looking at the "information ecosystem" which Bret Victor describes in his lovely Magic Ink paper. It's a structure he proposes for having software react to the end-user's context: different applications propose topics of interest to a platform which offers these topics to content providers (e.g. a restaurant recommender), filters the responses, and uses them to inform graphic design. So, if you were emailing a friend about pizza and switch to your maps app, you might find pizza restaurants to be subtly highlighted. The nice thing about this architecture is that it allows for a range of content providers or applications to plug into it, without knowing anything about one another. I couldn't find anyone who's done anything along these lines, and Bret doesn't know either… so it felt worth playing with.

   To fit within the remit of an Adaptive Systems project, I'm going to model the feedback mechanisms between the maps app, platform, and topic providers: the system should learn over time, building an understanding of what an individual user finds useful or useless, by taking into account what they click on, what they ignore, and what they express active disinterest in. Oh, and after 3 years of promising myself I'd learn functional programming, I'm finally getting stuck into Clojure, which I'm using for this project.
   

I also have a suspicion that I'm going to return to superoptimisation for my dissertation project next term. Every 5 or so years someone seems to wander across the topic and build a new superoptimiser for a specific hardware architecture, which is then obsolete within a few years. I'm thinking of building one for the Java virtual machine: something that could be open-sourced for other people to work on in future (to add fitness functions, better equivalence testing, better strategies for cutting down the search space), as well as being useful today.

I haven't gone much further than that with a plan; I'd likely start out optimising pure static functions only, possible just those with primitives for input and output. I'm thinking that Clojure might be a good choice for this project: it'd let me load generated byte code in-process, parallelises nicely (handy when it comes to testing large numbers of candidate byte code sequences) and a functional language could be handy for managing equivalence tests.

I'm still talking to a couple of folks about other possible projects, but that's looking likeliest right now; and so I've borrowed a hefty tome on the JVM which I'll be padding through over the next few weeks.

Over the last few months I've been swapping between three mobiles: an iPhone 4, Samsung Galaxy S2, and Nokia Lumia. I've grown fond of each of them; like strangely ugly children, they are all special and I love them equally.

Two observations from all this:

1. Moving between phones gets easier and easier. My email and calendaring is all through Google, and the synchronisation with all three platforms works well. The other app I use frequently, Kindle, is also solid everywhere. I could get 80% of my stuff on any of these phones, within minutes;

2. It's apps which tempt me to stay with a given platform. The big win of iOS for me is Omnifocus, which syncs beautifully between phone, iPad and desktop, and just isn't available for WP7 or Android. I found myself installing fewer third-party apps on WP7 than other platforms. Many of those available in the marketplace were pretty poor, but the platform itself had decent Facebook and Twitter integration, and I found myself using the (reasonable) browser for things like Google+;

3. Whilst the choice of apps of iPhone blows everything else away , there's something unpleasantly disjointed about moving between them. Maybe it's the zoom-in animations when launching an app, but every time I launch one I feel like I'm giving a particular product my full and exclusive attention, and must readjust myself to the whims of its particular interface. It's like each app is a little box of functionality, and I choose to move into and out of them in turn. This is most obvious when launching a site in Safari: I feel like I'm dropping whatever I was doing and trudging over to the web.

   In contrast, both WP7 and Android give the impression of moving between apps in a much more flowing fashion. In the case of WP7, maybe it's the left-to-right panning used across the OS: there's no animation indicating that "something else is starting now". In the case of Android, I suspect this is down to the componentisation that comes from breaking applications into Activities: you're not using an app so much as "doing something" (e.g. taking a photo). There are issues with this that annoy me, and I don't think that the design (in Gingerbread) delivers on the promise of this underlying structure. I'm still waiting for Samsung to mess up Ice Cream Sandwich for me; maybe once I have it, this is something I'll find is fixed or improved.
   

We have the same thing on the web: millions of discrete experiences that we dip into and out of, often with their own navigation, identity/authentication, and so on. And we've had industries like online payments spring up to provide consistency where it's most needed. But why should I have to manage a separate shopping basket for every shop I go to? Hmm...

The Lumia, btw, is a lovely piece of industrial design; the weighting and materials are perfect: extremely classy without aping the iPhone. It also gets some small things totally right: so brutalised am I by every other camera phone I've owned, I've still not managed to adjust to a world where I can take photos without unlocking the screen.

From an industry perspective, the other nice thing about the Lumia is that it's a great product from a partnership of separate hardware and software companies: a nice reference for anyone who takes the view that you don't need to own the whole stack to make a great product.

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.

A couple of weeks back I posted about how we might design for systems which we can't understand the inner workings of.

I ended up chatting about this to a neighbour over fondue at LIFT last week, and in the course of this it occurred to me that this isn't just a design problem, it's also a societal one.

The analogy I came up with (which my neighbour felt was a poor one, it has to be said) was the car: if you'd shown a car to someone in medieval times, they might have found the absence of a horse pulling it to be deeply disturbing. In much the same way, we expect to be able to understand what happens inside the software which we spend ever-larger chunks of our lives conversing with.

So if we fear technologies we don't or can't understand, we need to find ways to move beyond this fear.

If you're interested in this, Ben Bashford did a nice talk which is worth checking out.