1. Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff).

   One of the largest challenges when moving from Web 1.0 applications to the RIA’s development paradigm is learning to think differently. Flex gives developers an advanced component library that allows for doing things that simply weren’t possible only a few years ago. Often, the power of Flex is missed, and the framework is used to implement more traditional Web 1.0 applications.

   Building Web 2.0 applications is more than partial page refresh and rounded corners. For example, Flex developers should be using vectors to provide users a visual understanding of data, and advanced controls for a rich application flow.

   Stephan Janssen discusses this struggle recently with InfoQ.com:

   “As a Java developer, learning Object Oriented ActionScript and the UI markup language is really a walk in the park. The challenge however for (Java) developers is that we’re not designers, and with RIA technologies these two skills are very much needed.”

2. Breaking standard browser experiences.

   While Flex does provide an excellent platform for improving the user experience, it is still important to maintain familiarity of things like the back button, book marking, and auto complete.

   Flex 3 includes new Deep Linking features for back button support and book marking. You can learn more at labs.adobe.com. There are a number of components out there for implementing auto-complete. From the Adobe Exchange, you can use the AutoComplete Input component.

3. Slowing the application down with the use of too many containers.

   Flash Player uses a hieratical display object graph, similar to the HTML Document Object Model (DOM). The deeper containers are nested the longer the rendering takes. Adobe’s Flex Developer Center has an article that covers best practices related to Flex performance, including the use of containers in detail:

   “The biggest Flex performance danger is yielding to the temptation to use containers randomly. Deeply nesting too many containers hinders the performance of your application. This is the number one performance danger that Flex developers succumb to—and luckily it is 100 percent avoidable.”

4. Slowing the application down by using XML for data transfer over optimized protocols.

   Flex offers developers a number of options for data transfer between the Flex client application and the server, including AMF3, XML, SOAP, and straight HTTP requests. Ward demonstrates the use of these technologies and performance benchmarks in his Census application.

   BlazeDS should be considered for Greenfield projects using Java on the backend. BlazeDS is Adobe’s recently open sourced Data Services product that uses the AMF3 protocol. AMF is a binary transfer protocol that is easy to integrate with Java, and offers significant performance benefits over XML. There are open source implementations of AMF for every major backend technology.

   If BlazeDS is not an option, Hessian could be an option. Hessian offers ActionScript/Flex support for their binary web services protocol.

5. Trying to hire Flex developers.

   Experienced Flex developers are very hard to find right now. Flex is at the point in the adoption curve which Java was at in the late nineties. The demand for Flex developers is exceeding the supply. This makes finding experienced Flex developers difficult. This, however, creates a huge opportunity for Java developers to expand their skill sets and work with a fun emerging technology. Many companies looking for Flex developers have great success training Java or other web application developers for only a few weeks on Flex. Flex’s language and APIs are easily learnable by developers who are familiar with web and GUI programming.

6. Overuse of animations

   Using Flash as the runtime enables developers to easily add animations and effects. However, developers should make sure that the animations have meaning and provide context. Otherwise, they will annoy users. The timing of animations is also important. Interaction designers can help make recommendations on when animations should and should not be used. Interaction designers can also recommend the best type of animations, the duration, and the best easing function.

   There is good a post on the use of animations at laair.org:

   “Most animations are simply TOO LONG. They are long, and slow, and boring, and excessive. Tone it down. If there is one thing I have found, it’s that I hate waiting for stupid animations to finish so I can do something else.

   Don’t get me wrong that I am not bashing animations. I am simply bashing animations that are simply too long or too extravagant for their purpose. Every animation can be broken down to having a purpose. Figure out the purpose of your animation and apply accordingly.”

7. Not setting up an enterprise ecosystem.

   As with other software projects, it is important to set up an enterprise ecosystem for your Flex applications.

   Test Driven Development (TDD) is a staple of most enterprise project in this day-and-age. For Flex, the FlexUnit framework is available for coding unit tests. On Adobe’s Developer Connection, Neil Webb discusses TDD for Flex developers and using FlexUnit. In addition, Flexcover is available for code coverage reporting.

   Continuous Integration (CI) is a proven practice for building cohesive applications when multiple developers are contributing. Similar to Java applications, both Ant and Maven plug-ins are available for CI builds of your Flex applications.

8. Not using the entire framework.

   There are a number of optional features available in Adobe Flex that you should consider using in your applications. For example, Runtime Shared Libraries (RSL) is available for reducing the size of your applications:

   “You can shrink the size of your application’s resulting SWF file by externalizing shared assets into standalone files that you can separately download and cache on the client. Multiple Flex applications can load these shared assets at runtime, but each client need only to download them once. These shared files are called Runtime Shared Libraries.”

   Another underused feature of the framework is the built-in accessibility features. You can read more about the accessibility features of Flex in Adobe’s livedocs. In addition to built-in accessibility, the framework provides built-in features for localization. For the latest Flex 3 framework features, checkout Adobe’s Getting Started introduction page.

9. Slowing the DataGrid down with complex renderers.

   The out-of-the-box itemRenderer for the DataGrid is very optimized. Mistake #3 discussed the performance impacts of deeply nested containers. One of the places in Flex where containers can easily get deeply nested is in the DataGrid’s item renderers. The number of item renderers which are rendered by the DataGrid is the number of visible rows times the number of visible columns. Custom DataGrid and List item renderers should be very optimized. When complex layout logic is needed in an item renderer, it is best to use UIComponent (or other more low-level classes) and position the contents for that cell manually.

10. Not preparing for offline applications.

    The traditional model for RIAs is in the browser. However technologies like Adobe AIR and Google Gears are allowing those applications to run offline. By not preparing for a potential offline architecture when users demand it, changing your applications to support offline features may be very difficult. Typically, in web applications business logic lives on the server. In offline RIAs, business logic must transition to the client. This makes it necessary to architect ahead of time where certain business logic will need to live in order for applications to work both offline and online.

Unless you have been living in a cave, or in the far hinter world of HTML 3.2 and Framesets, you have no doubt heard about Flex recently. As a ColdFusion developer, should you care about Flex and why? Two years ago: No — Flex 1 and 1.5 was/is an over priced monstrosity. Created for the uber geek at large corporations who coded fancy web services in an object oriented fashion and who had a need for a $15K (U.S.) per CPU application server, most typical ColdFusion developers had no need and little interest. Now: Marginally — Flex 1.5 is still impractical for most people and projects; version 2 hasn’t even been released. Just as importantly, the user base of people with the required Flash Player 9 installed is approximately zero. Implementing a solution now isn’t practical. In the future (6+ months) - YES! …and here is why:

1. Ubiquity — Approximately a year from now, a large percentage of users will have Flash Player 9 installed (thereby enabling Flex 2 compatible applications/websites).
2. Changing expectations — Just as HTML 3.2 with framesets has been relegated to the past and replaced with HTML 4 and now CSS, more and more employers, customers, and website visitors will expect to see prettier and more functional websites, intranets, and customer facing applications.
3. Changing technology and competition — A certain percentage of the CF developer base can and will continue to work with simple HTML based sites. It is currently easier to do, more compatible with the end users, inexpensive, and more importantly for many, what we know and what our employers and customers are happy with. However, unless you as a developer want to be relegated to the obsolete junk heap, you better upgrade your CF 4.51 installation soon. A select few will continue to make a living or get their work done on old systems, but this is getting progressively more difficult. After all, how many of you are using DOS, Windows 3.11, or COBOL on a VAX Mainframe?
4. It is the direction Adobe and the industry is moving — ColdFusion isn’t going away. Learning the basics of Flex 2 development does not mean altering the course of humanity forever. Thankfully, ColdFusion is currently growing, well supported by Adobe, and best of all, intentionally upgraded to work well with Flex 2 applications. We will continue to be able to use ColdFusion exclusively in a large number of applications. However, just like we have been encouraged (I know, many of us have not changed fully yet) to drop the use of table tags in much of our layout code, replacing it with CSS, we will be encouraged to drop much of the HTML from our code and replace it with Flex-based front ends.

Let us use the disliked (rightfully so) cfgrid tag as an example of how the expectations for user interface have been changing. Up until CFMX 7, the grid was Java-based and was, by Allaire/Macromedia’s own admission, slow and limited in features. Little was done over the years to enhance the tag, until finally in CFMX 7, when support for Flash was added in addition to Java. After six major versions of the cfgrid tag in ColdFusion, when was the last time you coded a cfgrid tag? Have you EVER seen it used on a public facing website? Flex 2/ColdFusion 7 and Scorpio - The Flash Player (9) has been rewritten to finally handle the loads and complexity that grids require. Flex Builder 2 will make designing the grid (resizing, skinning, populating) easier. ColdFusion will be able to use the data submitted and using the new Mystic update (now in beta) will enhance the Flash Remoting capabilities. The advent of Flex 2 can and probably will be a major turning point in the life of ColdFusion applications and websites as a whole. Websites will no longer be tied into a straight HTML interface. AJAX functionality is being released that will allow developers to make HTML pages that react directly with Flex based objects in the browser. Should ColdFusion developers be worried about their jobs? Yes and no. Yes, because their jobs will change. Their HTML skills will slowly become obsolete. The expectations for websites will change and developers will be forced to learn new skills (Actionscript 3, MXML, Flex 2 development, Asynchronous calls to the server). No, because their ColdFusion skills are complementary to the new trend. The server side skills will still be applicable and the learning curve to use the new Flex 2 feature sets will be much less extreme than Flex 1 and Flash Remoting (in many cases). The financial and time investment to begin teaching yourself the new technologies shouldn’t be too large and Adobe is trying to make this easy. Steps you can follow to begin the transition from HTML/CSS/CF centric development to CF/Flex 2:

1. Read the blog entry by Damon Cooper and watch the following 11 minute Dean Harmon demo. (Please try not to drool on your keyboard… Notice the use of the grid?)