Apple might eventually have to cave if Flash becomes a standard feature of all other smartphones.

AIR For Android, And Adobe’s Plan To Deliver Apps Across All Mobile Devices.

We’ll just wait for New York to wake up and find out what John Gruber has to say about it – although he probably couldn’t give a monkeys – but it is sure to be entertaining reading if he weighs in.

For what it’s worth, I think it’s a great idea and a terrible idea. If this is a backdoor for poorly designed and poorly developed Flash Apps and advertising banners to dominate our interactions, then it will do none of us any favours. I think the same about Flash CS5 export to iPhone. But if AIR is another option to distribute apps then why not? (remember, AIR has a great HTML5 rendering engine in WebKit too). This is obviously not going to be subject to the same UI standards that make the iPhone so universally usable, but the reality is we live in a plural world, and the monoculture of iPhone UI specifications cannot possibly last forever, and nor should it. These platforms and devices all need to let go a little to allow the innovators and expressive interface designers experiment a bit.

Interesting times ahead.

I recently helped Trevor at Sploosh, an old friend and collaborator from Cape Town days, with the development on a new Flash website he designed for Pod, a “luxury boutique hotel” in Camps Bay, Cape Town. Took a few late nights to fit around my London remoteness, our respective dad duties and my day job, but the end result is a satisfyingly smooth mood Flash experience.

This is the first ActionScript project I’ve had the chance to work on for a while, and I can at last say I am fully converted to AS3.  The main features I am proud of in this production are:

• full screen scaling background imagery
• nice mask intro landing page
• external XML based navigation and content
• gallery slideshow that auto rotates if more than one image is present (see the Facilities page)
• deep linking (uses swfaddress)

I used a few open source libraries for this, including swfaddress,  Gtween and Bulk Loader.

Ah, a chance for process mind dump. My favourite! Here’s what I think
off the top of my head….

Yeah, I know what you’re saying about the tendency for clients to
change their minds when they see things in action. Generally it is
hard (for them especially) to visualise things out of context and
without seeing it in action. It’s what a prototype is for – one
expects it to change in the next iteration after feedback.

I suppose you need to offer a certain number of iterations at each
phase, and you agree beforehand that by the 2nd, 3rd or 4th (or
whatever maximum budget permits) feedback session you will have
reached a final version, or renegotiate terms. Obviously the better
defined the goals and idea is from the beginning, and the better the
feedback and communication with the client, the more worth you get out
of each iteration.

Internally we then discuss behaviour/presentation that is on brand and
in scope and answers feedback so far, and make sure we are developing
to meeting those goals.

I suppose one should throw some basic user testing into the mix too…
I usually show it around the office and send links to a couple people.

See it as building up from the essentials. Your first prototype was
actually your static photoshop designs. Next we will add click and
load of linked content, and then we will add transitions and tactile
mouse interaction behaviour, then we will tweak and polish. (there. 3
phases)

As for the hard work up front… I think a large part of that can be
mitigated by good client communication and explanation of ideas, so
the designer/developer isn’t trying to guess too much at time of
execution.Brief the designer/developer effectively so they understand
the goals, and can add some of their own understanding and creative
flair to the problem solving.

Review internally frequently – we can make the mental leap to how
things behave a bit better than clients.

Also, as you know I like to develop with reusability and
configurability in mind, so swapping one behaviour for another, or
enhancing one aspect of the behaviour is more about adjusting a lever
than rewriting much more code. I think the core to making this stuff
work is getting the correct subtle balance in the various parameters
that combine to affect the overall behaviour. If we know we are
starting in the right direction, the post client feedback should be
met with this sort of adjustment (and usually is, unless they hate the
whole concept and we have to start from scratch.)

There you have my thoughts! Happy to discuss adjusting and solidifying
into a more structured process…