We are especially pleased to launch with posts from Robert Reinhardt and Joseph Labrecque, as well as from our Senior Software Architect, Omar Gonzalez, and myself. You can expect to see many more posts, from more authors, throughout the year.

The point is to help serve as a guide and reference for the community of Flash talent, and we hope you find this site to be a beneficial and valuable source of information in this new era of interactive production.

Share and enjoy!

-r

The Production Engineer is tasked with producing code and functioning deliverables, in the areas of HTML, JavaScript, CSS and WordPress implementation and customization, per the specifications and standards of the Software/Solutions Architect.

Please plan to submit samples of CLEAN and WELL-COMMENTED code. Experience with unit-testing is a plus, but not a requirement, for this position.

Almer/Blank is an agile production studio, thus all candidates must demonstrate responsibility and ownership over one's tasks, as well as professional communication standards.

Majority of work may be executed remotely, during normal business hours, though ideal candidates will be in Los Angeles and available for occasional meetings.

Candidates may apply here.

The Production Designer is tasked with:

• Creating visual assets, per look-and-feel defined by senior creative resources, and per indications of User Experience Designer
• Processing visual assets, for engineering and production, per the specifications and standards defined by the Software Architect

Resources should be comfortable utilizing Adobe Photoshop and Adobe Illustrator (knowledge of other Adobe Creative Suite tools is a plus). Ideal candidates should also be comfortable with minimal HTML/JS/CSS production (but this is not a requirements).

Almer/Blank is an agile production studio, thus all candidates must demonstrate responsibility and ownership over one's tasks, as well as professional communication standards.

Majority of work may be executed remotely, during normal business hours, though preference will be given candidates in Los Angeles and available for occasional meetings.

Candidates may apply here.

While there are countless reasons as to their success, I believe each benefited from similar strategies that can also improve your odds of winning.

Content is King

It’s a basic business principle – if you don’t have what people want they will seek it elsewhere. So where could this content come from? Well, there are (2) basic types from my perspective:

1. Specialized
2. Generalized

If your content is specialized or concentrated around a particular subject, it has to be truly compelling to gain mindshare of potential viewers as the outlets available are astounding and growing daily.

If your content isn’t married to a particular subject then you need an abundance to create the foundation for “sticky” sessions that will have your viewers losing track of time as they peruse your library of content which you have carefully woven together using tags, keywords, etc.

Specialized content may be the easiest to acquire initially but requires a greater effort to maintain over time. Your content would have to generate enough buzz that people are constantly engaging in a dialogue either on your site or around the Internet.

Even if that were to happen, the window of opportunity is finite. Also, the time and financial costs can become exorbitant rather quickly which has the effect of constantly diminishing your rate of return making this path an unattractive one.

Generalized content is typically the complete opposite, being harder to acquire initially but requiring less effort to maintain over time. How you reduce the maintenance effort is by taking advantage of the social network which is more than willing to help you in your cause. And, due to the constant advances in modern technology, this social workforce is becoming increasingly capable of sustaining your efforts.

Recruit Social Videographers

If you build it, they will come. Everyday more and more people are discovering the massiveness of the social network. And, because of the social nature of this network, people are looking for ways to make their presence known, to participate, to have a voice, to socialize.

What you must provide them is a solid platform on which to do so. If you can make it easy for potential users to either generate content or upload existing content into your system, you are well on your way. But, you also need the capability to syndicate that content across the social network.

The more outlets you can tap the more appealing you become to your users who are appreciative for you making their lives easier. This good-will generally equates to positive word-of-mouth which can help propel your endeavor into the stratosphere.

With a limitless army of social videographers now working together with you, quantity of content should never be an issue again. All you would need to do is implement any kind of quality control mechanisms, if so desired, to keep submissions inline with your overall strategy, brand, etc. At the end of the day, you’ll have a mountainous library of content while rewarding your users with a media platform for social expression.

Multiscreen/Multidevice

Once you have content that people want to see, you need to enable them to view it in as many configurations as possible. The more accessible your content is, the greater its reach. The potential for your content to go “viral” is dramatically increased if it’s available across all the desktop browsers, as well as, available on iOS and Android phones and tablets.

Guarantee the most bang for your buck by investing the time and money necessary to extend your content library to these screens and devices. You get an additional bonus if you can also extend user content generation to these devices as well. You will be glad that you did and your users will love you for it.

Adapt to Tech Changes

Adaptability is extremely crucial to reaping the rewards of a social media strategy. You can improve your adaptability but having a firm understanding of not only how users have communicated in the past, are communicating now but how they might communicate in the future.

Future communications is not only subject to end user desires and needs but also to shifts in the underlying technology that enables these communications. Some things worthwhile to remain aware of:

1) New mediums, screens or devices available to deliver your content (eg, TVs, kiosks, etc)
2) Costs associated with the storage and delivery of your content (eg, disk space, bandwidth, etc)
3) Emergence of new video codecs or license changes in existing ones

The list goes on and on but the key is to start thinking about those things today so they don’t bite you tomorrow.

Use Twitter and Facebook to Promote

So, you’ve amassed an impressive library of content that’s steadily fueled by a sea of social videographers. You’ve made your content and content generation accessible across multiple screens and devices plus you’re ready for whatever the future holds.

Now all that’s left to do is to help your promoters promote. Not only must you integrate Twitter and Facebook for your users so they can spread the word, but you must also engage the social network through – you guessed it, Twitter and Facebook.

It’s simple. The more personable you are or are perceived, the greater your reach. Remember, this is a social network so when you “mingle” with people act like it. Don’t engage contacts like a cold, callous enterprise machine. If you do, you won’t be well received.

On the same note, you can’t be reckless either. Instead, let your corporate ethos serve you well by ensuring all communications are refined, responsive and informative yet relaxed. You want each contact to walk away with a positive experience because it’s that experience they will share with others thereby defining your social brand.

THE END

These are my thoughts and I’m sticking to them. What do you think? Post a comment or question.

At some point I’d like to discuss revenue generation as a follow-up to this article.

In the past 18 months, we made many representations to clients and prospective clients about the value proposition offered by Adobe’s Flash Platform technology, particularly with respect to mobile and pan-screen workflows, from design through production and distribution. We made these statements and representations, in good faith, based on publicly-stated, forward-looking representations from a publicly-traded firm — the fourth largest software publisher in the world.

However, given Adobe’s recent announcements, it's clear that a new era in the online frontier is rapidly unfolding before us. As we all embark on the next phase of this journey, we enter a turbulent period filled with both uncertainties and frustrations but also filled with new opportunities. We, at Almer/Blank, welcome this challenge as we are accustomed to being at the forefront of this kind of volatility.

Moving forward into 2012, we will expand our focus on native-language application development for devices and desktops, in Objective C for iOS, Java for Android and C for desktops — as well as specialized tools like Unity for more intensive gaming. Additionally, we will apply our extensive knowledge of Flash Platform technology to assisting clients in the process of migrating from Flash in their digital presence should they so desire.

The support to Flash that Almer/Blank has long provided through the LA Flash community, and the Rich Media Institute, will now be balanced with other community activities. First among these is a new website that Almer/Blank Labs will shortly launch, to facilitate the process of firms and Flash talent migrating to new technologies.

We are still experts in Flash Platform technologies, and we will continue to provide Flash consulting and development services — but moving forward, we will no longer make that our primary focus.

As always, Almer/Blank is devoted to creating outstanding digital experiences, for any intended audience, on any required hardware — and we will continue to employ whatever technologies are most effective at achieving those goals. On that front, nothing has changed — and it never will.

The focus of the Hackday was "Tech + Music + Video". Our team (which consisted of myself, Evan Squire, Hasan Otuome, and Michael Dela Cruz) didn't have any specific product vision — we just wanted to sit down and see what kind of creative experience we could build in a weekend.

After some discussion, I suggested an update to Mario Klingemann's Flickeur, which assembles a dynamically-created multi-media experience by integrating with the Flickr API to deliver user-generated photos in a creative and expressive medium. Of course, Flickeur was written ages ago (Flash 8, I believe) and today we have a lot more power. So, the key differences between Flickeur and our app include:

1. Instead of Flickr for pix, we would use Vimeo for flix.
2. Instead of tweens and color effects, we would use PixelBender to animate shaders on the video.
3. Instead of sound effects, we would use hit music (hit music makes everything look better) — we still use sound effects, but honestly I need to work on normalizing levels, because they are essentially inaudible in this version.
4. And we would add in some Synthia-like logic to correlate data of one kind (weather) to data of another kind (music, video and special effects).

I did about two hours of setup work on Friday night (just setting up the project folder, and running one quick proof-of-concept to ensure I could work with PixelBender and the video as I envisioned) so that we could hit the ground running on Saturday morning. We arrived on Saturday morning, and worked through until just before the final presentations began.

You can view a capture of the project here, on YouTube. This project is not posted online yet — primarily, because I need to integrate with a legit music source (like Spotify or Rdio) so I don't go to RIAA prison (this is the same reason that YouTube limits viewing of this video to the United States — sorry global community); and also because it hasn't been tested for online playback (when you're building at a hackday, you want to build quick).

So, what does this app actually do?

Well, first this app loads in the weather from a data feed, and then based on the details of the weather report it builds a playlist of MP3s and Vimeo videos, to reinforce the mood of the climate and environment. (We opted for Vimeo over YouTube support because, well, Vimeo videos tend to look a lot better.)

That's why, as a gag, we called it the 'Window for Lazy People with ADHD' (or 'WLPA')– so you can tell what the weather is without getting off your ass, or opening a window, and for those easily-distracted, you can watch an infinite playlist of rapidly-changing user-generated videos and hit tunes.

We apply PixelBender filters, dynamically, as shaders to the video during playback, to give it that artistic/cinematic feel. And we use GPU acceleration to get great performance, in the browser and in full-screen.

So, in case this isn't clear, WLPA is applying these special effects in real-time, to video that is loaded dynamically from an external source. Indeed, here are some still frames from the source videos, so that you can get a better sense of just how much special-effect work Flash is doing under the hood (click images for larger view):

Despite that this might appear as pre-rendered video (in fact, this led to some fun confusion at the event itself, as some believed this was our demo reel, and not the app we produced over the weekend), it is not — this is just one example of what the special effects and rendering capabilities of Flash offer today. And, I think that it's worth noting, that this project only uses features that have been in Flash since Player 10 was released THREE YEARS AGO — we don't even touch any of the stage acceleration or 3d features in Player 11.

Ours was the only entry in the Hollywood Hackday built in Flash. And while many of the other entries were impressive in various respects (and the winner, Tunehook, really was the best idea for an app with a real potential market, and had a nicely-executed prototype), ours was really the only one that featured any real design sensibility, or created an engaging experience of any dimension, or did anything interesting at all with video content.

And that's because Flash enables massive and rapid creativity with all types of content, including video, in a way that HTML5 simply does not (and saying this should not be seen as trashing HTML — it's just a true characteristic of the tools that we use). And we enjoyed showing the type of experience that you can create in just two days, when you have high-grade media support, and aren't debugging issues from browser-consistency.

I did the bulk of the coding, as well as the PixelBender customization for shader animation. Evan Squire handled graphic design, and the overlay effects and animations. Hasan Otuome wrote the Vimeo API integration code. And Michael Dela Cruz handled audio asset production.

There is a good chance that, time-permitting, I will continue production on this piece so that we can post and distribute it online (again, with legitimate media).

For reference, here's a slide from our presentation that shows which Adobe tools we used:

1. Adobe Flash Professional for animation and asset linkages
2. Adobe Pixel Bender Toolkit to load and preview shaders, so we could learn which settings to manipulate in the animations
3. Adobe Photoshop for visual asset production
4. Adobe After Effects for some of the graphic motion animation in the overlays
5. Adobe Media Encoder for media preparation
6. Adobe Flash Player to deliver the final experience

It really is empowering when you remind yourself what you can create with Adobe's tools. And we had a great time doing it.

Share and enjoy!

-r

Most of these limitations follow directly from how Stage Video is rendered, by the graphics card, beneath the rest of your Flash content, as I discussed in a prior post.

1. Even when Stage Video is available, the number of concurrent instances is limited. You can have up to eight Stage Video instances concurrently playing video on the desktop, and one on mobile devices. And, of course, remember that StageVideo might not be supported at all in the viewing environment. (Yes, the AS3 API informs you of how many instances are supported. More on that in a later post.)
2. You can not freely rotate the video. Your video can only be rotated in 90-degree intervals: 0, 90, 180 and 270 degrees.
3. You can not apply 3D, color, scale9Grid or skewing transformations.
4. Stage Video instances may not have alpha channel effects, blend modes, filters, or masks.
5. Access the BitmapData of the video, cache the video as a bitmap.
6. Use Stage Video with video that is embedded in your Flash source (Stage Video only works with video delivered over the NetStream).

And, this is not a limitation so much as a best-practice: Because you should set your WMODE to "direct" to maximize the cross-platform consistency of Stage Video (just like Stage 3D), this means that you should not use Stage Video with transparent SWFs.

Finally, I want to note that while Stage Video is available in most current versions of the Flash runtimes, it is not available in all. Stage Video is still not incorporated into AIR 3 for desktop (Mac or PC), and does not work on versions of Android prior to Honeycomb. On the BlackBerry Playbook, regular Video is treated like StageVideo.

Did I miss any of the limitations to note when working with StageVideo in Adobe Flash Player? If so, please let me know in comments.

Share and enjoy!

-r

Picking Screens

When discussing options for technologies utilized in production, obviously there's a lot of discussion around features — the powers enabled by the available options.

However, when building solutions with technology, obviously the goal is to support use cases — how people will really want and need to use this experience in real life. Supporting use cases is just as much about selecting platforms and environments as it is about examining power and features.

In other words, selecting which technologies to work with, and how you will work with them, is not just about technological capabilities — features and power — it's also about production workflow, publication and distribution options.

At Almer/Blank, we create experiences for every screen. But, of course, not every project needs to run on *every* screen. More often than not, you'll want to support many screens, but not all screens.

And, of course, you'll want to do so for as little money, and with as few codebases, as possible. Sometimes this entails rebuilding your apps or experiences in different languages for different platforms — but, increasingly, with the advances in interactive technologies, you can support all of your required platforms from a single codebase.

So it is very useful to have an understanding of which technologies actually work on which platforms.

To create the apps, games and other rich experiences that we do for our clients, we regularly work with three technologies that I believe are truly cross-platform: Adobe Flash, HTML5, and the Adobe Digital Publishing Suite.

And I thought it would be useful to review the platform support for each.

Adobe Flash

Flash is the most widely viewable cross-platform technology. It works inside of the browser, and on the desktop (or as an 'app' on mobile devices). It works on PC, Mac and Linux desktops. It works on iOS, Android and BlackBerry mobile platforms. It even now runs on certain types of Samsung and LG TVs.

In fact, the only place that Flash doesn't run, is inside of the iOS browser, on iPhones and iPads.

So, with a single codebase, you can create experiences targeting essentially any common, connected digital platform in the world.

HTML5

HTML5 is the latest version of the HTML specification from the W3C, and it brings many enhancements (like audio, video and 3D) that open up a wide new array of experiences that you can create inside of the browser, without relying on plugins like Flash.

HTML5 runs in all mobile browsers on iOS, Android and BlackBerry. And, HTML5 is now implemented in the latest versions of all desktop browsers on Mac, PC and Linux: Firefox, Internet Explorer, Chrome, Opera and, of course, Safari.

Unfortunately, since many people use older browsers, about half of desktop computers still can not view HTML5 content.

HTML5 for the browser, is just like prior versions of HTML in one core respect: cross-browser compatibility. Each browser creates their own HTML rendering engine, and the differences between how each browser (even the same browser on multiple operating systems) handles those differences can be negligible, or can prove to be a significant impact on your work.

With products like PhoneGap, HTML5 can also be used to author mobile applications, targeting iOS, Android and BlackBerry. And with products like Titanium, and Pokki you can use HTML5 to author desktop applications, as well.

Unfortunately, you have to customize your code for each of these purpose — meaning that it is not possible to support browsers and mobile apps from a single HTML5 codebase.

And this is a key characteristic of working with HTML5. Yes, HTML5 is a cross-platform technology in that you can get it to run anywhere (although, again, still not on about half of desktop computers) — but you have to alter the codebase for each of these top-level environments. So, depending on the platforms you wish to support, HTML5 may, in fact, not be as cross-platform a technology as Adobe Flash for your needs. This is fine, of course, as long as you understand what you are getting into.

Adobe Digital Publishing Suite

Adobe DPS is the latest entry into this set of cross-platform technologies. It is a set of technologies from Adobe that enable the creation of interactive publications.

DPS, unlike Flash and HTML5, does not require any coding to create, distribute, monetize or track rich and engaging experiences. All you need is Adobe InDesign, and you can create all your layouts, and define all your interactivity, right in a simple panel. (You can include custom HTML5 experiences in your DPS, if you wish to add mini games or apps to your publication.)

DPS can not be viewed in the browser — DPS publications are viewed through the DPS Viewer, which Adobe has built for you. You can use the white label viewer, or customize it to your own look and feel.

The DPS viewer currently runs on iPad, Android phones and tablets, and the BlackBerry Playbook. Adobe has announced support for iPhones and desktop computers in 2012.

You do not have the same degree of control with DPS as you do when building your own applications — of course, since you are using a white label viewer — but, aside from the obvious uses inside of the publishing industry, it is such a cost-effective way of creating engaging, interactive content, and distributing it to popular devices.

Summary

I've tried to summarize the above points in this chart (you can click the image for a larger version). I've used colors to indicate the variations in codebase under HTML5.

Share and enjoy!

-r

UPDATE: (11/4) Post and slides updated for increased clarity, and to add the options of Titanium and Pokki.

I gave a presentation to the AZFPUG (Arizona Flash Platform User Group) on MongoDB and MongoAS3. Below are links to the presentation slides and the GitHub repository to download the example code. The examples code repository is just a start and will continue to get new code additions as new features and new code example requests are received. If you find any errors in the code or have any comments or suggestions on the code examples please post them in the issues section in GitHub as opposed to the comments in this blog post.

Meeting Recording: http://t.co/WJ6yPIR6
Slides: http://dl.dropbox.com/u/1414382/slideDecks/IntroToMongoDBAndMongoAS3.pdf
Code Examples on GitHub: https://github.com/s9tpepper/MongoAS3-CodeExamples

A review of some past 'Flash Killers' might help illuminate the discussion as to whether or not HTML5 is.

Flash Killers

Before diving into a list of Flash Killers, it will be useful to define the term.

A Flash Killing technology is a technology that will kill off Adobe Flash Player — either by:

1. eliminating the Flash Player from a sufficient number of viewers' devices to defeat Flash's positioning as a ubiquitous technology
2. or by eliminating demand for Flash technology amongst firms and developers by supplanting Flash's features and functionality

Each of the following examples was either explicitly positioned by a firm as a Flash Killer, or was seen by the broader market, or some segment of the market, as a Flash Killer. I do not claim that this list is complete or definitive, but these are definite highlights I can call from my experience in this industry. If you can think of some that I missed, please let me know in the comments.

Scalable Vector Graphics (SVG)

SVG is an XML-based open standard, overseen by the W3C, in development since 1999. Despite the name, SVG accommodates for raster, as well as vector graphics, in addition to text. Today, SVG is increasingly accepted as a graphics and data format (it is, for example, one of the filters that you can apply on a Google Image search).

However, when it was introduced, it was seen by many as having a chance at being a Flash Killer (remember, this was at a time when Flash essentially only provided vector graphics, raster graphics, text, audio and a tiny bit of interactivity). And many firms — notably, Adobe — saw SVG as having a particularly good chance of taking out FlashLite as a threat on mobile. Adobe has long authored SVG viewers, and indeed, today Adobe still is involved in developing and promoting SVG.

Still, unfortunately, to this day discrepancies in browsers have prevented SVG from widespread adoption as a format for graphics, or any other type of data at all. Internet Explorer appears to be the main culprit, not adding basic SVG support until version 9.

Verdict: SVG may be a lot of things, but it was certainly no Flash Killer. There may have been multiple reasons, but the absence of universal browser support effectively made this technology a non-starter from the get-go. And today, SVG pales in comparison to the functionality offered by Flash.

Adobe Live Motion

This one is sort of my personal favorite, for a few reasons.

1. First, Adobe Live Motion is a relic from the days when Macromedia and Adobe were enemies entangled in litigation, rather than a single firm dominating creative workflows across industries;
2. Second, because it seems that people barely remember this product;
3. And third, because unlike many of the other technologies included in this list, Live Motion did not challenge the Macromedia Flash Player — instead, Live Motion relied on the Flash Player, and went after the Macromedia Flash authoring tool market.

In other words, Live Motion was Adobe's attempt to cut off Macromedia's revenues, using Macromedia's own runtime as the weapon. In case you aren't aware, Macromedia (then) and Adobe (now) do not make a dime from the Flash Player — the revenues come from the authoring tools used to create the content that is viewed through the Flash Player.

Released in 2000, Live Motion offered, to my recollection, three notable features:

1. Time-based animations (instead of the frame-based animations in the Flash authoring tool, then and now)
2. No ActionScript
3. An animation interface similar to After Effects

The time-based timelines were a kind of a nifty feature (eliminating the need to re-key your animations when you adjust your framerate) — in fact, there are still times today when I wished Adobe Flash offered this same option. And the integration with an After Effects-style GUI was likely quite useful for those coming to Flash from that tool.

However, in my opinion, LiveMotion was fatally flawed from conception because of the lack of ActionScript support. True, LiveMotion was positioned as an animation tool (and thus wouldn't require ActionScript), but even back in 2000, when ActionScript was a pale imitation of the coding language we have today, basic AS was required to do things even as simple as banner ads. And when you needed to use AS in your project, LiveMotion wasn't an option.

LiveMotion was discontinued after two versions.

Verdict: LiveMotion was not only not a Flash Killer — it wasn't even a viable product. Though, it is notable as the only member of this list to explicitly attack Flash as an authoring tool, while reinforcing the dominance of the Flash Player and underscoring the importance of ActionScript to the future of Flash technology.

 

Processing

Originally developed as a language and IDE ('integrated development environment', aka 'authoring tool') to teach programming to more design-oriented creatives, Processing made its way through the Flash community in the middle part of the naughties (the term I prefer for the first decade of this millennium). One of Processing's main innovations was the inclusion of a 'Sketchbook' as the IDE, simplifying and reducing the learning curve for designers to program.

To my recollection, Processing was not a sufficiently high-profile technology for much of the media to take note, but the Flash creative community (which Flash, unlike any other web or programming technology, has in droves) did. And they complained vocally that Macromedia needed to add features to cater more to designers and designer-based workflows, as Processing had done. (It is important to note that, by this point, Flash had seen the two most recent versions include new features that catered to developers more than designers or animators). I remember hearing that more and more of the design community was considering a switch to Processing if Flash didn't add more considerations for designers. Processing was (perhaps inadvertently) making a play for the hybrid designer/developer for which Flash had become so well known.

Processing is, to this day, a successful niche technology, enabling some wild creativity. But it never made a real or long-lasting impact on the Flash world. Why? Well, in my opinion, there were three main issues:

1. First, compiled Processing experiences require the Java runtime to view. Java is just not that widely-distributed — certainly not in comparison to Adobe Flash Player. A technology does you no good, no matter how expressive it is, or easy to work with it is, if the end-result can not be seen or experienced by your audience.
2. Second, while Processing features an IDE that makes coding much easier for designers, it doesn't include any design tools to speak of. Whether you are outputting to Flash or HTML, Adobe has tools that provide the entire design workflow prior to engineering. By comparison, it's just not that easy to port Photoshop and Illustrator designs into Processing.
3. And third, Flash got more visually expressive in subsequent versions.

 Verdict: Processing is popular, innovative and fosters a wide degree of creativity. As well, it is has found a market in which it continues to be adopted and utilized. I would say that it is a successful technology on its own terms, but in the end, was no sort of 'Flash Killer'.

 

Microsoft Silverlight

Microsoft Silverlight was introduced in 2007, and was positioned, to my recollection, explicitly as a Flash Killer. And, while you can debate which technology is better for which purposes, I believe that it is difficult to argue that Silverlight has been a successful web technology, or has come anywhere near achieving Microsoft's goals of supplanting Flash.

Microsoft faced three challenges with Silverlight:

1. to get developers using their tools
2. to get clients approving Silverlight work
3. to get their Silverlight Player installed on computers

On the first item of tools, Microsoft has two tools to author experiences in Silverlight. The first is their powerful Visual Studio, which can be used to code and debug applications. The second tool is Expression Blend which is a tool more positioned to design and animate interfaces and content. You can think of Blend as roughly analogous to Flash Professional in function and purpose.

Visual Studio is really an impressive tool, enjoyed by coders of many languages. And, you can program Silverlight experiences in multiple languages. So Silverlight included a robust engineering IDE. However, without going into the details of Expression Blend, let's just say that Microsoft doesn't excel at creating professional design tools.

Beyond the capabilities of Blend, it's important to remember that Microsoft does not make any solutions for content creation further up the workflow (I mean, it's not like you're going to use Microsoft Paint to design your web apps). Almost all of the time when working in Flash, you are working with designs that originated in Photoshop or Illustrator. All of those tools are Adobe's, and thus there is a clean workflow between design of an experience, and creation of that experience. Microsoft offered no design tools of their own, and only more recently has added workflows to support working with Photoshop designs.

When it came to having clients approve Silverlight work, Microsoft underwrote several high-profile projects, encouraging adoption among clients. This (along with the fact that you can develop Silverlight solutions in multiple, existing languages), encouraged developers to pick up the technology and fostered market penetration of the Silverlight plugin. But, it clearly hasn't been enough. Per Wikipedia, Silverlight has a player penetration around 65%, versus 95% for Adobe Flash; and Silverlight is utilized by approximately 0.3% of websites, as opposed to Adobe Flash's site utilization rate of 27%.

 Verdict: at the end of the day, while Silverlight may be seen as successful in some ways, and may still see other successes in the future, it's safe to say that it has not been a Flash Killer. 

Asynchronous Javascript And XML (AJAX)

The history of AJAX actually extends back to 2000. And, while we saw some cool early implementations starting in 2004 (with GMail), AJAX became increasingly popular around 2006 and 2007.

Unlike every other entry on this list, AJAX is not actually a technology — it is a way of using Javascript to work with client-side technologies, like HTML and CSS.

When AJAX came into popular use, it was often referred to as a Flash Killer. And, it is certainly true that AJAX enabled firms like Google to start building rich internet applications in HTML, that previously would have required Flash. At the same time, of course, Flash continued to extend in power, offering new features (like high quality video) stimulating increased adoption of Flash technology.

And, AJAX relies on web browsers to interpret and execute the instructions. Since web browsers are created by multiple companies, and run on operating systems created by other companies, that means that there are platform-specific discrepancies with how AJAX experiences are rendered — leading to increased time spent in developing and debugging AJAX applications. And, of course, each time a new version of a new browser is introduced, you have to go back and test all of your older AJAX work for compliance.

 Verdict: AJAX made the web better — a lot better — but it has certainly not been a Flash Killer. From my perspective, AJAX is used to enhance and improve experiences that are going to be written in HTML; very few AJAX experiences would otherwise be built in Flash if AJAX didn't exist — they would just have fewer features and be less enjoyable to use. 

The Ingredients of a 'Flash Killer'

A review of the above contenders for Flash Killers is instructive on a few points. First, of course, it shows that we've been down this road before. Almost since Flash was invented, people have been trying to find the next 'Flash Killer' — and to date, no technology has proven itself capable of taking down Flash. At the same time, I think the above examples help illuminate what a successful Flash Killer would look like.

A Flash Killer would, to my mind, have to offer three things:

1) Compelling Feature Set

Of course, a technology seeking to become a Flash Killer would have to offer a compelling feature-set — at least roughly equivalent to the features and power currently available inside of the Flash Player and utilized by developers in projects, sites, apps and games.

2) Widely Distributed Runtime

Second, the Flash Killer would need to be viewable by a large audience. It doesn't matter if you can create the most amazing experiences with a technology — if those experiences can not be viewed by anyone.

The Adobe Flash Player is the most widely distributed software in history — no other software comes close. According to the Adobe Census penetration of the Flash Player is currently at 99%; according to Wikipedia, that number is closer to 95% (depending on which entry you read). In any case, that's a lot of computers. Which means that if you author something in Flash and post it on a website, most anyone in the world who browses the web can view it (and for those who can not, it is possible to install or upgrade the Flash Player pretty easily and seamlessly).

I also think it is worth mentioning that, not only can most anyone on a computer view your Flash, but when they view it, it will look, feel and operate the same — no matter what type of computer or web browser they are viewing on (or what future version of the Flash Player that they may have installed). I can literally open up some of my Flash 3 work today in the Flash Player 11, and it will still run perfectly, as it did the day it was first published. That's a big difference from a technology like HTML, which is also universally viewable, but does not have a consistent, backwards-compatible runtime.

3) Tools and Creative Workflows

This is a key, and often overlooked, aspect of Flash — that Adobe provides not only Flash Professional (and now, Flash Builder and Flash Catalyst) — but also a whole set of tools that power the experiences created in Flash (or HTML, with Dreamweaver and Fireworks), including Photoshop, Illustrator and After Effects. In order for a technology to be a viable replacement, it must include tools to enable (or, at a minimum, accommodate) the creative workflows utilized by industry professionals that are based almost entirely around Adobe's content creation tools.

This is where I think solutions like Silverlight were fundamentally flawed from inception. People not only need to be able to use your authoring tools — they need to be able to execute complete projects, from conception and design, all the way through engineering and deployment.

Where Does That Leave HTML5

Hopefully, as this post has attempted to convey, the history of Flash Killers is lousy with technologies that did not even come close to killing Flash. Some of these technologies were complete failures on their own terms (like LiveMotion) and some are successful and popular technologies that have just not killed off Flash (like AJAX).

Today we are revisiting this same discussion, but this time the market wonders if HTML5 will be the Flash Killer.

If we look at the criteria I highlighted above, that I believe are requirements for any technology to be a successful 'Flash Killer', HTML5 does offer a compelling feature set (although one not on par with Adobe Flash; more on that in a separate post). However, HTML5 still does not offer a consistent or universally available runtime, and the tooling to build HTML5 in professional environments is still quite early stage.

So, of course, it's too early to tell if HTML5 can be a 'Flash Killer'. That said, in my opinion, it seems obvious to me that HTML5 will play out much the same way that AJAX has. Yes, there will be some projects that will be done in HTML5 that would otherwise have been created in Flash; yet, by and large HTML5 will make the web better. HTML5 will improve the quality of experiences authored in HTML. It should not — again, at least on its own terms — supplant Flash technology. (I attempted to examine this question in much greater depth in last week's post.)

So, when people ask 'is HTML5 going to kill off Flash' the answer should be 'too soon to tell, but it's unlikely.'

However, it is not possible to examine this question in isolation. Because when people ask 'is HTML5 going to kill off Flash?' they are really asking (whether or not they realize it) 'is Apple going to kill off Flash?' 

Of course, everyone and their uncle knows that Flash Player has not run on iPhones and iPads since their initial release. Steve Jobs provided an explanation of their position in April, 2010 and concluded that "Adobe should focus more on creating great HTML5 tools." Apple has additionally contributed significant efforts to creating and finalizing the HTML5 specification, and promoting its use in commerce.

Apple is trying to position HTML5 as a Flash Killer, because Apple wants to be a Flash Killer. HTML5 is simply the technology that Apple believes will offer an alternative for creating compelling, feature-rich experiences.

It is still too soon to tell how this will all play out. Adobe has recently created workflows to publish high-performing Flash work to iPhone and iPads, and we have to see how clients and the developer community adopt those new features. Perhaps Apple (in the post-Jobs era) might someday see their way to permitting the Flash Player on iOS; perhaps not. Perhaps HTML5 will be able to agree on a single video codec; perhaps not. We don't know what features Flash Player 12 and 13 and 14 will offer (all of which will likely be released before HTML5 is universally viewable by web audiences). These are all open variables that will impact this discussion.

That said, Apple's move was the first effective attack on Flash that I've witnessed in my 12 years of working with the technology. Because, this was the first time in the history of the technology that Flash was prevented from being distributed to a popular platform. One of Flash's core advantages is that it can provide a consistent experience everywhere. And, for the first time, it didn't actually work everywhere.

Still, it's important to remember that HTML5 is only the latest in a longer list of also-ran Flash Killers. Flash is a very robust technology that offers an advantage that has proven to be unrepeatable and insurmountable — namely, that it works on every screen.

Verdict: It's still too soon for a final determination whether HTML5 will be a Flash Killer, but I believe that history shows that, on its own, HTML5 does not have the ingredients to be a Flash Killer, and would instead prove to have much the same impact as AJAX has had, by making the web a better, more enjoyable place to spend time.

However, this is separate from whether iOS will be a successful Flash Killer. iOS has been effective at eating into Flash's market, by attacking perceptions, and offering replacement functionality in the form of HTML5. But the absence of a technology that can actually, truly replace Flash on all platforms has given Adobe some breathing room to create publishing workflows to engage on the iOS platforms. And, without intending to sound harsh, the passing of Steve Jobs has removed the core actor in this drama from the stage. So, we'll see in the next couple of years how this plays out.

Thus, HTML5 will not be a Flash Killer. Apple might. Time will tell.