Monday, December 26, 2011

in defence of the flash IDE.

I develop online learning experiences for users. These tend to involve some kind of interactive UI that enables the user to view content and interact with it in the form of simulations, tests and assessments of some kind, and tracking/session management stuff aka bookmarking.

These experiences are generally one time experiences with little repeating.  They sometimes want to be reused extensively, but to me the quality of learning tends to go down with extensive reuse even though it does save some money.  I have had the fortune of working on projects that really push the envelope and make memorable and intriguing first impressions for the learners and have a proven rate of retention and ROI for my customers.  My latest opportunity at SweetRush as CTO is no exception, and Ive been able to work with some of the best folks in my career on designing and developing training content for some very impressive and demanding clients.

Although I can certainly build these projects using non-Adobe Flash IDE (Integrated developer environment), I really enjoy working inside the flash IDE because its where I started, and creatively its a wonderful tool to use.  I tend to write all my code inside the flash IDE on projects where I'm the sole programmer/creative and decouple the scripts from the artwork using simple includes on projects where I'm the sole programmer but not the artist.  I find this approach enables me to work very fast, and build projects that function reliably with few if any bugs out the gate.

My type A approach is fairly simple.  I use the timeline as a logical flow line (a hold over from my initial training in authorware)  Starting with the first few frames as preload/init frames, then dividing the user experience into what I call "action points" where some code gets executed to display some content, provide a small game or what have you.  Then users can visit the AP's in any order, loop through them incrementing a value (like using 1 AP to display a question, but using another AP as a count incrementing element that just loops back to the question display AP until all the questions are done, at which point it then moves to the next logical AP).

Then by the AP's , I can set bookmarking logic to each of them as well as garbage collection, necessary inits and component/class instantiation.   This allows me to use the timeline to visually layout the user experience and enables an animator who is unfamiliar with code but knows how to move keyframes around to have the ability to change the logical flow without editing code.  The flash IDE provides all the objects, the library of components, and types of symbols I can provide the animator to tweak, change or even discover how programming essentially works in an environment that is familiar to them.

As a general rule of thumb, if a segment of code in a particular AP becomes more than a few hundred lines, or that code is getting reused in other spots, it becomes clear I need to move that code to the first frame where I put all my globals.  I tend to have all the global variables, functions, and common data defining/parsing logic there. I also like to push all dynamic text and content URI's out to an external XML file that always gets loaded as a global to be used anywhere in the application.

I find the flash IDE endlessly flexible in this regard.  I can visually represent objects as movie clips each of which can be visual or not, and can carry out functions, or just hold functions for use by other movie clips or the main timeline.  Being able to make any code anywhere behave as a visual object definitely has its advantages.

Of course, one can write endlessly messy code that is nearly impossible for others to navigate in the flash IDE, so its important to be very consistent in keeping the library neat, the main timeline reserved only for logical flow and any artwork/animation to be encapsulated and contained to a specific and well labelled layer with instance names that allow it to be controlled externally.

Other advantages are the integration of the compiler in that you don't have to jump through several file settings or create elaborate folder structures with strict names on the computer to work, you can do it all inside the highly optimized work environment of the flash IDE.  No need to find compilers, and moving/renaming MC's or "classes" is all monitored and tracked by the IDE so there is no need to update paths.

All this makes for very rapid application development.  Provided a disciplined approach is taken, I have found one can use the flash IDE to make very flexible, very reusable and very powerful applications all with the built in power of handing the file to non-programmers to tweak art/animation/sound aspects within the same working context.

I think a primary perceived disadvantage is the reliance on the IDE vs being able to pull out the code and edit it using a text editor or source code editor of choice.  While there are hundreds of thousands of flash coders like myself who feel completely comfortable implementing what could be considered "valid design patterns" inside the flash IDE, I think there are also a lot of detractors who feel that the flash IDE represents a step backward or is a tool that does not have the capabilities of a tool like Flex, for example.

I would challenge anyone to building something in Flex that I couldn't build in the flash IDE, and have it work equally as reliably, and be equally as flexible and scalable, provided other coders had access to the IDE as well for the bits that were non xml or external script.

That said, I can clearly see a few issues / disadvantages to the IDE.

1. The IDE is too permissive, in that you can use untyped variables, haphazardly scope variables and functions, and put code anywhere making it difficult to find.
 - all of these are true, but they are not the rule.  Any disciplined coder can write bad code in any environment.  I think the need for discipline and neatness becomes heightened in the flash IDE, but I also think visually the ability to lay out an application clearly is greatly enhanced in a visual programming environment like flash.  Its not as literal as author ware where you had a literal vertical line and you could drop logical objects on the line with visual loops, visual branching all iconically represented, but its similar in power.

I think of it as the difference between looking at pages and pages of VRML textually representing a 3d model, or the 3d model itself.  If you can "see" the 3d model when looking at the code, wow, good for you...but you can't argue that actually seeing the 3d model itself fully rendered gives you a different perspective and often illuminates problems that a human couldn't possibly perceive when looking just at text.

That, to me, is the main difference.  I like to represent code iconically, and the flash IDE/timeline allows me to do that, and just as looking at a rendered model enables me to see the object as it is, so the IDE enables me to see what I'm doing as I'm doing it rather than furiously writing incredibly elegant looking code-all indented and outdented perfectly with inline class autofilling...I can actually see the end result, the user's experience, as I'm writing it.  (not quite exactly...but certainly closer than when I'm writing an app in Flashdevelop or some equivalent).

As a career coder I think its important to know a little bit about all the approaches, and to not think one is necessarily better than others as long as the primary stated goals are met, and try to apply best practices wherever they may apply across languages.  If I write in Ruby, Java, Python, C++ or what have you and can learn something from a timeline / visual developer then great...and vice versa.

So why so defensive?  I think that flash has branched out to make its technology more palatable and familiar to those coming from a traditional OOP background, and created Flex/Flash builder for that very reason.  The sense, however is that somehow meant that Adobe was "admitting" that the flash IDE was somehow a failure and that Flash Builder was the superior step in evolution of the product.  If that was true, of course, the flash IDE would have been phased out or at least severely "dumbed down" in order to push developers towards FB.  I certainly felt that way and it pushed me to learn to do strict OOP, embracing a class/inheritance/interface approach and writing some fairly sophisticated projects in flash builder.  After really getting down that rabbit hole I came out the other side thinking that there was a lot of what I considered unnecessary complication with that approach, and that while I thought it certainly made sense for some kinds of projects like the one I was working on for example, I didn't think it necessarily was the be all, end all approach for all projects.

One very interesting development is the advent of the javascript/html animation tool Adobe Edge.  Over the past couple of weeks I had to build a project using Edge with some serious tweaking and I found that even though the product is in beta, and its buggy, I really enjoyed using it and appreciated the ability to edit the source files and find most of my edits were retained in the IDE, with only a couple of minor exceptions. So far, Edge looks a lot like the flash IDE, the only notable difference being the timeline works in seconds rather than in frames.  But, like the flash IDE, I can place code on a timeline or all in one place at the beginning, reference external code, and use the timeline to trigger/organize events that can also be manipulated by animators.

I think the Edge tool, either merged with flash IDE or kept as a separate tool will ultimately continue the legacy and impact of timeline coders, perhaps to the ire of OOP programmers but I certainly hope to see more interoperability among skillets and disciplines rather than an eventual monoculture of development.

Finally, on a creative level the IDE enables animators to "see" code, and coders to "see" artwork. I think if animators stick to tools like illustrator and photoshop, they will never get "rich media".  I also think the same is true for programmers that wall themselves up in code.  The flash IDE is the glasnost, the common ground where folks from an artistic background and those from a programming background are forced to literally work in the same environment and gain a very intimate understanding of each other's work.  The best stuff I've seen in flash has been built by coders who were also amazing artists and animators, who really understood fluid motion dynamics, colour, font design, traditional animation technique, photography, bit mapping, sound editing and mixing, and of course were excellent programmers who really had a grasp of OOP.  While these "one hit wonders" are tough to come by, I think the flash IDE provides the opportunity for a collective to "get inside each other's heads" and become that one mind that can then, collectively, become more than any individual team member can.

1 comment:

  1. Great article Ryan, I've not tried edge yet so I can't comment. But you are spot-on in regard to Flash IDE in a collaborative work environment. Your technique in using preload/init frames, then dividing the user experience into what you call "action points" where some code gets executed to display some content was one of the greatest lessons I learnt from you.

    Keep writing, you've got a lot to give :)

    ReplyDelete