What is "Apollo"?

A couple people, one of you in particular, asked me just what Adobe’s Apollo is, pointing out that my post from Adobe Engage last week doesn’t exactly start out with a definition thereof.

Indeed, there’s plenty of room for explanation before <a href="http://www.redmonk.com/cote/2007/02/27/adobe-engage-good-morning-apollo/"my usual arm-chair product management.

This InfoWeek piece has a good starting discussion:

[One of the ancestors of Apollo,] Macromedia Central was an early [version] of Apollo,” said Pam Deziel, director of the Platform Business Unit for Adobe. Apollo will allow developers to take applications built not only in Flash, but also in HTML, AJAX, and other Web development languages and create them to run locally on a user’s desktop, she said.

According to Sean Christmann, senior developer at EffectiveUI — a Denver-based company that has had an early look at Apollo — the technology acts as a wrapper, which makes it easy to take code from an existing Web application, wrap it in Apollo, and transfer it to the desktop. The key to making this transfer is Adobe’s Flex Builder tool, which developers can use to wrap their code with the technology, Christmann said.

What you can imagine here is the ability to move a Flash/Flex application from being the browser to existing and running on the desktop. The same could apply to self-contained XHTML/CSS applications. I haven’t seen a whole lot of the second apart from just wrapping a web page in an the Apollo equivalent of web-browser, but the functionality is in the Apollo framework.

A Desktop GUI Toolkit Built from Web Technologies

Moving Flex applications to the desktop is, to me, the core of what makes Apollo. “Flex applications” including using XHTML, CSS, and JavaScript as needed and desired as well. From the technical overviews I had last week, Apollo is indeed a “wrapper” on Flex and XHTML/CSS applications along with (obviously) the glue to tie those two together. Also, Apollo provides much more access to the desktop environment and underlying operating system than a web application would. That desktop access is currently to things like the file system, local devices, raw network sockets (right?), and other things a “purely” web-based application would lack or have severely limited.

Flex is an XML and ActionScript (Adobe’s JavaScript) based UI framework based itself on and “running in” Flash. The benefit of Flex is the ubiquity of the Flash player, aside from the (tragically) usual Linux hiccups (they say they’re doing, or will do, better).

Ain’t that just a GUI?

So, pulling back to the main thread, the point of Apollo is to build “applications” with Flex and/or XHTML/CSS/[Action|Java]Script. These applications “live” on the desktop, getting (some) of desktop benefits like the afore mentioned access to the local file-system and tighter integration with the native desktop windowing environment, e.g., a launch icon on the desktop or in the dock. And yes, there is security sand-boxing. The user interaction for this sand-boxing is limited to install-time only when the user approves the application; usability says this is all the user will tolerate. These applications act like web applications in so far as they’re very aware of and interact with the web, interacting with HTTP (and other) servers and even pulling in complete web pages, like Twitter.

Now, if you’re like me, your next thought is: “so it’s a desktop GUI framework, right?”

While that’s my conclusion, Adobe is edgy about declaring that outright:

• First off, philosophically such a statement misses the point: Adobe (and Macromedia before them) is trying to create a new way of creating GUI applications. They’ve certainly done that, taking a clean break from the Microsoft and Java/Eclipse (and, yes, Cocoa for all you OS X nuts) worlds both in that the way in which you code these GUIs is different and in that the resulting GUI can look much, much different than a native GUI. Apollo wants to bring down all the benefits of a web application to a desktop application: easy install, (more easily) connected to the rest of the world instead of stuck in a silo, simplified development and (sometimes painfully so) user workflows. Of course, the point is to mix in desktop benefits like working offline.
• Apollo isn’t done enough to be a full fledged desktop GUI system, it’s still 1.0. I tragically don’t have a handy list of the what Apollo can’t do on the desktop, but Adobe folks were always gracious to admit that it can’t do everything. One example is high-level uses of raw sockets like connecting to databases via ODBC or JDBC. Now, I have no problem with releasing incremental products at all. In fact, it’s what I advice. The problem for Adobe is that other people are not so nice: if they came out saying it was a desktop GUI framework, everyone would start flinging poo at them. This point is more important in the sense of causing a distraction that would cause Adobe to miss the window of opportunity to launch Apollo. They call it “FUD” as well. Of course, the future is a wide open space, isn’t it? I know Adobe would be happy to become a full-fledged desktop GUI framework (who wouldn’t?), but they’ve gotta ship sometime, and hence we have what we have. (Bravo on deciding to finally ship, even after several years and at least 3 major concept-iterations.)

All of this, esp. the FUD-avoidance, is why Adobe is desperate to create a third category of applications “between” desktop and web applications. It’s also why it’s so difficult for Adobe to articulate what Apollo is.

But, if you subscribe to my notions, there is no third type of application: Apollo is a web-aware and enabled desktop GUI framework. There’s nothing wrong with this. In fact, almost every vocal developer at Engage said “man, I really hope this works” meaning that they’d really like a new way of doing GUIs.

Desktop Buses

Another interesting aspect of Apollo is that it allows your application to not only run on the desktop and act more like desktop GUIs, but access the local machine like a “service” in the web sense. Now, that’s just common desktop GUI sense, but coming at it from a web application mind-set, it’s something new. Access to those “services” is currently limited (rightly so) for security concerns, but I get the feeling that Adobe wants to widen it over time.

That service pivot is one of the things that could make Apollo much more interesting. Several of us at Adobe Engage talked about the concept of accessing applications on the desktop as a service, and it seemed to solve many annoying data-interchange problems that currently exist. For example, accessing OS X’s AddressBook.app or Outlook is currently a problem. Fixing that problem would add a whole new bucket of features to application development, web or otherwise.

The glue (“desktop middleware” or “desktop bus”?) to access all those desktop applications as services currently exists in proprietary silos: Microsoft has their OLE/COM/whatever-it’s-called-now, OS X has their Services stuff, and Linux (hopefully) has a common desktop bus for interchange as well. But, OS vendors have an incredible interest in keeping those desktop buses locked up. Roach motels make killer revenue, bub.

A third party like Adobe with an application framework not tied directly to those roach motel revenues could build such a desktop bus though. Now, that’s the kind of thing we hope for from open source projects as well who — theoretically — have even less bias to lock things up.

What’s Left?

I’ve left a large chunk out, and that’s the notion of how servers are involved in these applications via things like Flex Data Services. The point here is that you can expect most Apollo applications to interact with some sort of server, otherwise it’d be purely a desktop applications. I believe the security model disallows peer-to-peer interactions between Apollo applications (except as mediates through a server, of course); that seems like a potential tactical problem, but I haven’t thought on it too long.

My developer head was incredibly skeptical at first. But, at least I’d look into Apollo and Flex more that I know it better. A single-source for any technology always bugs me out, rational or not (see this sailor-talk filled episode of the DrunkAndRetired.com podcast for more on that point). But, if it worked and was quick and easy to do, I’d assume it’d help make me money, so I’d look at it.

In all truth, speaking personally, I’d need free tools, probably built from someone other than Adobe, to really get into using Apollo or Flex. The price (any price) is certainly a sticking point, but the benefit I’d more be looking for was evidence of a thriving community which would point towards a tool-set that was portable to whatever environment I wanted to or was forced to work on. That said, I work on OS X, a very locked down OS, so I can be a bit two-faced when it comes to open-theory.

Now, how to combat that? I think that (some…a lot?) developers with my mindset would start to ignore their open-think if they saw their applications used widely and saw the delight users had with their UIs. Until Ajax, there really was no “cool” in UI design, and developers had taken to getting happy over how standard and “pure” any given framework was.

With the rise of OS X and Ajax, developers have “remembered” how rewarding it can be to have users who titter with joy over their user-interaction. Tightening up that feedback loop, and even making it possible, would be helpful for wining over non-Flex/Flash developers to Apollo. The question might be “remember when your users loved the UI’s you made?”

We’ll sacrifice a lot to be cool, which is good and/or bad depending on your motivations and desires.

Demos

Finally, I don’t have that many screenshots or screencast links. Once the Adobe Engage videos are up, there should be demos aplenty. But here are some in the meantime:

• Video Apollo Demos from Adobe.
• Video from DEMO 07 – the eBay demo that represents the “third type” line of thinking best.
• An in-depth demo from Mike Chambers (via Marco Casario).

Disclaimer: Adobe, Eclipse, and parts of Microsoft are clients.

Technorati Tags: adobe, apollo, cool, gui, integration, osx, redmonkclients, sunw, webapps