And that’s understandable, given that we are tumbling into the next generation of everything all at once right now – SaaS and SOA, Web 2.0, Blu-ray, cellular streaming, and on and on – like a tornado crossing a junkyard. It’s one of those times when it’s hard to keep things straight.
So Adobe’s AIR announcement roiled the swamp and raised the themes of rich Internet applications, offline Internet applications, and cross-platform runtimes in a wormy bundle. In the process it was lumped together, variously, with Google Gears, Mozilla Prism, Sun JavaFX and Microsoft Silverlight in the Air coverage.
Sure, AIR has something to do with each of them, but it is more important than any of them. It may be a primary salvo in a user experience revolution on the scale of the fabled Sacking of Xerox PARC by Apple and Microsoft during the First PC Epoch.
That was the conquest that brought us the spoils of the graphical user interface, pointing devices and the desktop “metaphor.” It also, sadly, solidified the tedious Sunni-Shiite squabble between Windows users and Mac people that persists to this day. But what goes around comes around and Adobe may now be about to sack Apple and Microsoft.
Kevin Lynch, the guy responsible for AIR, certainly thinks so. On the eve of AIR’s release, he reflected that it “represents the beginning of a new medium as the best of the web and the best of the desktop come together.” Whoa, dude, beginning of a new medium? You are blowing my mind.
Okay, so how does AIR rate as a platform for rich Web 2.0 applications against the gang of four to which it has been compared? A chart might help.
Neither Gears nor Prism profess any particular RIA aspirations. In both cases, if the application is rich, it’s rich. Gears lets applications cache data and page content locally on the user’s machine to be used when the machine isn’t connected to the web. Prism, which is still under development, does something quite different; it enables the user to move browser-based online applications out of the browser and onto the desktop.
JavaFX, the newest member of the prolific Java technology family, salutes the RIA flag by enabling easier scripting of dynamic user interface elements in web-based applications. It interoperates with things like NetBeans and, of course, the Java runtime, so, as with other kinds of Java applications, the RIA could be browser-based, but needn’t be.
When Microsoft talks about Silverlight it’s all about RIAs and it parrots what Adobe says about AIR, the user experience, monetization and branding. It’s the natural thing to say about RIAs, but Silverlight’s cross-platform/cross-device functionality comes by way of the browser and it still has no offline capabilities.
So, if a developer wants to build a rich Internet-enabled desktop application that runs the same way across platforms and devices, does useful work offline, doesn’t use a browser, and directly enables interactive content, it seems that AIR is the only option.
To speak of RIAs is to speak of the “user experience,” which could mean what a user does and how he or she feels in the process of finding and using information and content, communicating with other users, consuming media items and products, dealing with connectivity, and interacting with transactional software applications.
An RIA delivered in a browser forces the user into a disjointed overall experience comprising multiple different user experiences in the application, the browser and the operating system the browser’s is running on.
If you’ve ever tried to use Internet Explorer on a smartphone to do anything useful, you know how painful that user experience can be. Granted some browsers are better than others and it’s hard not be impressed by iPhone commercials. But users of applications for sales force automation and e-commerce or social networking and streaming media don’t benefit from the browser “experience”; they suffer from it.
Applications and content providers don’t benefit from it either, net-net.
The cross-platform benefit is outweighed by the price of limited local intelligence and persistence, diluted user intimacy and brand impact, and always being a tab away from a competitor and a click away from nowhere.
A persistent standalone “devicetop” application that connects to the Internet and communicates with back-end Web Services there, caches data for offline use and, to the extent the OS will allow, has a look-and-feel specific to the application and its intended user, runs on any device or system and provides a user experience that’s more immediate, intuitive and intimate can’t be browser-based.
Instead of thinking about of applications for salespeople and teenagers, think instead about the user experience of an emergency medical technician thumbing critical medical information into his Blackberry.
“Stay with us, sir. Hang on!”
“Lessee, Applications… Browser… Bookmarks…”
“He’s flatlining! Get the paddles!”
“Ah! Wrong Bookmark! Bookmarks… Got it… Page loading… Scroll down…Scroll down… There, Enter Patient Data…”
“Sir? Can you hear me? Sir?”
“Damn, damn, damn!”
Clearly the browser isn’t the best deployment vehicle for an emergency response application or most others.
The Java language(s) and runtime, and adjuncts like AJAX, have come to be the only way to build browser-less, high-touch cross-platform applications. A lot of the cool stuff you see out there these days was built this way. But it’s a high-skills/high-cost way to go, especially if the application requires facilities that aren’t native to Java like media streaming.
The open source movement has ameliorated this barrier considerably by providing frameworks for some things, but Java is not a user-experience platform.
At the device level, of course, there’s a user interface, and this interface influences the user experience of applications and services on the device. On a commodity cell phone, the UI comprises hard or soft buttons and keys and a small screen showing text and possibly graphics. On a premium smartphone or PC the UI is Windows, Mac OS or some stripe of Linux.
The device-level user experience is the main reason people buy one device, one phone, one PC over another. Apple’s Mac, iPod, and iPhone devices and Mac OS, Quicktime and iTunes software have set a stratospheric bar for the device-level user experience.
Microsoft, God bless it, keeps trying, but every one of its approaches – and there have been many – has lacked coherence, clarity and comprehensiveness.
Anybody who has, even recently on Vista or Windows Mobile, tried to buy, use or make music or other media the Windows Media way knows painfully well how far behind the Microsoft user experience really is.
Sadly for it, Microsoft doesn’t get nearly enough credit for the heavy lifting it’s done in media codecs and other goodies out of Microsoft Research. These things add substantially to the quality of certain user experiences, but users won’t see how good the screen looks when the buttons don’t make sense.
For both Apple and Microsoft, enabling, controlling and monetizing the user experiences related to media is a strategic mission.
The things affecting their success include how easy it is for developers to build rich media applications, how easy it is for users to find, manage, use and interact with media elements and applications, and how easy it is for publishers, advertisers and distributors to federate, interoperate and transact business.
Now, consider Adobe. It’s hardly a stretch to say that Adobe has been in the user experience business all its life. Fonts, documents, graphic design, images and video are critical to a high-quality computer user experience and Adobe products have historically set the gold standard for tools used to create all kinds media. Both Apple and Microsoft compete in various ways with Adobe in this arena, but neither covers all the categories nor provides comparable cross-category collaboration facilities. Commercial content creators know, trust and love Adobe. They use Macs and PCs.
Then there’s Flash.
Most folks recognize the name from the ubiquitous in-browser media player used on sites like YouTube for video. Some know it’s the technology underneath sexy graphical movie splash screens on all kinds of web sites, but most people use Flash media without realizing it.
Underlying the Flash Player is a runtime engine capable of processing all manner of user interaction through programs written in ActionScript and other languages. Flash web sites are the result. A site is a movie made up of interactive actors that take the form of buttons and other controls. A user doesn’t visit a Flash site he plays it. Flash blurs the line between media and function. It enables instrumented media, a necessary element of both self-monetizing content and high-quality cross-device experiences.
Flash .SWF movie/site files are also fairly easy to use offline. If a particular user interaction with a movie element requires connectivity or local storage, it can be programmed to handle that far more easily than it would be in Java, HTML or the .NET languages. Neither Apple nor Microsoft has anything like Flash.
Less flashy than Flash, but equally important is Flex, a free set of software frameworks for building cross-platform, web-connected desktop applications that are really interactive Flash movies.
Adobe AIR is important because it completes the Adobe user experience ecosystem by providing a platform-independent platform on which to stage interactive content and programmatic functionality for rich Internet apps. Nobody else has anything like that.
It’s probably no coincidence that both Microsoft and Apple have recently made comments that are relevant here. Perhaps actually aimed at Google Gears, but timed to the AIR announcement, Microsoft sniffed that it would probably offline Silverlight sometime soon. More focused was Steve Jobs hissing about the Flash player’s performance on the iPhone – at the Apple shareholder meeting, no less. They seem to be taking notice of Adobe’s onward push towards a massive context shift where device choice doesn’t matter.
I actually used the AIR beta to build a monetized rich Internet application and as it came together with surprising speed and as I deployed it on a number of different systems with surprising ease, an application with MY look, feel and function beholden to no browser or OS, I had a feeling that I had felt before. It was the feeling I had the first time I used a programming terminal instead of a punch card machine, a hard disk instead of floppies, a mouse instead of arrow keys, WYSIWYG editing instead of dot commands, an IDE instead of a text editor, a GUI instead of DOS.
It’s the feeling I get from the sight and sound of giants leaping.