JD's Forum

Hi, I've been very excited by the Macromedia Central project -- it has been difficult for me to keep from talking about it over the last few months! But with any new project, it's hard to predict how it will eventually be received by developers and the public. Here are some of the things I think are important about Macromedia Central, as well as some of the aspects I'm not yet sure about. If you've got early observations or opinions on these subjects then I would appreciate hearing what you have to say, thanks.

Disclaimer: I'm writing this from my personal understanding of the project, in advance of any public discussion. At this early stage I could well have some of the details wrong, and if there's a discrepancy between me and the docs, then the docs win. I may also ramble a bit here, because it takes practice for me to say things clearly and concisely. I hope you can put up with any vagueness or other problems in these early notes... I'm just really excited by it all, and hope that you are, too.

Lives on your computer, not on server: This is the key architectural difference for me. For applications, you really have to trust the author before downloading and executing a new app. For browsers, once you trust the browser-maker then you want to be able to visit any linked site safely, so no site can know much about you or interact with your system. Rephrased, with apps you have to trust a few people very deeply; with browsers you have to trust many sites not too deeply. We need a middle path.

Macromedia Central is a shell, a host, which lives on your local computer. It's a sandbox in which various applications can safely play. It differs from Java applets or other in-browser work because the code is local -- it doesn't require ongoing connection with a server, doesn't require a fresh download with each use. You can remember preferences across sessions without storing your private data on someone else's machine. Applications you choose can also share their stored and live data if you permit.

Are these lines crisp and clear? No -- browser cookies can store data locally, and you can open multiple browser windows to have two in-browser apps working simultaneously. But the basic architecture of document browsing is to protect you from violation when visiting any possible site. In Macromedia Central you can choose to trust your own selected applications to share personal profile data, but without risking system manipulation as you would with native-code applications.

With Macromedia Central you pull data from afar, rather than instructions from afar. This is a simple distinction, but it has a whole set of implications....

Easier adoption of stronger functionality: Because this is a middle path between browsers and native-code applications, we can get a middle ground between the ease of visiting a new web page and the persistence and power of a desktop application. This isn't a binary either/or, but more like a spectrum, where applications made in Macromedia Central can live in a new sweet spot between the easy access to web pages and the greater abilities in a net-enabled application.

Look at the differences between visiting a web page and installing an application. For the web, just click on a link, and it loads and renders for you. To download an application from the web you have to first decide how much you trust the author, then do a download of a relatively large file, decompress, click an installer, and activate.

Macromedia Central is in the middle. You can use the Application Finder to locate a new tool and check its recommendations, then Macromedia Central downloads the necessary code and handles its use. Installation is much friendlier than with applications -- the "one click install" is closer to just clicking a link in a browser. Because the hosting shell and standard UI components already live on the client machine, the process is also much faster than for a standalone native-code executable file.

When adding new functionality, Macromedia Central is more like a browser than a standalone application. But instead of just being a document browser, you could almost think of it as an application browser.

Faster performance: In a browser-based application, when you visit a site then you download a presentation layer, instructions for interactivity, and your initial data. With a Rich Internet Application (in-browser Flash) you can then do multiple data requests without reloading presentation and interactivity, but the application still ends when you leave the page, lose your connection, power-down the system, or otherwise break the session.

Keeping the presentation and interactivity layers local on your machine means that the only download costs are the ongoing data transfers. Macromedia Central starts up like a local application, and persists across restarts like a local application.

What are the data-transfer costs? It depends on which data-transfer method you choose. Macromedia Central is oriented around web services, with support for SOAP 1.1, WSDL 1.1 and XML-RPC. This is typically much faster than downloading HTML's blend of data and rendering instructions, much less any referenced image files and building a new display. But if you're working with your own server you have the additional option of using Flash Remoting and the compact binary AMF format. This is less of a server load than XML and frees you from serializing and deserializing in-memory objects from one system to another.

Will all Macromedia Central applications be faster than any HTML-based implementation? Probably not, because there are lots of ways to make things slower (see below). But when you compare apples-to-apples, then the local storage of presentation and interactivity, and the reduced transfer costs of XML and AMF over HTML, mean that performance can be more like a desktop application than like a browser.

Better return to developers: It can be hard to make money on web pages. The most reliable path is to have a patron: a client who hires you to make something which reflects well on them. Standalone applications can be sold to the public, but then you're subject to being ripped off by file-copying.

Assuming we can get past the chicken-and-egg distribution hurdle with the Macromedia Central shell (a reasonable assumption; see below), then applications built upon this base will be as easy to distribute as web pages, but can provide a financial return to developers without the problems of distributing standalone applications. The developer's business model is an extremely attractive aspect of Macromedia Central.

With a browser-based application there's always the question of whether the time you invest in development can be compensated. With standalone applications the big question is whether word-of-mouth will overcome the problems of executable installation. With the approach Macromedia Central uses, it looks like you can get easily and directly paid for the work you do, escaping that "patron" model and dealing directly with your audience.

Freeware? That's fine. Donation-ware? That's cool too. One-time purchase price? That's available. Free trials or partly-functional demos? Yes. A subscription service through your server? This model is also possible.

Even better, the success of any other Macromedia Central application increases the chances of success for your own application, because more of the potential audience will have the shell and UI components already installed. Your downloads can be remarkably light.

Right now I can't predict which economic model most developers would choose most often. But the ease of implementing any of various economic models makes me anticipate that we'll see great success here.

It's easy to make: If you've already created web applications with Macromedia Flash MX, then you've got the skills. There are some additional abilities available in Macromedia Central, but if you can develop in Flash, then you can develop in Central.

I'm confident of the overall shape of this new path. But I'm not clear yet on how each individual will weigh each particular detail. Here are some of my big question marks:

Security: This will always be an issue, because some will always seek ways to exploit others. Macromedia engineers have been dealing with security and privacy issues since the dawn of the popular web, but anticipation only goes so far, and there needs to be constant reality-checking against new exploitative ideas. For this to succeed we'll really need to rely on the distributed brainpower in the developer community to challenge us on any questionable areas. I think we're in good shape here, but it will have to be an ongoing effort.

Initial distribution: Any new technology has a chicken-and-egg problem. Breaking out of background noise is a significant task. If hardly anyone ever knows about even a single Central application, then this decreases the odds of success for all Central apps. Conversely, once someone uses a single Central application, then it becomes much easier for them to use additional Central apps. That initial attraction is key to overall adoption.

Publicly, there's not much I can say here in March about the later campaign for consumer distribution -- we're just open to developer-level access right now, and I can't yet speak about specifics of distribution paths, partners and so on. For your own calculations, please be aware that you should factor adoption rates into your overall plans, and also be assured that folks here inside the shop understood from the start that this is a vital issue! You might also consider the consumer awareness of Macromedia Flash technology, and manufacturer awareness of the desirability of bundling such ability, and the remarkable ease of installing Macromedia Central, and also that distribution details must necessarily be sketchy right now. This is an important issue, and not all cards can be put on the table yet.

Balance between server and client: All of us have worked on this problem with in-browser applications, but now we have to really bear down on figuring which parts of each application should be done on a central server, and which parts should be done in each client machine. Work done on desktop computers will have a different balance than work done on weaker pocket devices. Costs of incremental on-demand downloads need to balance against the costs of caching local data for offline use. Server-side aggregation has advantages and disadvantages compared to asking each client to independently pull from multiple sources. Should preferences be kept on the local machine for privacy, or stored on the server for use from multiple machines? With MX technology we have a unique ease-of-use in developing on both local and remote machines, but communally we haven't nailed down best-practices here yet.

Playing nice with other apps: One of the most exciting things about Macromedia Central is that actions can happen in the background -- your machine can do data pulls while you're working in some other application, and can present notifications to you if something meets your predefined criteria. But a greedy SWF can request too many system resources, tying up the processor or pipe or storage. The original developer may not get adequate feedback about how their work performs on a variety of systems, in a variety of situations. "Skip Intro" taught us how, if bad things could be done, then bad things would be done. The "politeness" of the first year's tools may have a big effect on how popular the overall technology becomes.

Breaking out into other parts of society: If Macromedia Central remains a geek tool, then I would have to think it a failure. Techy people are a key part of information convenience, but our work has no meaning unless real people actually use it. We've got to provide useful and unique abilities to businesses, kids, people-on-the-go, the technophobic, the nerdy, education, worldwide audiences, people with different sensory or motor abilities -- if we stay locked in our little geek town then we will not have gotten very far at all. Macromedia Central needs to solve real problems for real people.

Ethics of using data: I believe that many, if not most, of the popular Macromedia Central applications will make innovative use of live data requests. There is currently no easily-distributable mechanism for personalized applications which communicate with the rest of the world. But where does that data come from?

Web services are the cleanest shot here, because they're almost always associated with a clear terms-of-service. They're also the easiest to use. But distribution of web services is still emerging -- great momentum, but it has yet to achieve ubiquity.

People familiar with server-side languages may be tempted to use "screen scraping": parsing an HTML display into data objects. Most server-side languages already include higher-level RegExp functions to parse remote pages for their embedded data. The term is actually over 20 years old, when people did pixel-analysis of screens to turn presentation into data for other environments. Serverside screen-scraping can be helpful if data is only available from a site which does not yet offer web services, but you've still got to get the consent of the person who owns that data.

The current consensus on best-practices here involves a couple of simple steps: (a) check a site's terms-of-use to see if they already grant or deny permission for reuse of the data they present; (b) if in doubt, ask; (c) if you use another site's embedded data, credit them; (d) don't just skin... innovate, provide something uniquely useful; (e) avoid overuse of another server's resources... periodically cache data on your server instead of making a fresh request for each client, for instance.

Web services, XML feeds, HTML screen-scraping... all are valid, yet all can risk misuse. We're in the early days of exploring the ethics here, so it's important to err on the side of caution, and to be responsive to feedback as it arrives.

These topics don't concern me as much, but I know they'll come up in the developer communities, so I might as well type my canonical replies
here.... ;-)

"It should be in Director!" It's true that Director can do more than Flash, but the cost of this is that it's only possible on Macintosh and Windows computers. Flash is more portable and is already running on many more platforms. The big win is probably in pocket devices, which just don't have enough oomph yet to run Director. If you're skilled in Director, then you're actually skilled in interaction design, and I'd urge you to expand your abilities rather than rely on any single application to achieve all possible goals.

"You tried this with ShockMachine!" Two points to you for remembering history. ;-) ShockMachine was also a client-side host, which could store and play Shockwave or Flash files. Six years ago the ShockMachine shell focused on games rather than tools -- there was no economic model for individual developers -- there was no such thing as web services, and even XML was a strange concept, so the only live data feeds could conceivably have come from HTML scrapes. Many members of the Macromedia Central team had also worked on the ShockMachine project, and are well aware of things to do different this time around. The business model for content developers alone is a radical difference. The ShockMachine experience definitely helps, but this is a distinctly different case.

"Flash is just for eyecandy!" Aww, go back to Slashdot, gedoutta here.... ;-)

"I want to interact with other desktop applications, so security shouldn't be so strict." Sorry, no can do. It's easier to loosen up a sandbox than it is to tighten after people are already using abilities. To get distribution of the host we have to be reliable. If you need to manipulate arbitrary local files then Macromedia Central will likely not suit your needs. (Let us know what you're trying to do, though... we need to learn where the popular destinations are, thanks.)

"I know ColdFusion, and want to do this, but I don't want to learn Flash." uh, I'm constrained in what I can say right now, but I think there's a well-known need to enable other creation metaphors. Hang in there, that's all I can say right now.

"Macromedia should add a particular UI component to the default download." You're right, the more we can pack inside the shell, then the lighter each additional application can be. But the bigger the shell, the bigger the first download has to be. We're making our best analysis of bang-per-byte, but this is definitely one subject which will be refined over time. Frustration acknowledged; feedback definitely appreciated, thanks.

"Wow, this concept is just... so weird!" Yes, it's different from existing web development in a number of ways. The possibilities between choosing a foreground app, a desktop dashboard, a notification system or some combo of these in itself is a major new capability to consider. The communal aspects of multiple people using a communication application may be the most mysterious and hard-to-predict angle. From what I've seen of the architecture I'm convinced we've got great possibilities here, but the manner in which those possibilities will eventually express themselves will definitely require experimentation, communication, and consensus.

I've already typed 'way too much for you to read, and I realize I've left out a lot of the stuff that's been bubbling around inside me about this Macromedia Central initiative. I'll do a follow up column here very soon in what I've seen on the weblogs, mailing lists and other discussion areas. I'll open up an entry in my blog for feedback on this early word, and will definitely appreciate hearing what you have to say, thanks!