Barklund.org

I will try to explain my views about best-practice Flash development for rapid prototyping – and why Soft Coding and Scripted Layout is bad for everyone. The argumentation is partly based on this article from Daily WTF, that I have enjoyed and recommended to any and all developers. But when it comes to Flash a whole other possibility of Soft Coding comes into play, namely Scripted Layout, which is the practice of adding items to stage in script only with position, sizes and other parameters specified in script or external sources (e.g. XML, database or other source). Scripted Layout is a terrible waste of time and effort and completely undermines the power and flexibility of Flash turning it into a language-wise weaker version of more mature (but graphically challenged) programming environments like C# or Java.

Let’s just start by repeating my main point:

Defining all graphics and especially their position, size, color, font, etc. in ActionScript only is a waste of time and undermines the power of Flash.

My main argument for claiming this is:

• It is easier to change the layout of a page, when you can visually see the elements on stage inside the Flash authoring environment and moving content, aligning pieces to each other. These possibilities and this overview is not achieved if you can only move content by changing pixel values in a script or configuration file and testing the result.

My secondary arguments are actually counter-arguments to what I have heard from the opposition, about why Scripted Layout is good:

• It is a cleaner and more “mature” coding practice. It proves that Flash is not just a tool for the visual artist, but for the “real” programmer as well.
• It is more flexible and much faster to update. All information about position, layout and sizes is centralized in one place and can be edited here.
• If doing visual layout in the FLA file and working multiple developers on the project, only one person can use the FLA file at a time, and thus only one person can layout, which results in more complicated collaboration.
• My framework works this way.

The worst argument is of course the last one but it is surprisingly common to hear. I won’t even go into discussion about that, because if you can see, that the other arguments does not hold up, you should see that you really need to find a better framework.

The best argument is the third one; it is a valid point, but I feel that first of all this can easily be avoided by having a good team discipline, but also that the benefits of this does not outweigh the cost.

“It is more mature”

This is somewhat a matter of pride, a matter of using a graphical tool for the visual parts of your application seems wrong somehow, seems un-geeky.

Flash originated as a graphical tool exclusively, in Flash 4 the scripting part became somewhere bigger (and this is where I started) and in Flash 5, us programmers could suddenly do a whole lot – but everything was still built around the Flash UI and the structure put forward in Flash. The first frameworks started appearing back then for doing structured programming using simply prototype-inheritance (I especially remember Robin Debreuill’s classic OOP guide).

Since then, Flash has come along way, and the whole Flex line-of-thought is based on the belief, that more “real” programmers (with backgrounds in VB, Java, C#, C++ etc.) will join the Flash movement, if Flash production uses a real IDE and not Photoshop with a scripting panel.

But why should that stop the rest of us from using Flash the way it works the best (for us)? When creating design-driven applications like campaign websites, games, company profiles etc., the possibility of having the designer look over your shoulder while you align elements or even have him/her edit the FLA file directly because of changed designs is a real benefit. When the development cycle is very short, when decisions are made up until 3 seconds before launch, when everyone is pulling you in different directions, having graphical control of your layout seems way more mature to me, than boxing around with configuration files from here till Styx.

“It is more flexible”

This is a direct application of the “Hard Coding is bad, Soft Coding is always better”-belief, that many programmers possess. And the exact focus of the Daily WTF article, that I referred to earlier.

The claim is, that when you have the x and y coordinate of every object in one single place, you can very easily change multiple of these. Well, that is true, but when are you going to change these variable and how do they change?

One common cause for changing positions of graphical elements is that the graphics have been updated. The designer created a new logo, and new headline, a new background image and so on, and the new element has a different size and things just need to be re-aligned. In this case, you would need to look at the actual elements to see how they should be realigned and only having and XML file to do it would be weary path, having to change the coordinates, test out the file etc.

Another cause for having to update the layout is changed requirements. Maybe your designer, the client, some user or any other stake-holder suggested, that the contents of this-and-that page should be centered, right-aligned or changed in some other quite simple way (when using a graphical tool), but quite a challenging way when only having a configuration file. Of course you could the extend your configuration language in order to allow for specifying items to be aligned centered with respect to some other element and so on, but then you walk down the never-ending path of building a layout markup of infinite complexity, that when this project is done cannot be used for anything else (as it supports your project’s custom properties of content being “about page” aligned, which is a special mode needed somewhere) and no-one but you know how to edit or update the file. And in about 2 weeks time, not even you know how to update the file.

Thus, if flexibility is a requirement, use the best possible and most flexible tool for creating layout – the Flash graphical user interface provided by Flash CS4 or likewise authoring environment.

“It is better for teamwork”

This is a valid point. When not using Scripted Layout, that FLA file is necessary for the developers to a greater extent – and as FLA files cannot be easily merged, only one developer can use it at a given time and collaboration must thus be much better coordinated. In high-tension situations this exact issue can be the cause of major problems including “but I already fixed that”, “who has the FLA file – I freaking need it now!”.

But this issue can actually be solved by using FLA-files intelligently – and their resulting SWF-files. As you do not need to have everything that can blend together on stage in the same SWF-file (as you did in the good old days before addChild() and re-parenting), you can have separate pieces of content in different SWF-files (originating from different FLA-files) and simply load the all at run-time or build the FLA-files to SWC’s and import the assets compile-time using the Embed meta tag.

In conclusion…

In conclusion my summary is the same as my initial claim: It is easier to change the layout of a page, when you can visually see the elements on stage inside the Flash authoring environment and moving content, aligning pieces to each other. These possibilities and this overview is not achieved if you can only move content by changing pixel values in a script or configuration file and testing the result.

If you in any way feel you have further arguments in either direction, feel free to comment.

Related posts:

1. Using AddThis with Flash
2. Minor change in handling NaN positions in Flash Player 10,0,22
3. Announcing MXHR4AS3: Multipart/mixed-file download by Flash clients