Archive

Nokia

I’ve got a big old post almost done on the project, but Tom has procrastinated slightly less and beaten me to it – writing about a prototype that Future Platforms built for me early in the year.

“We all like to play; whether we’re trainspotters, online gamers, old or young, we all take pleasure from playfulness. It can be solo activity, a social exercise, investigative, educational or just plain fun. In a mobile context, play is usually associated with simple downloadable arcade games – but this needn’t be the whole story.

So we built a mobile toy for Nokia, called Twitchr.”

Don’t know if Tom is going to talk about it tomorrow at MoMoLondon, as I think his talk will be concentrating on Flirtomatic. If you’re going to MoMoLo – see you there I hope.

» Tom Hume.org: Selling New Mobile Phone Features

The new version of Python for s60 is available, and looks to have a metric shed-load of interesting new capabilities:

The new version includes support for the following new features:

* 2D Graphics, Images, and Full-screen applications
* Camera and Screenshot API
* Contacts and Calendar API
* Sound recording and playback
* Access to System info, such as IMEI number, disk space, free memory, etc.
* Rich text display (fonts, colors, styles)
* Support for Scalable UI
* Expanded key events
* Telephone dialing
* ZIP module

Version 1.2 continues to include features from the 1.0 release, such as:

* Networking support for GPRS and Bluetooth
* On-device and remote Python console
* Support for native GUI widgets
* SMS sending
* Application build tool for packaging stand-alone application installers
* Compatible with all Series 60 1st and 2nd Edition devices

Aside from being able to make nice UIs with it – now that you can make stand-alone application installers, hopefully we’ll see a lot more innovation on s60 using this.

.flickr-photo { border: solid 2px #000000; }
.flickr-yourcomment { }
.flickr-frame { text-align: left; padding: 3px; }
.flickr-caption { font-size: 0.8em; margin-top: 0px; }



"Napkin Sketch" Nokia ad, originally uploaded by blackbeltjones.

Pleasantly surprised by these new adverts of ours.

Gone are the cheesy grinning yoof models gleefully living the ‘mobile lifestyle’, and instead we have a languidly expressive line sketching the form of the new phone.

It’s the archetypal ‘back of the envelope’ sketch that captures the essence of the design, communicates it to another with casual power.

I like that the ad is not covered with ‘features’, ‘benefits’, acronyms or tech specs either. It’s confident enough to say the clear, simple design of this object will sell it to you, or not.

The fact that this can now be the primary image in the advert also shows the iconic status of the clamshell as the shape of mobile telephony in the popular mind.

Which is going to be an interesting challenge for all the mobile device manufacturers when they want to innovate beyond that – not just Nokia.


p.s. I hate those pompous “disclosure” lines that people use when writing about companies they work for, but as you may know, I work for Nokia, and usually I hate their adverts, so was prompted to write this, the views here stated may not be those of my employers, yadda, yadda.

.flickr-photo { border: solid 2px #000000; }
.flickr-yourcomment { }
.flickr-frame { text-align: left; padding: 3px; }
.flickr-caption { font-size: 0.8em; margin-top: 0px; }

Jan Chipchase, a colleague of mine in user-research at Nokia has started a new blog called ‘Future Perfect’, wherein he posts snippets of his experiences travelling the globe studying the use of technology.

Jan has a great eye for the unexpected detail in the everyday, which makes him fantastic to work with as a designer, and will be fabulous to read has his blog develops.

From this post on the culture of mobile phone repair shops in India (where he took the excellent photo above):

“a lot of the hyperbole surrounding western hacker culture makes me smile compared to what these guys are doing day in day out.”

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.