Dynamic Flash

I’ve been meaning to sit down and this article on SproutCore ever since it shot to fame as the underlying client-side framework used to build Apple’s recently released MobileMe web application. You see, SproutCore seems to have had a falling out with web standards and web development best practices, something that wasn’t getting picked up in all the mainstream coverage it was receiving.

For the uninitiated, SproutCore is a JavaScript framework developed by SproutIt. It was initially developed to enable them to build their Mailroom application, which according to their website is a hosted help desk service for consumer-oriented businesses . So far, so good. The description given on the SproutCore website makes it sound like the framework is similar to other JavaScript libraries like YUI and JQuery, only a little more focussed on the application as a whole:

SproutCore is a framework for building applications in JavaScript with remarkably little amounts of code. It can help you build full “thick” client applications in the web browser that can create and modify data, often completely independent of your web server, communicating with your server via Ajax only when they need to save or load data.

What the above paragraph only hints at, though, is that SproutCore doesn’t just ignore progressive enhancement — it hacks it into tiny little pieces, urinates all over them and then mails them back to you one by one:

After lots of testing, we have found that the most efficient way to server a SproutCore application is as a … static web page! Once a SproutCore application is loaded into your web browser, it communicates with your backend server using Ajax.

Can you guess what an application looks like with JavaScript disabled? If you said “a blank page”, you can give yourself half a gold star. The unfortunate truth is that what you get is even worse than a blank page – you get a page devoid of any content but with UI controls that do absolutely bugger all. Don’t just take my word for it; check out the check out the SproutCore Photos example and then turn JavaScript off and hit refresh.

I thought we’d moved past this whole progressive enhancement issue back when Jeremy Keith was banging on about it to anyone who stood still for long enough. Alas, it seems there are still some poor unfortunately souls who have yet to benefit from Jeremy’s wisdom.

The total disregard for progressive enhancement is not the only thing wrong with SproutCore. Almost every UI widget and container in the framework is represented by nested <div> elements, differentiated only by their combination of class names. Where semantic elements are used they are used incorrectly (i.e. using <label> for headings). There is no sign of tab-enabling them or WAI-ARIA support, and all of this means that SproutCore applications are likely to be totally inaccessible out of the box.

OK, so SproutCore is bad, but what does all this have to do with Flash? That’s a fair question, given that the main focus of this blog has been Flash / Flex / AIR for the past 3 years. The answer is that the About SproutCore page takes a fundamentally misinformed swipe at Flash, and I’m calling them on it:

Why should I use SproutCore instead of a plugin like Flash or Silverlight?

Nobody likes using software running in a sandbox and no one likes to download plugins before they can use your software. If you want to create an application on the web that is fast, fluid, and native, and usable by everyone, use the only technologies that come built right into every browser: HTML and JavaScript. SproutCore makes it easy to do just that.

It seems that the SproutCore developers may have forgotten that JavaScript also runs in a sandbox, and it’s a great deal more restrictive than the Flash Player. Just try making a cross domain request using JavaScript, or setting up a permanent connection to a socket server, or (as is available in Flash Player 10) run-time access to local files.

They also seem to have missed the fact that the percentage of users unable to see Flash content is significantly lower than those fumbling around the Internet without JavaScript disabled. According to Adobe’s statistics content published for Flash Player 9 is viewable by an average of 97.4% of web users across all markets. That compares very favourably with the 95% of users who have JavaScript enabled according to w3schools.

Oh, and there’s nothing special about SproutCore’s fast, fluid and native controls – they are no more or less fast, fluid or native than Flash or Flex components. You can make either one look like native operating system controls but that doesn’t mean you should, and speed of execution and layout is down the to the implementation. On the speed front, it’s interesting to note that Mozilla are busy integrating Tamarin (the ActionScript virtual machine built into the Flash Player) into Firefox in order to support ECMAScript Edition 4 and speed up JavaScript execution.

The worst thing about all this for me is that this is the framework that Apple have chosen as the foundation of their MobileMe web application. There are lots and lots of bad frameworks on the Internet, but to see one used in such a prominent application by a company normally very meticulous about application design and user experience is disappointing.

I hope that the SproutCore developers read this article and take on board at least some of the points above. There’s nothing in the framework that cannot be fixed, though fixing the whole progressive enhancement issue is going to require a shifting of the framework’s focus away from 100% client-side application logic.

I’m heading down to Brighton this evening for this year’s Flash on the Beach conference, and right now I’m feeling like a kid on the night before Christmas.

Last year I didn’t plan my schedule in advance, and ended up missing some sessions I’d really like to have seen. This year I thought I’d be ultra-prepared and decide what I wanted to see in advance. With that in mind, here is my personal schedule for the conference:

Monday

1. 09:00-10:00 Keynote: Overview of Flash CS3 Professional – Richard Galvin
2. 10:15-11:15 Localising Flash Content and Applications – Dave Williamson
3. 11:30-12:30 Understanding Adobe AIR – Mike Chambers
4. 13:30-14:30 Adobe AIR for Interactive Designers – Lee Brimelow
5. 14:45-15:45 The Pirates of Accessibility – Niqui Merret
6. 16:00-17:00 Dynamic Abstraction – Joshua Davis
7. 20:00-21:00 Inspired: If it ain’t broke, break it! – Brendan Dawes

Tuesday

1. 09:00-10:00 Flex and ActionScript 3.0 Worst Practices – Ted Patrick
2. 10:15-11:15 Perceptive Interactions & Alternative Interfaces – Craig Swann
3. 11:30-12:30 2D or not 2D, that is the question – Mario Klingemann
4. 13:30-14:30 Mobile Flash Development – Dave Yang
5. 14:45-15:45 Flashing Flex – Tink
6. 16:00-17:00 Breaking away (Processing) – Robert Hodgin
7. 20:00-21:00 Inspired: Beyond the Knowledge – The Art of Playing – Erik Natzke

Wednesday

1. 09:00-10:00 Adobe Town Hall Meeting – Adobe
2. 10:15-11:15 Stylising Flex Applications – Joey Lott
3. 11:30-12:30 Klangfabrik – Andre Michelle
4. 13:30-14:30 Visualising Time – Marcos Weskamp
5. 14:45-15:45 Flex Application Development: Done in 60 minutes – Mike Jones
6. 16:00-17:00 Algorithms to Fill Space – Jared Tarbell

I’m not sure how much of the after-hours partying I’m going to get to. Last year my fellow Yahoos and I sloped off to a local bar and spent the evenings drinking beer and shootin’ pool rather than partying, which is much more my kind of scene.

Anyway, if you’re lucky enough to be going the the best Flash conference on the planet, I’ll see you on the beach.

Yesterday, Adobe released Flash Player 9 Update 3 Beta 2, which (aside from a ridiculously convoluted name) has caused much furore in the industry.

With the big headline feature of the beta dominating the blogosphere – that’ll be native HD-video playback via H.264 support, in case you’ve been hiding under a rock – you’d be forgiven for thinking that this was the only feature added to this release. In fact, there were several less glamourous features listed in the release notes that passed pretty much uncommented, including support for Flex framework caching and full-screen support on Linux.

One of these less-publicised features is that Flash Player 9 for plugin-based browsers on Windows, which includes Firefox, Opera and Safari 3, now supports the Microsoft Active Accessibility (MSAA) layer, which means that properly-authored Flash content should now be accessibly to screen reader users on Windows regardless of which web browser they choose to use. Support for MSAA in Internet Explorer has been included since Flash Player 6.0r65, so it’s nice to see support now being added across all supported web browsers on Windows.

This isn’t a panacea for all Flash’s accessibility ills – the Flash Player is still lacking support for accessibility layers on other platforms, for example – but, when coupled with the ability to get video subtitles included in the H.264 feature, it is an encouraging step in the right direction for Adobe.

Niqui Merret has compiled a great list of Flash accessibility related issues on her blog. Some of these issues have clunky workarounds – like not using the wmode setting (I did say clunky) – so if you’re creating or using Flash content, be sure to check out this list to make sure you’re not unintentionally harming the accessibility of your project.

The only thing I have to add to this list is that Firefox support for MSAA on Windows appears to be coming in the next beta version of the Flash Player 9, based on Emmy Huang’s post on Flash Player 9 Update 3 Beta.

Oh, and if you feel strongly enough about any of the accessibility issues, don’t forget to file a feature request. While all the issues Niqui mentions aren’t necessarily the fault of the Flash Player team, if you let them know what’s important to you they can work with the browser manufacturers to sort out any issues.