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.
0 thoughts on “Prototyping mobile applications with Flash Lite”
Well, coder time has the same scarcity as designer time. Functional specs were meant to make it possible to design once and code once. Techniques such as Agile or XP mean that the code is constantly usable and constantly changable – but that requires discipline and saavy from the designers, coders and clients. The trouble with doing this on mobile is (as you point out) all the constraints and hamfistedness needed to get things to do what you want to do. This domain requires quite a lot of prep work. I’d venture that there are more people that could pick up Python and do a good job of it on s60 than Flash Lite.
I agree, flash generally provides an excellent way of rapidly prototyping UIs.
I think I heard that the new version of Flash Lite is to be based on the Flash 7 player (currently iI believe t’s based on the 5 year old Flash 4 player) which supports action script 2.0, this is a massive leap forward in terms of Flash’s ability to do complicated things and will hopefuly cut out most of the scripting gymnasitcs required by earlier versions of the language.
i’ve only been banging on about this for about a year now…
where did you hear about the next player tom? (just out of interest…)
Actually in japan most of the new phones use Flash for the FINAL UI. eg the OEMs do their whole UI in flash and just rely on its ability to “launch” the various applications (camera, phonebook, mailer etc).
This means the UIs here are more than the PDA+ we find everywhere else – the OEMs really care about the style, hiring designers to do a one-stop hardware + software look + feel. (google for “marc newson +talby” ).
some of the first couple of phones actually didnt lock down this ability, so ppl in japan were making their own phone UIs in flash. of course, the Mac finder was one of the most popular… ( Fiora toolkit even came out to make this easier http://auicon.freeownhost.com/pc/tools/fiora/tutori13.html )
Pete — search term “actionscript deuce” pulls up early guidance on the next generation of the FlashLite engine.