Chris Harrison, Dan Morris and Desney Tan, of Microsoft Research have come up with Skinput, a bio-accoustic sensing technology that allows the human skin to act as an input device.

Still in early prototype, an armband detects the subtle differences in sound frequencies caused when tapping various parts of your body to locate the impact, making it possible to determine which button was pressed.

Wireless Bluetooth technology is then used to transmit this data to other devices, such as iPods, mobile phones and the like to be actioned.

Absolute genius!

This move will open new doors to a generation of Flash developers whose skills have been rendered all but irrelevant in today’s CSS-driven Web 2.0 marketplace. Okay, so this could be good or bad; the Flash website was killed by poor user-experience design and amateurish implementation long before Nielsen ever got his claws into it. There’s something about a looks-identical-in-all-browsers development tool that draws lazy designers like flies to a steaming turd.

But underlying all of this is a deep, thunderous rumble than gnaws at my bowels like a dark tumor. Adobe.

My own experience of Adobe is one of mind-boggling frustration; from their utterly atrocious customer service to their buggy, bloated software. Adobe has helped me earn a good living, I have to admit that much. But they’ve made me pay for it – in more ways than one!

This has the potential to be a ground-breaking milestone in mobile development, and exactly the kind of unification this platform has desperately needed. But only if it’s done properly.

And therein lies my greatest fear. The words “Adobe” and “done properly” rarely, if ever, belong in the same sentence.

All of these things are now easily measurable, and UX designers are just as accountable for their design decisions as any conventional architect or engineer. Design is no longer shrouded in mystery. It is no longer a black art, understood only by the sacred few. Everything I do, I do for a reason, and my design decisions are based on a careful balance of knowledge, experience, fact and a little educated assumption.

On the other hand, what makes me attractive to my potential clients is something very different. Most people require effective design in order to deliver a ROI that justifies the risk, but what they desire is something better; something different. Something innovative.

And herein lies the conflict. To design something that consumers can use so easily that it feels natural to them, removing any barriers to conversion or engagement, means engineering something that is inherently easy to use; something intuitive. Jeff Raskin defined the word beautifully in his (still valid) 1994 paper Intuitive Equals Familiar:

"Intuitive = uses readily transferred, existing skills."

For those who can’t be bothered to read the whole paper (and I recommend you make the effort), Raskin defines intuitive as the ability to use an interface without having to learn anything new. Familiarity creates intuition, enabling an end-user to immediately adopt an interface without further research or training. But innovation, by its very definition, demands the creation of something new and experimental. If that’s the case, how on Earth do we innovate in intuitive user experience design? How do we create an interface that is both unconventional and familiar, all at the same time?

When put like that, it sounds like an impossible task, and I’m sure there are many UX designers who are happy to hide behind this conflict, as a source of justification for remaining within their comfort zone. But you only have to look at some of the big innovators in technology today to see how this can be achieved.

Until recently, the conventional means of utilising mobile phone software was via a keypad and joystick of some description. This was the case for almost a decade (it may be longer – mobile historians, please correct me) until Apple released the iPhone in 2007, changing the face of interaction design forever. With the iPhone, Apple had created a truly ground-breaking user interface, whilst making it more intuitive than ever before, by rejecting current mobile conventions, and instead mimicking the way we interact with real-life objects.

We naturally prod things, we pinch and squeeze them, and slide them around to reposition. We don’t naturally do these things via a proxy, such as a mouse, joystick or keyboard. These input devices are relatively new to our consciousness, and have been adapted-to over a long period of time. Multi-touch technology has allowed us to revert to a more direct interaction with the objects we see on screen, effectively removing technology (psychologically, at least) from the equation altogether, and putting the power back into our fingertips where it belongs.

So what can we learn from the iPhone? The lesson I take from this is that in order to innovate in the field of user experience, without sacrificing effectiveness through lack of intuition, we must first look at how our current understanding of the world has been constructed. Only when we can separate truly intuitive behaviour from acquired constructs, can we begin to design interactive solutions that revolve around what makes us human. And with the almost sci-fi advances in 3D tactile touchscreen and voice recognition technologies over the last few years, we’re coming closer than ever to that eutopia.

At Moko Digital we currently use XHTML 1.0 Strict as our bread and butter markup of choice, mainly due to its rigorous validation. But let’s face it, it’s been the only stable, predictable and extensible option in standards based development for a long time now.

The fact that even simple syntax errors will prevent an XML document from rendering fully encourages our web developers to code more diligently, but then enforced attention to detail can’t be the only benefit of XHTML over HTML. While HTML5 doesn’t discourage poor markup, it certainly doesn’t encourage it either; without a DTD to validate against, it’s rules are merely implied. In fact, we recently switched back to XHTML 1.0 from 1.1 because the validation was simply too strict; The page was parsed as XML, and the errors thrown at every un-encoded ampersand proved to be a monumental pain in the arse.

I’ve worked with a lot of web developers in my time, and I’ll bet the vast majority of them don’t consider the markup they use, and simply put into practice whatever .net magazine tells them to. The doctype is given to them by Dreamweaver, or whatever WYSIWYG editor they happen to be using, and they’re content to go with the flow. At Moko Digital however, we need to be a little more careful. We’re already making use of HTML5 in our administration interfaces where Javascript is a basic requirement, but lack of support in older browsers, such as IE6 means that we can’t confidently use it for the public-facing user interface where Javascript cannot be relied upon to bring IE6 up to date.

So the news that XHTML2 was to be abandoned in favour of HTML5 caused me to think hard about what this meant for us. What kind of effect would it have on how we build our web applications? These issues are important for us to confront, since the applications we build are key to our clients’ abilities to earn money from the web. This might not be so important to a brochure-ware shop, but to Moko Digital, the decisions we make directly affect the bottom lines of our clients.

HTML was originally conceived as a way to represent the structure of a scientific document in plain text. It was never intended as a method to describe the presentation of that document; something that Tim Berners-Lee hadn’t anticipated back in 1990. It wasn’t until Mosaic (the first web browser with a GUI) arrived on the scene that developers really got stuck into the presentation layer with the addition of images.

Over the years, HTML has evolved. And I mean evolved; all evolution is torturously slow, and leaves an indelible trail of omissions and oversights in its wake. It has attempted to roll our visual constructs (such as header, sidebar, footer) etc into our semantic constructs (Headings, Paragraphs etc) to make a pseudo-semantic mark-up language tied inextricably to the presentation layer. And this is what I always liked about XHTML.

XHTML sought to abstract all presentation logic to cascading style sheets where it rightfully belongs, leaving XHTML to capitalise on its most distinguishing component (its eXtensibility). And herein lies my core reservation with HTML5.

The W3C committed “to realise the full potential of the web, by ensuring long-term growth”, and yet HTML5 seeks to provide code that satisfies the needs of web developers today. Whilst this doesn’t prevent long-term growth, it does nothing to encourage it either; Look back at the decade since HTML 4.01 reached the candidate recommendation stage and see how much the web has changed. It’s difficult to imagine that by the time HTML5 reaches candidate recommendation (not scheduled until 2022) it will be anywhere close to the requirements of our next generation of standards-centric web developers.

At first glance, many of the new elements in HTML5 made perfect sense; Every site has some kind of navigation, right? The trouble is, the structure of an ‘average’ web page develops as quickly as the technology that renders it. Locking our vocabulary down to words like ‘aside’ and ‘article’ is not extensible, and makes the assumption that everything we’re doing on the web right now is the way it should be. Imagine if this specification had been drafted in 2002; would there have been a <flashintro>tag?

This may be purely down to personality, but I appreciate the freedom and extensibility XHTML affords. The ability to define my own semantic vocabulary using ‘class’ and ‘role’ attributes, that is fit for both my audience and my developers alike, is far more attractive than being forced to adapt to someone else’s idea of semantic meaning. That’s until we consider search engines and assistive technologies.

Anyone who witnessed Robin Christopherson’s eye-opening demonstration of screen reader technology at FOWD earlier this year will understand what an important part standards play in helping those who have disabilities. A single, standard vocabulary would enable screen readers to better understand and communicate not only the structure, but also the meaning of the page.

So how do we separate vocabulary that makes my life easier, from standard vocabulary that makes life easier for those using assistive technologies? In my opinion, the role attribute seems to be the answer. On the one hand, it supports a standard vocabulary; a set of default values recognised and understood by any compliant client or device, solving the issue of assistive technologies and search engines taking content out of context. On the other hand, developers are free to define their own custom vocabulary within their own namespaces, allowing for fringe-case applications and providing the extensibility that XHTML2 implies.

All in all, I don’t lay awake at night worrying that the sky will fall in due to the demise of XHTML2. XHTML 1.0 will continue to be the only real stable choice when it comes to consumer-facing presentation layers for some time to come. That said, there were some components of the specification that really tickled me, such as the XML Events module.

The ability to define and handle custom events really would have gone some way to fulfilling the W3C’s promise to ensure long-term growth, especially considering the number of new web-enabled gadgets and input devices cropping up; Gesture-based design for iPhone and other touch-screen devices means that the days of mouse-only interaction are well and truly over.

So the conclusion I came to, rather undramatically, is to forgo the temptation to mourn the demise of XHTML2, and embrace HTML5 for what it is and what it could be. It just means that we, as a developer community, have to be so much more tenacious in our attempts to sway the recommended specification towards something that resembles the W3C’s original pledge, whilst taking into account the needs of those who depend on it.

And given that we have a little over 12 years to do it, I don’t feel under any immediate pressure.

I recently had the opportunity to design an EPG interface for a television set-top box. To me this was an interesting departure from my day to day work in e-commerce, social media and application design; a chance to look at the world from a different perspective.

When the design was complete, the technical director of the project seemed genuinely surprised that I had understood and adapted to the peculiarities of the EPG, and had designed a user interface that was both intuitive and technically correct. Not bad for a web designer.

He’d worked with many web designers in the past who had  attempted to translate their UI design principals to the television screen, and had failed miserably; Delivering a web experience that was neither practical nor technically possible on a television.

The World Wide Web is just one medium that I work with, and I am particularly good at it. But design, for me, is universal. It is about finding a balance between something over which you have no control, and something over which you have no limitation.

On one side you have the immovable truth: The problem, the business objective, the strategy – whatever it happens to be. On the other, you have possibility – a blank canvas. What you put into this space, in order to answer, solve or fulfill the immovable truth, is Design.

Televisions and EPGs have some immovable truths:

• They are generally navigated with a remote control, using directional arrows
• They don’t have a cursor
• Anamorphic HD will be squeezed into a Standard Definition screen, losing resolution
• There are ’safe areas’ to observe, in order to avoid having your interface cropped
• Televisions don’t handle certain colours particularly well

Some might see these as obstacles, but I see them as truths; Neither negative or positive. It’s just the way things are, and I have to work around them. I have to design an intuitive and engaging user interface around these truths.

I avoided problematic colours in situations where they might bleed. I used fonts and type-sizes that would shrink gracefully and still be legible when reduced to Standard Definition. I created a grid that respected the ’safe areas’ and didn’t put anything important close to the edges. I included ‘on focus’ styling so that the user could see which button they were on, without relying on a mouse-cursor to tell them.

In my world, Design is about solving problems and answering questions. Good Design is about solving problems in new and interesting ways. Great Design is about taking those fundamental principals and applying them to any given problem, regardless of the discipline or medium.

At first, I thought it was a web developer’s responsibility. Afterall, it’s a scripting language, right? It involves writing code in order to extend a webpage with some kind of logical intelligence. A web designer, on the other hand uses markup; an instructional language describing the contents of a page to a web browser, with no inherent perception or decision-making capabilities (beyond attribute-selectors in CSS). This seems to make sense, but there is another way of looking at it.

In Defining Web Design 2.0, I looked at the myriad roles of the new breed of web designer, one of which was that of Interaction Design. As Javascript matures – or should I say the application of Javascript matures – it’s becoming more an integral part of an Interaction Designer’s usability toolkit. Whether it’s providing client-side form validation or visual feedback for a subtle AJAX call, Javascript is very much a part of the User Experience.

Unlike server-side languages such as PHP or Ruby, the quality and application of Javascript code has a direct effect on a user’s experience. And I believe it’s this subtle qualitative aspect of Javascript that separates it from the rest of a web developer’s toolkit.

I know a few designers who would go as white as a sheet, faced with the prospect of owning Javascript development, but I believe that if a designer is to create inspired user experiences, they should have a thorough understanding of the tools at their disposal, including Javascript.

Driving a car was always going to be a necessary evil. I had tried it when I was 17 and hated every minute of it. So it came as a huge surprise when I took to it like a duck to water in January this year. Within a month I had passed my test and was ripping up tarmac like nobody’s business.

But being a biker, I’m constantly frustrated at the lack of acceleration in smaller cars, and began to wonder what kind of supercar I’d need to experience the same rush I get every time I fire up my trusty v-twin. And then I found it, in the form of the Dax Rush V8.

Based on the classic Lotus Super 7, a properly equipped and tuned Rush will hit 0-60 in 3.5 seconds, with the wind in your face and your arse 4 inches off the ground. And the best bit? No helmet or hot, creaky leathers!

So I’m in conflict. Iron horse vs. classic racing car?

One More Day [director]

Based on a comic strip by Nicholas Gurewitch, One More Day was my fourth attempt at directing, and despite being a comedy, was the perfect opportunity for me to work on my straight drama.

Starring young Mitchell Smith, the film was shot over a period of two days on a budget of less than £500, which is pretty astounding given the quality of the finished product. Most of the budget went on set design and the various visual effects that really make the difference, thanks mostly to the talents of Emma Dalesman (Camera) and Mark Danbury (Art Director).

One More Day was produced by Michael Pentney.

The Last Temptation of Jeff [director]

Written, shot and edited (including original musical score) in only a weekend as part of the 48hr Film Challenge, The Last Temptation of Jeff was a pretty accomplished filum, all things considered!

We had prepared, with the help of www.saxonviolence.co.uk a van full of anglo-saxon costumes and weaponry, so whatever theme we were given was going to be a period piece! All the dialogue was ad-libbed by the immensely talented Colin Cuthbert (Jeff) and the late Iain Etchells (Tarquin) and the score was written and performed at 3am by Dave the Happy Singer.

I don’t have the space to ooze about the level of talent on the set that weekend, but it’s all there to see – just about everyone made it into the filum, even me!

Death & Mrs Brady [writer/director]

This was my graduation filum, shot on 16mm film and earned me my First. I wrote and directed it, with Ellie Land producing and Emma Dalesman as DoP.

I knew that once I had graduated, it wouldn’t be quite so easy to experiment, so I wrote a script that contained all of the cool stuff I’d seen in making-of documentaries – stunt work, fight sequences, make-up, visual effects, costume design and set-building.

It was fantastic fun, and a proper baptism by fire for an inexperienced director!!