Looking back at the past week, it is very apparent that some big changes are in store for Flash although it was strikingly obvious to me that innovation will come from the community and not from Macromedia.
MAX was a great conference, not due to the sessions, but from the great developers in attendance. I learned much more from the community, the core Flash development team, and the late night coding sessions than from any part of the conference. I had the pleasure to meet many developers and discussed development problems and related issues with them. I look forward to keeping in contact with everyone I met at the show, I had a great time. Thanks! ;)
One of the hidden trends at the show was that allot of developers are struggling to adopt Flash for business development, RIAs are not easy to build! In speaking with many developers after my sessions and in the development forums, Flash is very difficult to understand if you have not evolved with the medium. Although we have shiny new features in AS2 , new components, standards support, and a better IDE, we are still bound by a lack of understanding of what happens at runtime. Behind the all these features are a set of simple datatypes and structures in the player that have been present since the pre Macromedia days of FutureSplash Animator. Choosing to ignore these basic rules and you will struggle with Flash, it is just that simple. Here is an example I used in my session on “Component-Oriented Development with Flash”:
trace(_level0.ted + ‘ ‘ + _level0.ted.getDepth())
//Data precedence over MovieClips
_leve0.ted = 101
The key here is that if you fail to understand the differences in MovieClips and Object Data at runtime, you will fail to build effective component applications as a simple error will render your application useless. These errors are due to path processing at runtime between the object data and movieclipDatatypes and all fail silently in the new MX 2004 IDE. These issues need to be addressed so that new developers will not be hindered by these low level problems. I also think that Macromedia and the community should more openly disclose the details of the interpreter at runtime. It is one thing to make the swf format open, but quite another to explain bytecode effects at runtime (not that everyone wants to know but some of us do!). Even now, this is a dark art and limited to a handful of developers inside MM and a few in the community. Only when you understand an actions effect can you effectively solve a larger problem. Give the community some insight and we many find the state of Flash is moved forward dramatically.
One solution to this problem is to add a new development paradigm hence FLEX (Royale). It seemed like lots of developers are pinning their hopes to this “newest of new” server but I remain firmly skeptical. I went to all of the FLEX sessions, asked some hard questions, and saw some subtle problems that are a bit scary from my perspective.
1. SWF output files are huge (1MB+). One of the demos at the show was 2+MB! Think Intranet not Internet delivery!
2. FLEX imposed changes on V2 components. We received FAT components due to FLEX compatibility(SWC).
3. Components are bound into the one big SWF. This is the same mistake that LASZO made and support for progressive loading will not be included until a version 2 release. There are ways to solve this problem today that are as of yet unexplored.
4. Expensive, $5,000 to $10,000 per CPU! WOW, I thought generator was expensive.
5. F7 support only.
6. Most of FLEX 1 can be done client side in the player today. This killed generator as a product.
7. Lack of support for remoting.
In the meantime, I am looking elsewhere. Turbine 7 looks promising as does Kinetic Fusion’s latest release. If you walked away from MAX thinking FLEX will solve all your problems, be careful. Version 1 releases have a tendency to be a very bumpy ride and will not always fulfill your expectations. I am not sure I would recommend it as a consulting solution but that is just my opinion on the matter. Seeing as things will be optimized prior to release, conditions may dramatically improve but I am not holding my breath. I am sure rich media will penetrate the enterprise, but its development may not come through FLEX.
I had the pleasure to meet several members of the core Flash development team. I sat down with Gilles Drieu and talked about a myriad of issues in Flash MX 2004. Based on our conversations, I would expect to see some great things come from Gilles area in regard to designers/animators. Your in great hands as Gilles is an absolute professional and dedicated to making the graphical aspects of Flash a top priority in the next release. We discussed project workflow and some of the issues related to team development especially integrating design into development (skinning, version control, External Libraries). Thanks Gilles!;)
I talked to Mike Chambers about Central and he fundamentally changed my opinion about the product. Central’s value is subtle and is very easy to miss. Unlike internet applications, parts of Central apps run all the time vs running only when I visit the web page. With all other internet applications, I must do something to use them (Remember the service, Enter URL, Use application), with Central the information comes to me with no effort. Mike explained that after a long period of use, Central provides much greater value in that agents provide updated information and alert you to changes in data. Considering that I missed the big reason Central was important, I am sure there are many still pondering its development. Central is important as it shifts execution of short term (browser) applications to a long term process on your local machine combined with seamless installation and updating. You are now talking to the converted, Central rocks! Also Kudos to the Central team for the great API poster and the naming changes in Central components and SDK. Mike your efforts have made the SDK easier to understand and easier to use. Sorry I was such a nagging A-Hole about Central, I didn’t understand it, and I stand humbly corrected. Thanks Mike! ;)
In speaking with others, I gathered that the MX2004 Flash release was internally problematic at Macromedia. A couple of developments made the release what it was. Here are a few of the issues:
1. MX Studio common release date (Dreamweaver, Flash/Flash Pro, Freehand, Etc). Flash was a very ambitious release adding a myriad of features, yet every studio release product was required to share a common deadline. Personally, I would have rather seen MX2004 launch at at MAX, than to have received an unpolished product. Uncouple the Studio product and release Studio MX like a mini-DEVNET (online), the products will be of a much higher quality and developers will upgrade as their key application is released. Ideally marketing and development both win as software quality improves!
2. FLEX imposed late design changes on the component architecture for MX 2004 as the products were required to share SWC components. Also the V2 component architecture added string support to allow FLEX to do its job. Instead of receiving an improved model, we received a model intended for use in FLEX and not optimized for component development with Flash MX 2004. The components also had to be usable for V6 of the player making the common design even more difficult and more convoluted.
3. The team had to rebuild most of the IDE functionality in XMLUI on the JSAPI foundation. Not an easy task, especially with the high expectations of the tools given prior Flash releases. This dramatically increased the work the team needed to accomplish as every panel, control, GUI element needed to be rebuilt in the Dreamweaver API model. This was a massive change in the IDE and compounded all aspects of the release.
4. Core team members departed the company and key developers were shuffled around mid-project.
Talk about a tough set of requirements. Given the circumstances, the Flash team did an amazing job. I question management’s and marketing’s judgment on pushing the team this hard and imposing dramatic changes (FLEX) late in the development cycle. I would much rather get a solid release than a pile of new features, quality not quantity. Hopefully management and marketing will listen to this request as they screwed up the Flash MX 2004 release, and the development team saved the release through hard work. The dev team deserves allot of credit in doing their best under difficult development circumstances and for providing a solid update to the release. Thanks! ;)
Another interesting presence at MAX was that of IBM. At the keynote, sneaks, and at other parts of the show, IBM was very present, listening, watching, and waiting. Actually I spoke with several IBM engineers at the show after my session, it was most enlightening. As MAX rumor has it, MACR has been hiring IBM Lotus Notes engineers and some of them are responsible for architecting V2 components and parts of FLEX. Even more amazing is that IBM is adding development support into Eclipse for FLEX. It is not very often that a 152 Billion dollar company caters down to a 1.3 Billion dollar company without an agenda. This is a clear sign of things to come, Macromedia has become an acquisition target as the leader in rich media application development. IBM and Microsoft have obviously taken notice. When enterprise software purchasing takes hold again, we may see some consolidation in the industry that profoundly affects Macromedia. From my perspective, the writing was on the wall at the MAX conference, it is just that simple. Although, after seeing the IBM engineer at the sneaks, merging corporate culture at IBM and Macromedia should be very interesting to watch.
Not that any of these items change the Flash opportunity, but we will see some amazing changes in the coming year. Although I expect the community will provide an order of magnitude more innovation than what I saw at MAX. Some things never change. ;)