This is WeWatch, the result of the last-but-one Rattle Hackday, where they (we as was) attempt to create something either interesting, useful, or hopefully both inside a day.
The concept is simple - it’s a stripped-down listing of what’s on the main channels tonight during the peak viewing period. If you’re signed in via Twitter you can click on a programme to show the world that you’re planning to watch it. You get the option to tweet about it with a link to the programme, and the site shows a count of how many of your friends are planning to watch the same thing.
It’s hardly groundbreaking in terms of functionality, but it’s neat - if you look how busy the Twitter backchannel for a programme like Question Time or The Apprentice gets, it’s clear that TV is still a social medium. It’s just that we’re talking about it at the same time as the broadcast, instead of the following morning around the coffee machine. The simplicity is partly by design, and partly by constraint - the BBC data is readily available, but other channels make it more difficult (and expensive) to get hold of.
With this simple an interface, and this limited a set of interactions, it’s clearly crying out for a mobile - i.e. iPhone - version. And that’s what this is (or what’s going to become).
The most interesting thing for me about designing the iPhone app is that you’re starting from a completely different place in terms of the interaction. The browser is a very linear place, and the interaction is one step removed. You click with a mouse, which is an indirect action. On the iPhone, on the other hand, the interaction is direct and far more visceral. You touch, and drag, and swipe. If a browser is eating peas with a knife and fork, then the iPhone is picking up the chicken leg in your hands and gnawing on it. Far more satisfying.
This is where I’ve got to so far in terms of the “interaction design” - a rather grand term for some rough sketches, but hey. There’s a single screen view of the timeline, with the programmes scrolling horizontally. The width is fixed so that if there are more than two programmes in a time slot, the third is hidden by the screen edge - which is hopefully a subtle call to action to try swiping across to reveal the hidden elements.
Tapping on a programme switches to a single view with the detail, and a large “Watch” button at the bottom as the primary call to action. That will also contain the number of fellow watchees - there’s some implied Twitter sign-in functionality behind this, but I’ve deliberately ignored that at the moment to keep things simple to start with.
Tapping the “Watch” button causes another modal view to appear with the pre-completed tweet, and the option to send the tweet or cancel back to the previous view.
The main view caused quite a lot of discussion - whether it should scroll vertically as well as horizontally, how much information should be disclosed in the programme “icons”, whether the detail should be held in a new view or presented modally. I don’t think there are any “right” or “wrong” answers here, but I’ve been surprised by how many options are exposed simply by sketching the interface life-size, and interacting with the pencil and paper version.
And then there’s other, added functionality that a browser-based interface can’t offer. It’s fairly obvious that offering a reminder - “that programme’s on in 5 minutes” is an obvious one for a mobile device. And once you’re watching the programme, giving you direct access to the hashtag discussion on Twitter seems like a natural thing to do.
Those are things for the next-but-one-iteration - at the moment, I’m concentrating on getting the interface built (and as “right” as possible, whatever “right” means in this context. That’ll use dummy data, which means the step after this will be to tweak the WeWatch site and the app to provide and ingest a JSON feed of the programme data. Then should come Twitter integration. It seems like a logical process, but there’s sure to be a few rabbit holes to disappear down along the way.