Yeah, But Is It Flash?

This wasn’t an easy decision. After all I’m supposed to be a Nokia fan boy. However, after much deliberation my trusty wee Nokia 5800 has been put aside and I’m now using the Google Nexus One as my primary mobile.

Anyone who knows me will be well aware that I’m quite enthusiastic when it comes to the Symbian S60 operating system. It’s something I’ve grown comfortable with over the years and has always dictated what phone I get next.

I’ve been tinkering with Flash on mobile since Flash Lite appeared on the scene and Nokia have always done an excellent job of supporting Flash Lite on their mobile platforms. Flash is actually the reason I got my first Series 60 handset and it’s the reason why I’ve stuck with Nokia devices for so long.

However things are changing and Nokia don’t seem to be keeping up. Flash Player 10.1 and Adobe AIR 2.5 have now arrived on mobile and I’ve been desperate to explore both. Unfortunately there’s no sign of Flash Player 10.1 on any upcoming Nokia devices and they seem to be going with Flash Lite 4 in the short term rather than AIR.

So for the time being I’m moving over to Android, where I can get a much more complete web experience and also create cool Flash apps until my heart’s content.

This doesn’t mean I’ve become an overnight Nokia hater or anything. I will be keeping an eye out to see how things develop. The Nokia N8 looks like it could be quite interesting – It’s just a shame its doesn’t support Adobe AIR.

Does it look familiar? Of course it does, it’s the HP Windows 7 slate. It was certainly one of the most promising looking tablets on the horizon and I for one was a little upset when it looked like HP had pulled the plug on the project. Thankfully HP has just announced that it will arrive this fall/autumn.

It’s a nice looking device and I’m hopeful that they’ve ironed out the usability and performance issues that we were hearing about from those who got their hands on early preview versions of the device. Best of all is that the HP Slate will support Adobe Flash within the browser. Not sure if it will have AIR support but fingers crossed.

Here’s some more info.

Now what about a WebOS version? Now that would be interesting.

UPDATE: Looks like the slate is no longer a consumer products. Thanks to mnem for sending this link.

Flash competitions are like buses. You wait ages for one then three come along at the same time. But hey I’m not complaining and neither should you because three separate competitions simply means three more chances of winning something!

Adobe are really starting to push the Flash platform on mobile and along with its partners is looking for exciting game content that runs on either Adobe AIR for Android or Flash Player 10.1 for mobile. There are generous prizes on offer for each of the contests ranging from cash to software bundles.

Kongregate are offering almost $30,000 in prizes including Adobe CS5: Web Premium for the top 5 entries. Made for Mobile are offering over $20,000 in prize money spread across 105 (yes 105) winners plus Adobe CS5: Master Suite for the best 3 entries. And lastly (but certainly not least) is Cell Your Flash Game’s contest where the top 3 will win Adobe CS5: Master Collection and take a split from a cash pot of $4310. The next 147 (this isn’t a typo either) people will receive $100 each and a few will also receive Adobe Flash Professional CS5.

So what are you waiting for? Get coding and see what you can come up with. Oh and try not to bite off more than you can chew. The submission dates are actually quite tight.

Right all I need now is a great idea! Err,….. Damn! Oh well maybe next time

Good luck!

here’s an interesting video showcasing the Flash Platform being used to deliver a mobile version of the Photobucket site. Before Flash Player 10.1 for mobile’s arrival the conversion effort to support video on mobile would have taken the Photobucket team several months. However by sticking with the Flash Platform the Photobucket team were mobile ready in a matter of days.

Vice President of Engineering Luke Swanson cited cost savings as a major factor. Using Flash removed the need to transcode and store multiple copies of their existing videos in different formats. It was also interesting to hear Software Engineer, Chris Nguyen describe the process of porting their Flash content to the mobile site as “pretty much plug and play”.

I decided to see what all the fuss was about and took the mobile Photobucket site for a spin on my Google Nexus One using Flash Player 10.1 beta 3. The results were pretty impressive although I still think there are a few usability niggles that need ironed out – scrolling on a page that was mostly consumed by a video was a little tricky.

I’m sure the Photobucket team will be looking forward to Flash Player 10.1 rolling out across more mobile devices in the not so distant future.

The Challenge

There’s much talk of creating content once with Adobe Flash and running it just about anywhere. Now anyone who’s had experience writing Flash content for mobile will know that it’s not that simple (all devices aren’t equal after all) but hey, I’m always up for a challenge and thought I’d try and port some web-based content to a wide range of handsets.

So what to port? Well I recently posted about the WeeWorld Fame Game, which we released a few weeks back, and thought that it would be an ideal candidate. Now I appreciated the sensible thing would be to plan with mobile in mind from the outset but I was genuinely interested to see how difficult it would be to take content that was designed primarily for the web.

Now if you can’t be bothered reading on – it’s quite a long post – or don’t have the time then why not just watch the video above where you can see the results of my little experiment. If you want to know more then read on.
(more…)

I asked in my last post if Adobe’s focus on mobile would limit the features we’d see in future versions of Flash. Well looks like I have an answer via Thibault Imbert’s blog where he teases us all with talk of Flash’s next generation 3D API.

For those wanting to know more, Flash Player engineer Sebastian Marketsmueller will be holding a session at Adobe MAX 2010 where he’ll delve deep into Flash 3D. So just how sophisticated is Flash’s 3D support going to be? Well I guess we’ll need to wait and see but without giving much away Thibault promises that some serious stuff is coming for 3D developers.

You can find a schedule for this years MAX sessions here.

Okay this is a slightly controversial post but it’s something that’s been nagging at me for a good few months now so I thought I’d put it out there and see what people think.

Will Adobe’s mobile vision for Flash restrict future features?

“Why would it?” you might ask. Well the whole point of Flash Player 10.1 for mobile is to deliver the exact same desktop web experience to our mobile devices. Considering the performance gap between desktop and mobile it surely wouldn’t make sense for Adobe to add any new features to Flash that were CPU intensive or memory hungry. Such a strategy would risk producing content that performs poorly on mobile and gives Flash a bad name. Unfortunately the really cool features are often the ones that require fast CPUs and bags of RAM.

Adobe has committed considerable time and effort educating developers about mobile and encouraging them to optimise their existing Flash content – Take a look at the Ads Optimizations and Optimizing Performance for the Flash Platform white papers. It’s clear they’re desperate to ensure that web-based Flash content runs well on mobile and shows Flash in a good light, so I seriously doubt they’ll want to introduce any new features to the player that might cause problems on mobile.

You could argue that Adobe should just keep adding great new features regardless of how well they might run on mobile and leave developers to decide whether or not to use them. The problem with this approach however is that they risk fragmenting the web with great content that runs brilliantly on desktop but poorly on mobile, which is exactly what they’re trying to prevent at the moment.

Sure, as time goes on, mobile devices will get faster and faster but there is always going to be a gulf between the power of mobile handsets and desktops. My guess, and my hope is that Adobe let their mobile strategy dictate, to a certain extent, the future of Flash and the features that we’ll see in upcoming releases.

In the short term I think it’s very important we start to see some performance parity between mobile and desktop Flash content. Much of it is down to the developers producing the content but I think Adobe can help by ensuring that any new features aren’t likely to melt our mobile phones.

There’s a really interesting post over on the YouTube API Blog from Google’s YouTube team explaining their reasons for using the Flash Platform to deliver video.

The article discusses the advantages Flash currently has over the HTML5 <video> tag including:

• A Standardised Video Format
• Robust Video Streaming
• Content Protection
• Encapsulation & Embedding of Video
• Fullscreen Support
• Camera and Microphone access

It’s definitely worth your while reading through the article and I’ll leave you with this quote, which I think sums things up nicely.

Today, Adobe Flash provides the best platform for YouTube’s video distribution requirements, which is why our primary video player is built with it.

Thought I’d share a video I stumbled upon today showing the latest beta build of Flash Player 10.1 running on an Android 2.2 handset. I’m pleased to say that the performance now looks significantly better than the first beta build I got to play with at the Adobe CS5 Road Show in Edinburgh. I guess from the performance gains I’d say that hardware acceleration has now been switched on, which was definitely missing when I tried it out.

From the video it also looks like many of the usability issues have also been ironed out – previously it was very difficulty to switch into full-screen mode but it does seem much more intuitive now. Some Flash heavy sites do still seem to be a problem though. The UFC site at the end of the video seemed quite sluggish and unresponsive as its content loaded, and there were also a few occasions where full-screen video looked a little choppy. Hopefully Adobe can fix these remaining issues.

For the most part however I was once again very impressed and looking forward to a final build of Flash Player 10.1 making it onto handsets.

Update: I’ve just been informed that Flash Player 10.1 for Android went live about a week ago. I’ll need to try and stay in the loop – it’s been a busy past two weeks for me though so at least I have an excuse Thanks to Dave for informing me.

I keep hearing from friends and colleagues that Flash is notoriously slow and the content it produces is hopelessly bloated. Of course this simply isn’t true but recently I’ve been finding out the hard way that it’s not easy to convince many of them otherwise.

Now I’m not attempting to turn this into a Flash v HTML5 debate but I do believe that some of these misconceptions have been borne out from the war that has erupted between those who support Flash and those who want it gone. However I feel most of the blame lies with those who use Flash and I do confess to being as guilty as the next man when it comes to writing large SWFs that use poor loading strategies.

It is all too easy to create unnecessarily large SWFs by producing hopelessly large vector images, packing your SWF with high-quality bitmaps, and forcing all your code and resources to load up-front. Ignore everything that’s great about Flash and you’ll soon have users yawning as they wait for the entire SWF to download before they’re able to try out your latest masterpiece.

So in an attempt to re-educate many of the non-Flash developers at WeeWorld I set myself the task of ensuring that any Flash content produced for our latest project would be as small as possible without a loss of perceived quality.

But first we had to decide if Flash was required at all. From the initial mock-ups it was clear that HTML, JavaScript and some server-side cleverness would take care of the majority. There was however one section right in the centre of the page that was screaming out to be done in Flash (or at least that’s what I believed).

Hey! I want to be Flash!!!

The centre panel in the mock-up above represents a little voting game where users get to vote for their favourite WeeMees during a fashion contest. Each time the user votes a new WeeMee is loaded from the server and slides into view. After voting, a panel is updated showing the current voting statistics for that WeeMee. To ensure the voting experience was as fluid as possible we decided to cache WeeMee SWFs up-front to reduce loading time between votes.

First I had to justify it. After all, some team members quite rightly stated that it could probably be done in JavaScript. In the end though we went with Flash for the following reasons.

• We’d need to load WeeMees, which are all dynamically generated on our server as SWFs.
• Flash would give us good cross-browser support without the need for any browser-specific code.
• The visuals could easily be reproduced using Flash’s vector drawing tools.
• The vector content would be a fraction of the size of bitmaps.
• ActionScript is compiled into a compact byte-code without sacrificing the legibility of the source.
• I moaned at my boss MacDog for two weeks straight until he relented.

So how did I get on? Well in the end I split the project into two SWFs – a preloader SWF and the main SWF. The preloader came in at 4K with the other being around 12K. The combined total was a minuscule 16K! To be honest given the tiny file size it was perhaps overkill having a preloader but heh, I’d rather the user had to wait for 4K to download before seeing something rather than 12K.

The point of the preloader wasn’t to actually feedback to the user how much of the content had loaded – after all everything loaded too quickly for there to be such a need. Instead it was created to force a visual onto the screen as quickly as possible therefore giving the user the perception that the content had loaded. I was eager to, as quickly as possible, plug the hole in the HTML page where the Flash content would be rendered, and the preloader gave me that opportunity.

High level breakdown of SWFs.

The diagram above shows roughly how each SWF looks and more importantly a high-level breakdown of sizes. The preloader’s (left hand-side) content is more-or-less split 50-50 by code and embedded fonts. The final size of the graphics within the preloader was perhaps the most pleasing, with the vector content only consuming 185 bytes!

It was a similar story with the main SWF (right hand-side). The ActionScript consumed the majority of the file size while the graphics consumed next to nothing. This time the vector artwork was a little larger but still comfortably under a kilobyte, coming in at 479 bytes. Unlike the preloader I was able to use device fonts for the main SWF, further helping to reduce the final SWF size.

I could quite easily reduce the total SWF size further by spending time shortening function and variable names. There are of course many other ways to squeeze the code down but I was eager to keep it as legible and maintainable as possible. The total size of the ActionScript source across both SWFs was 41K but was reduced to 13K after compilation.

I’m happy with the result along with everyone else at WeeWorld. Many were pleasantly surprised at the final SWF sizes and hopefully it has gone a long way towards making individuals realise that there’s absolutely nothing wrong with the Flash Player or the SWF format.

If you want to keep file sizes down I’d suggest you spend as much time and effort optimising your vector content – it’s certainly where the majority of savings were made on this project. Where possible re-use content by storing your artwork in movie clips and using instances of those clips. In fact take a look at the diagram below for a more in-depth breakdown of the vector graphics used within the SWFs.

Size breakdown across SWFs.

Also spend time thinking about your font usage. Only embed fonts if you really must. Where possible use device fonts, which will help reduce significantly the final size of your SWF. And although it wasn’t an issue with this project, if you find your byte-code size getting out of hand then you many want to split your code into separate libraries and load them at run-time when needed.

If you’re still in any doubt as to the compactness of the SWF format then perhaps this might give you some context. I examined the size of a single JPEG (260 x 274 pixels) loaded onto the front page of the WeeWorld site. It was a fairly compact 31K in size. Now compare that to the 16K total of our two SWF files (360 x 459 pixels). That’s right, our fully interactive Flash content with graphics, fonts and animation was half the size of a JPEG!

Anyone still want to argue that Flash can’t produce compact content?