Quite a long post this, and it might state an awful lot of obvious things, but that’s the reason I have this place – if I state the obvious to myself it helps me think what’s next – sometimes. So bear with me while I walk you through one of this weeks personal ‘a-ha’ moments

Yesterday, had the final presentation from Fjord, who’ve been working on a prototype for us. The proto looked good and did the job, but the real eye-opener for me was when Olof and Jonathan, both part of the Fjord team (along with Celia), went through what they had learned from trying to push the capabilities of Flash Lite in producing the demo.

It’s early in Flash Lite’s life, and it obviously has vast potential for creating very compelling services and user-interfaces on mobile devices, but it needs to mature a little first. I’m not going to speculate here on what it’s future potential as a content or experience platform for mobile might be, however, I think it is safe to say it is already a really game-changing tool for rapidly prototyping mobile user-experiences, for a few reasons I can think of:

Freed from functional specs (alone)
As Jason Fried says ‘there’s nothing functional about a functional spec’ – often with designing mobile user-experiences, the functional spec is the key boundary object shared between the designers, the developers, the engineers and the marketers. It’s often unfortunately a lousy, stodgy way to work – with the spec being something that one imagines might be definitive, but in fact too often allows for ‘creative reinterpretation’ and compromise, whilst at the same time managing to be constricting and inertia-inducing.

Having an interaction design rapidly prototyped in Flash Lite as an additional boundary object means that everyone in the team will grok the user-experience you’re trying to create and the benefits you’re trying to provide. And not only grok it, but if you’ve done a good job – be excited about it, hopefully.

The relative cost of creating a series of Flash Lite protos to do this within a development team is tiny when balanced against the disaster of finding out too late that the specs, wireframes or whatever else have been misintepreted.

Design, test, redesign, test, redesign again etc
Obviously the reason it’s a disaster is that coding is costly in terms of skilled people’s time. I’ll continue stating the obvious by saying coding is damn hard.

I can’t do much beyond

10 "foe is cool"
20 goto 10

And I have tons of respect for people who can. Unfortunately, their time is often best spent, well, coding – at least in the eyes of those who employ them to deliver solid software for mobile devices on time.

This doesn’t leave a lot of their time free to collaboratively ‘sketch’ in software the sorts of disposable prototypes necessary to iterate and test a service effectively and quickly – as perhaps those involved in developing “web2.0” services are becoming used to. Also, in my experience, once stuff turns into code, it has a tendency in any organisation to start to calcify into a finished thing.

Often, paper prototypes or other abstractions can be used to push the experience design along before committing to code – but having a tool like Flash Lite means that you can get to a more concrete, less abstract test of the experience, without spending too much time.

If you don’t polish the visual aspects, keeping it at a ‘wireframe’-like level of detail – then you almost have an ‘animatic’ of the experience that you can put in the hands of a prospective end-user; which also you can quickly pull apart, reconfigure and test again. This should result in iterative improvements to the design which you can then take to the next level – coding.

It’s different when it’s in your hand
Which is the rather innuendo-laden point underlying both of those above. While both paper-prototypes of web/laptop/pc based software or services can give good results in testing and wireframes/screen-flows can make for a good abstract of a user-experience to build to – I think for mobile services they fall down as a measure of the experience.

The handset is – just that – a hand-bourne device that projects into your world, and the service you are designing with it, rather than the experience of even say a 12″ laptop, where you project yourself through the proscenium of the screeninto that user-illusion.

The interactions with the device, the UI and the service are both embodied and situated – whether it’s the embodied muscle memory one employs while thumbing frequently used commands on the device, the socially situated context of use of mobile devices or the plain fact that they are most often used while multitasking one’s way through a visually and aurally distracting world. These factors have a profound effect on our interactions with the device interface – in other words – it’s different when it’s in your hands.

Having a Flash Lite animatic on the device itself makes for a remarkably different evaluation of a candidate design by users and sponsors than the equivalent wireframes or even a flash mockup on a pc screen; and as described previously, the meagre bucks that are spent getting that bang are well worth it.

There are some beefs with Flash Lite that Olof and Jonathan pointed out – it chokes sometimes when doing complicated things, if you want to simulate an even slightly complex app then you have to do some scripting gymnastics tomaintain things like state across the movie and the text handling from the device keyboard is less than optimal.

I’m sure that Macromedia/Adobe will straighten this out in subsequent releases for s60.

I think it will be worth trying a simularly process with the newly-extended Python for s60 to understand it’s strengths and weaknesses for ‘sketching software’ for mobile devices.

Python might be suited to a ‘second-round’ level of design iteration, where you start to flesh out experience more and geet closer to a finished design for final development.

Of course, using a scripting language, even a high-level one like Python takes us back to the problem of coder time and attention that I mentioned above.

As Russell Beattie has pointed out – the experience of the mobile web is lagging that of the tethered significantly for many reasons – but I strongly believe from what I’ve learnt from Fjord and this project that Flash Lite is one of the promising tools for prototyping our way forward, at least on the user-experience side.