Tagged: flash


A New Approach for Flash Accessibility


My colleague (aka running buddy, aka friend, aka fashionista) Andrea Hill and I had a pow-wow a few months back in anticipation of her Accessibility presentation at Spring </br> . Personally, I thought the conversation was a perfect example of how genius occurs at the intersections of knowledge domains, as we were able to take her expertise on Accessibility standards and my expertise in Flash and Actionscript and come up a back-of-the-napkin approach to Flash Accessibility that might just fix all the headaches caused by interfacing with Assistive Technology. Note that this solution does NOT absolve you from designing for visual impairments, hearing deficiencies and so forth- this is a way of interfacing with screen readers.


Classifying Rich Internet Applications


I had an excellent discussion with my coworker Susan today about refining certain internal processes, and one of the tangents of the conversation went off on what the actual definition of a Rich Internet Application actually was. As we know, anything from a banner ad to a product configurator can be considered an RIA, and the only common element seemed to be that an RIA retains its functionality within the context of what the user is interacting with. In other words, if you click on button in an RIA, the resulting action does not significantly change the page or window the user is interacting with; Clicking to go to a new page loses context, using an animated accordion to display different content does not.

The similarities, though, end there. Implementation varies, technology varies, scope and location and functionality varies, and all in all it ends up being a pretty difficult convoluted mess to describe. At best you can group them via complexity, and after a brief exercise of that nature we realized that a new breed of networked application was emerging. Well, alright, perhaps not emerging, but instead gaining momentum and acceptance in the mainstream. Here’s the scale, see if you agree with our reasoning.


Application Release: Pandora & Practical Desktop


I’ve finally gotten around to fully open source my various applications, factoring and debugging the code, commenting and applying all the necessary licenses and other miscellaneous logistical duties to get my two AIR applications up and out there.

Practical Desktop

Practical Desktop appears to be a simple timekeeping application, though in reality it’s an open source widget framework that allows pretty much anyone to build a deployable block of functionality that can start interacting with other widgets. The wrapper’s there for you, go nuts. The source is here

From a personal perspective, I use it as a beta and explorative sandbox, because there are a lot of interesting things coming out in the near future that I’d like to offer some guidance on development best practice, and to do so I will have to figure it out myself first. Rest assured that the widgets I build will be functionally complete, though perhaps limited in feature support.

Pandora

The Pandora Desktop application is really just a customized webkit browser that’s hardwired to the Pandora mini player. I’ve fixed the application so minimization works in Windows, and expanded it to include the player’s html wrapper as well. The reason I did this is because Pandora’s a free service, and I’d like to make sure that I’m not ripping them off by stripping out the ads. Optimally I’d like to help them convert their existing player to AIR, but until I have free time (or they pay me 😀 ) that won’t happen.


Porting Pandora to the Desktop


So there I was, hacking away at AIR, and my iPod runs out of batteries. I was in that rare coding zen where you really need the audio to lock you out from the rest of the world, so I was fairly annoyed that the random conversation here at Apropos suddenly started to interfere with my productivity. No worries though, I could always resort to Pandora, right?

Now, I’m not a big fan of Pandora. Don’t get me wrong, I love what they’re doing and have found some phenomenal music there, but the fact that I always have to keep a browser window open to make use of their service has kindof annoyed me, and now was no different. I could deal with it though for the sake of productivity…. until I realized that AIR came with its own embedded WebKit browser.


Using the Metrics Package to record Flash Application Analytics


Web analytics is a way in which individual visitor action can be easily tracked within a site, and the aggregate statistical data derived from this can often lend remarkable insights into the effectiveness of your design, how ‘sticky’ your content is, and what your users are actually looking for. Unfortunately, extending this paradigm into flash has always been tricky, because it doesn’t adhere to the page-based paradigm on which most Analytics packages are built. Once a flash application or widget is loaded, the server loses most knowledge about what the user is actually doing within it.

Usually this isn’t really a problem- flash applications have not been too complex and not many people care where on the banner you clicked, just that you left the site as a result. Yet now with the strong growth of Flex and Ajax our web applications are becoming more and more complex, and marketers and usability experts are now demanding this tracking data in spite of the paradigm limitations.

If you really think about it, what we really are interested in tracking is a user action, rather than the page loads we are collecting right now, which means that the largest part of an analysts job is turning these page events into meaningful user actions, rather than interpreting those users. There’s been some attempt to set metrics to individual places within a page flow, yet nobody has yet thought to rethink the paradigm. But I digress…

Most Metrics providers have since opened their API’s enough to allow a developer to pretend like a new page refresh has occurred. While this is hardly optimal, it does allow us to track user events from inside of flash, but the fact that each provider has implemented their API a different way means that implementing metrics for each is still a string of unique problems to solve.

To that end I’ve written the Metrics package, which is intended to provide a common metrics proxy that any developer may use, which relies on a common library of connectors that can be swapped out as needed. In this article I go over the details of how to use it, and touch on how individual connectors might be written.


Package: Metrics


The Metrics package was designed to provide a simple, reusable, extensible and flexible interface to any web metrics package, including Google Analytics, Urchin, Omniture, WebTrends and more. It supports multiple connector management, instantiating only those registered connecters that are successful at autodetecting their environment. If a developer does not know in advance which metrics package his client is using (or whether his client might change his mind at a later time), he may safely add several connectors secure in the knowledge that the package will do the heavy lifting. Additional functionality allows you to “hot-swap” connectors should that become necessary, though I myself don’t exactly know why you’d want to do that.

At this point in time, the only connector published with this library is the UrchinConnector. Google Analytics and WebTrends will follow shortly, however due to my employers’ client agreements I find it prudent to not release connectors for API’s that are considered proprietary (such as Omniture) unless I have a formal letter granting me legal permission to do so.