Attended a fascinating – but somewhat puzzling – focus group sponsored by Adobe tonight. Apollo is an upcoming Adobe product* that’s sort of difficult to put a finger on. Blurring the line between web and desktop applications, online and offline use, Apollo is a desktop run-time for any combination of HTML, JavaScript, PDF, and Flash, which can be packaged up into a downloadable cross-platform application that runs without aid of a browser. Fairly good description of the platform here.

Adobe seems to be putting a fair amount of emphasis on Apollo’s off-line capabilities, which are interesting, but what device isn’t connected 24/7 now? With everything going online – Writely, Google Spreadsheets, Basecamp, all the “rich” Web 2.0 Ajax stuff, Apollo is being introduced at an awkward time. How is it that Adobe is returning to the desktop right when everything is moving to the web? The desktop is becoming less relevant every day. I’m thinking the big markets for this will be car dashboard displays, kiosks, point-of-sale devices, handhelds, and cell phones. Personally, it’s hard to imagine developing any HTML/Flash/PDF system that I would also feel strongly should also be available as a standalone desktop application. But I could be wrong – look at the popularity of both Apple’s and Yahoo’s “widgets” systems (Apollo is like widgets plus BALCO).

If there was ever a product that needed a focus group to hone its message and understand its market, this was it. The eight web developers in the room had very different takes on what Apollo was, what it could do, or what it could mean to the web. Still, some very cool demos, and I have to admit it’s nice to be able to drop the browser chrome completely, go full-screen, use window transparency, etc.

Like Java, Apollo apps have the ability to access resources on the local machine (a developer demo’d a file manager like the OS X Finder, but running on Windows). Didn’t hear much about security (no time), but clearly it will be an issue for Apollo. Also, no PHP/CF/ASP services available, unless developers also create a server back-end for it to talk to.

Whether it has the potential to explode or will fizzle on the vine is anyone’s guess. Its amorphousness may make it hard to explain to users. If tonight’s session was any indication, it may be tough to explain to developers as well. A key to success will be in making it dirt-simple to generate Apollo apps. I would expect HTML or Flash developers to be able to drag a .swf or folder full of .html docs onto an icon and have an Apollo app be spit out the other end, or to export to Apollo directly from Dreamweaver, Acrobat, or Flash. Another Adobe-length learning curve could kill this thing.

Anyway, pretty cool tech. I just worry that the browser already “owns” cross-platform app space, and that it will be hard for Adobe to find a sweet spot for this.

* No, I’m not breaking any NDAs here.

Music: The Fiery Furnaces :: Inca Rag/Name Game

18 Replies to “Apollo”

  1. If I wanted a kiosk, I’d just use Firefox or Gecko… I have no idea why I’d want to pay Adobe for the privilege of removing chrome from a browser..

    XUL is very powerful, can (when the browser is configured as such) have full access to host system, and even have access to XPCOM components written in C++, JavaScript, and soon Python. And obviously can support any web technology either natively or through the use of a plugin..

    The only value they seem to be bringing to the table is offline functionality, but that’s something that could be provided in an XPCOM component pretty easily…

  2. Echoing Sean: Offline functionality is quite easy to add to Mozilla. No need to use XUL, plain old HTML and Javascript will do just fine for loading or saving files. Version 2 of Firefox includes SQLite if RDF isn’t up to your structured data storage tasks. Programmers have access to any of the components that make up Firefox, Thunderbird or SeaMonkey — extension auto-updating, X.509 security framework, address book, email, RSS, SVG. The only thing Adobe might be able to provide beyond this is a library for offline dynamic PDF generation.

  3. On the other hand, if you don’t have in-house XUL skills, Apollo would let you leverage existing talents and package up the whole app painlessly. Development time could be greatly reduced (if I’m right and they make Apollo generation painless).

    On the other other hand, you’d end up with a non-standards-compliant, proprietary, binary Flash-like object. All of the usual accessibility and standards reluctance about deploying on Flash will (I would imagine) also apply to Apollo apps.

  4. To repeat, Scot — XUL isn’t needed to develop offline Mozilla applications unless you need/want to modify the browser menus (even that isn’t difficult.) Simply build the interface as a normal HTML page. Access to local resources is accomplished with Javascript (the most widely deployed programming language, and kissing cousin to Lisp, the most expressive programming language.)

    The one area Adobe could gain traction in is ‘ease of use’. The Mozilla documentation is rather scattered, not version-consistent, and in general a moving target. Otherwise, it has a very long way to go in catching up with the Mozilla framework (which has a head start of 4 years.)

  5. Ah, I stand corrected on XUL (brain fart). Yes, it seems like this is definitely going to be a tough sell to experienced developers. And I’m not sure the need for the product is there for less-experienced developers.

  6. The Apollo thing sounds interesting to me. In some ways this is a successor to Macromedia’s Central environment, which did not see wide adoption. It seems like they’re trying to fix some of the issues with that, as well as broaden the supported development model (Central was Flash/ActionScript only). As someone who is currently learning Flex, I welcome the opportunity to easily port my projects to a desktop deployed and enabled environment. One way Adobe has described Central/Apollo is as the “occassionally connected client.” As far as I know it can take advantage of whatever web services or protocols you want to use, like anything else. So from my perspective Apollo just gives me another potential way to leverage my investment in learning Flex/ActionScript (or Ajax). On the web the flash client has succeeded in being the ubiquitous rich-client Java Applets always wanted to be. Seems like Adobe is trying to now apply that to the desktop also similarly to Java in being a cross-platform, cross OS development target.

  7. Your description of Apollo’s search for an identity reminds me of the early days of Acrobat:

    I first saw it sitting on the shelf at ComputerWare in ’92 or ’93, billed as the future of publishing, sure to _replace_ printed books… then I remember listening to an Adobe evangelist at WebEdge95 _trying_ to tell us what we would be doing with it soon… hmmm.

    Clearly they were scraping and didnt have a real clue where it would get traction, however they did have the resources to see it through. (never mind how awkward the process was, akin to what you’ve described re Apollo)

  8. Ward, you’ve nailed it re: “Flash is becoming / has become what Java on the desktop always wanted to be.” Now Java has been relegated to the server (and most of the time I don’t understand why orgs use Java rather than PHP or something else less resource-intensive), while Flash is the clear winner in cross-platform “rich” interactivity (man, I hate that word “rich” – sends my marketing-speak buzzers buzzing; but can’t think of a better word any more than the marketers can, so there you go).

    Anyway, looking forward to seeing some of your experiments with Apollo when the time comes.

    Steve, interesting comparison with the early days of Acrobat. Sometimes if you see far enough out, the market won’t “get” what it is you’re trying to do. That was certainly the case with BeOS.

    There’s also an element of “throw it at the wall, see what sticks.”

  9. Ward, you’ve nailed it re: “Flash is becoming / has become what Java on the desktop always wanted to be.” Now Java has been relegated to the server

    Please don’t mention that to our customers, I’d hate for them to stop paying us millions of dollars a year for desktop Java applets/applications.. :)

  10. “Flash is becoming / has become what Java on the desktop always wanted to be.”

    Except Java works just about everywhere, Flash does not. And Macrodobe has stated that there is no timeline for Flash on AMD64 Linux. I’d hate to think about OpenBSD on SPARC.

    I’m tired of this company. Can they get off the web already?

  11. AMD64 Linux is what percentage of the userbase? I feel for you man, really I do, but I also don’t blame them for not prioritizing it.

    The developer who did part of the Apollo demo mentioned Linux support alongside other platforms (I didn’t ask about AMD64 though).

  12. You know that Linux users are stuck on v7 of Flash, ja?

    Oh, they have promised v9. You know, the one they released months ago for Windows, and weeks ago for OSX. Linux users get it sometime early next year. So they promise.

    Many sites have (needlessly) “required” Flash 8 for a long time, and everyone not on Windows and Mac was locked out.

    It’s easy to say, “what percentage of the userbase are you?” when you’re not in that userbase. But we’re talking about something Macrodobe would like to consider the “standard” for media on the web. Standards are either fully open and documented so that they may be implemented or are well enough provided for by the author that no one is locked out.

    Not so with Flash.

    If they can’t deliver this to everyone, they should make sure it’s possible for others to do so. I’m not asking for the Flash Studio code; just the frackin’ player.

    Actually, what I’d really like is some sort of dynamic SVG implementation that kills Flash. I’m tired of a company wanting to be responsible for the delivery of the web’s media content when said company can’t port a media player to another architecture. Meanwhile, in the FOSS community, volunteers can port kernels and entire desktop environments.

  13. Hey, I did the BeOS thing for five years — I know exactly how you feel. But speaking of that, we did get a current Flash player back then even for BeOS. My understanding was that that was possible because the specs for the player were documented so OSS implementations could happen. Has that changed in the meantime?

    I think a lot of sites that “needlessly require” Flash 8 don’t even know they’re requiring it. They just output content from the latest version of Studio and don’t stop to think that the .swfs they generate are not backwards compatible.

    As for standards, yeah, that’s desirable but a separate question. Sure, I’d love to see SVG rise to the level of Flash and be a real competitor to it. But that’s up to the OSS community to make happen.

  14. Tinic Uro from Macrodobe said, “…there will be definitely no 64 bit version of the Linux plugin initially, at least not for the beta. Neither have we planned to have a Linux PowerPC or even ARM version for the upcoming beta.”


    And I really don’t want to chroot a 32 bit instance of Firefox to get a plugin.

    Nothing else on my system demands a 32 bit chroot. But a browser plugin does? Come on …

  15. All I can say is I that if resources were tight in my department, I wouldn’t devote them to a small fraction of a small fraction of my userbase. Even if it does stink for them. It’s not that I wouldn’t care, but that you gotta do what you gotta do. Reality bites.

    As for them publishing the spec so OSS devs could do it themselves, that’s still a good question. Seems like they used to but don’t anymore.

  16. Of course I don’t know, but that’s pretty much standard operating procedure in tech companies – everyone working long, hard hours.

Leave a Reply

Your email address will not be published. Required fields are marked *