Central is important to developers for a number of reasons. First, Central provides an application framework with which you can sell the applications you make. You just have to add a few purchasing details to an XML file and edit a Web form. Additionally, the user is presented with information about how to purchase. Considering Macromedia's current deals with companies such as Intel and AOL, you can be sure that your applications will get exposure.

The evolving Flash Player will do better on the desktop than within the browser. There are fewer restrictions and a lot more room to add features and internal APIs developers may want or need. The politics of ubiquity rule the overarching plan of the Flash Player's development in a Web environment; you don't have those restrictions with Central.

Central makes deployment scenarios much easier. With Central's built-in App Finder and Free Finder applications, users are more likely to find your applications. Additionally, you know exactly what technology your end user has; currently Flash Player 6.0.65.0. There are no diversions from these specs, the only difference is OS. It's nice to have such assurances in development, as any developer knows.

But to really understand what Central means to us, we have to look at the history of where Central came from, including the problems Flash application developers have had in the past, as well as where we're going.

For an application developer, the browser is pretty lame. If you look at the history, starting with when the Web hit, a lot of application developers turned into Web application developers. Whether it was for back-end ASP/PHP/JSP coding, Java applications (and all the flavors), or copious amounts of JavaScript/DHTML, application programmers had a new playing field with many avenues to explore and a lot of uncharted territory.

In the multimedia realm, the CD-ROM revolution made us aware of what was truly possible using all of the media disciplines (design, audio, video, programming) together to create unique and powerful interactive media. The push for the Web wasn't as easy, mainly because of bandwidth.

Even so, there was still a lot of interactive, offline work that application developers could do utilizing a lot of artistic media. Whether the range was a simple, interactive brochure for a kiosk, or a full-blown interactive application that may even have had Internet connectivity, Director was one of the few authoring programs that allowed you to merge the best that media could offer. However, as companies desired easier exposure to their customers (but with all the functionality) the plug-in wars got pretty harsh. Basic rights were violated, and IT tightened the noose of security - and for good reason. This made a lot of technologies inaccessible to a lot of people.

Enter Flash - this plug-in is everywhere. It is a cross-platform, lightweight media tool with which many people can view and experience whatever the creators make. You can create animations as well as applications on the same plug-in. Although Director has a great plug-in, even as a developer, I've had a lot of trouble getting it to work on anything even remotely associated with a firewall. Call it user error, but I haven't been able to get it to work easily - who's at fault doesn't matter. Flash, on the other hand, is very easy to install, and in many cases is already installed. This ease of proliferation has enabled a vast amount of the connected world to view Flash content.

Flash has been capable of connecting to outside data sources via GET/POST operations since Flash 4 and via XML and XMLSocket since Flash 5. With Flash 6 came Flash Remoting as well as the Flash Communication Server, built-in Central installation functionality, Web service code modules packaged with Flash MX 2004, and dynamic sound and video, all with the same real-time pixel-to-vector engine that can scale your content, and all running in a secure sandbox. From a multimedia standpoint, whether for creating rich media ads or Web applications, Flash is the way to go.

But Flash can't go much further in its current environment. Considering all the factors working against innovation in the IE browser market, Microsoft's attitudes toward browsers and browser applications in general, and the challenges of integrating with a new barrage of browsers, the Flash Player has many challenges to overcome. Challenges like allowing Flash to easily respond to "next" and "back" navigation, in all versions of IE that are realistic (and who determines this?), as well as Mozilla and friends, and the *nix flavors.

It's really about attitudes. Microsoft dropped development of IE for many reasons, but look where they're headed. Their prominent emphasis in Longhorn, and its development platform Avalon, is to create Web-connected applications that can be occasionally connected. This applies to laptops and devices such as PDAs and phones. There was a time when the push for win32 and Web applications as two product offerings was key to success and survival in technology. Studies show that a large portion (80% in some cases, but I never trust statistics) of Internet users utilize that connection without a browser. Applications that are connected have a lot more freedom outside the browser, not just in functionality, but in room to grow and adapt. Microsoft's enhancing their OS and allowing applications to access that rich GUI, as well as the classes they used to create it, opens a lot of doors for developers wishing to get into the rich GUI market. Flash, as its current IDE stands, is somewhat challenging to existing developers. The flair that Flash can offer, as well as its integration into disparate systems, makes it ideal for putting a nice face on applications - the issue lies in getting comfortable. The advent of Flex from Macromedia will definitely open the doors for enterprise application developers. Interestingly, I've read reports that a lot of smaller-time application developers feel they too would like the workflow of Flex. From how the initial offerings work, the Microsoft XML format and Macromedia's looked exactly the same in my eyes; one simply used ActionScript where code needed to be written, while the other used C#. Even the syntaxes were amazingly similar.

Macromedia, too, realizes that if they want to offer more benefits to developers, they cannot unnecessarily bloat the Flash Player with features comparable to Microsoft's current Smart Client. From a developer standpoint, one of the great successes of the Flash Player was its proliferation to a lot of platforms and devices because of its small file size and lightweight implementation. Additionally, it's getting harder and harder to support each and every browser intricacy and still have the player operate and function the same on each platform without spending unrealistic development time or unnecessarily bloating the Flash Player to deal with these various discrepancies.

This is where Central comes in. The OS is our playing field now, instead of the browser. And by being freed of the chains of functionality and file-size restraints while retaining a secure sandbox, it has room to grow where we want it to. In contrast, because of the mess created on the Web by the lack of standards and the lack of applications following those standards, people have learned and have started following standards, which doesn't leave a lot of growing room. Going against the grain to push the envelope of design and media is now Okay only if you validate - lame.

My subjectivity is born of the fact that, during college, I chose the Director application route over Web design, merely because there weren't a lot of rules I had to follow. As long as we didn't crash your computer, the playing field for the team of designers I worked with was wide open. This allowed for a great number of custom-built solutions and great flexibility and creativity. Flash initially offered this on the Web, but as more functionality is needed from a programming standpoint, it's hard to deliver much without stepping on some file-size or nonubiquitous toes. The Flash Player on the Web has reached its breaking point in terms of what we can add without significant tradeoffs. Flash, already maturing into a really great development platform, saw the rise of some third-party applications to extend Flash where it was lacking in the desktop environment. Screenweaver, SWF Studio, etc., all offer ways to easily give Flash functionality that the player was lacking, such as reading the local hard drive and saving a text file, as well as additional APIs, some custom created by developers. As most of my work was in the application arena as opposed to Web, these programs were, and still are, invaluable.

This isn't saying Web applications are bad or are going away. Rich GUI applications that people can use from anywhere with a Web browser and an Internet connection is a powerful concept. However, for people like me, who don't like dealing with browsers and all the fun little problems that Web developers and designers deal with day in and day out, a set platform is required. If you're a .NET developer, you get the .NET Framework; they also have one for devices. This is extremely cool for .NET developers, but what do Flash developers get? Originally, the same player with minor security restrictions freed. If you wanted functionality similar to what desktop apps had, you had to use a third-party application or Director. Now, we have Central. Just like some .NET apps, it has one-click installation. It also has built-in UI controls and a plethora of built-in APIs not offered in the Flash Web Player.

It's important to focus on where we're going, not where we are. Central, in its initial incarnation, is strictly for developers to get comfortable developing in it, as well as to provide Macromedia with the feedback it needs to better morph Central in a direction that is somewhat congruent with our Flash application development needs. We Flash developers now have a platform that has more potential for growth and the ability to adapt to our needs more easily and quickly. Not only that, but users can be upgraded more easily along with the applications that we deploy to them. Think of Flash with hardware acceleration and easier access to OS-integrated features. These are all possibilities depending on community need.

The really good stuff is yet to come. Once Macromedia starts marketing Central to the user base, packages it to places of great exposure (crossing fingers), and implements the AOL IM API (as well as related packages such as ICQ) along with some of the Breeze Live APIs for pods, Central will be a seductive platform to not only develop to, but also to sell applications on.