It seems that recently people, good people, are coming out of the woodwork to point out that they might not always like to deliver their Flash Platform solutions as OO solutions. I hear the collective gasp of horror and revilement from the community of Actionscript developers who have spent years refining their coding and OO methodologies to a point where they can code in Java with little effort. I myself am one of those coders. However, I am forever using the term ‘Pragmatic’ when I speak to staff and peers alike. Look at the big picture. Not everyone wants a solution that takes 2 months to deliver because you have to develop redundant, reusable, unit tested OO code. Many clients want throw away solutions and have no likelihood of code reuse. The problem is that we’ve become enamored with the idea of perfecting and using only code. Anyone who speaks of the timeline does so with contempt and some even call for it’s removal altogether, suggesting that it is the province of antiquated, knuckle dragging wanna-be coders. Not like us ‘real’ coders.
Well, let me stop you right there. It could equally be argued that components are the province of lazy or just plain bad coders who won’t or can’t do the code them selves. Of course this is not true, or at least it’s not true of well written components. They serve to reduce development time, simplify solution requirements and yes, in some cases, allow less skilled developers to produce the same results as highly skilled developers whilst learning better coding practices at the same time. No one disagrees with the use of components for all these reasons, in fact they extol them. Interestingly, the very same arguments can be used for the use of timeline solutions, where timeline solutions are appropriate and employ their own best practices. How then can this be a bad thing?
As is being pointed out a lot recently, Flash/Actionscript, is NOT java or C#. It’s getting there, but let’s not forget that it has it’s own unique, inherent strengths and believe it or not, the timeline is one of them! Let’s not abandon the old strengths of Flash / Actionscript for the sake of the emperor’s new clothes. Using OO based code solutions when appropriate and timeline when it’s pragmatic allows us to produce the right work in the right time for the client’s requirements. This is an example of good process at work. Flash is an amazing tool, capable of an entire spectrum of solution options. This diversity of solution options is a strength, not a weakness. If you want to be a Java developer then by all means be one, but if you want to be a Flash developer then extol it’s great diversity of strengths, from full on OO to timeline. Don’t be cajoled into admitting that Flash is a glorified coloring in tool by code snobs. Tell them they’re wrong! We can produce the same solution in 2 or 3 equally valid and completely different ways. Imagine how hard it would be to produce a coding tool that actually allowed for all 5 members of the Dreyfus Model of Skills Acquisition to operate. I seriously believe that there is no other software tool that does this. It should be celebrated with pride, not hidden in shame and though many of us use best practices, good process and pragmatism to produce the right solutions for our customers actual needs, Flash’s diverse solution palette is all to often reduced to just OO class file options in an effort to look professional.
Adobe need to stand up and support their huge Flash developer base on this matter to. For to long they have pushed Flex as the right choice and insinuated that if you prefer Flash then you are a Mickey Mouse developer. The reality is that we have all options and can help developers from novice all the way through to expert. I’m not condoning using the Flash API for coding as Adobe have failed to improve their actionscript code panel in line with their Flex one (some might say this was deliberate).
Yo!…
Really feeling you on what you said about the time line. I use timelines alot. I can’t even begin to count how many frames i’ve chewed over but my point to what will be the relevance of Flash if it was just an authoring tool for just programmers? Imagine you have to write about a mountain code just a create basic movement. Developers calling for the removal of the timeline suck BIG time(line). Just because i use timeline doesn’t demean my skill as a designer or developer for that matter. Remove timeline and be prepared kill Flash as the top animation authoring software in the market. Too hell with best practices, what the client wants is effective solutions
They (OO dev.) would be nothing without us the designers who hug the timeline and make sure everything works strait.
As designer / developer I find it odd to hear this from a “developer”, I thought the timeline was there just to animate with not code by – to this point you haven’t articulated anything other than an unjustified view of.. “pragmatism” which to be honest sounds like I don’t really get this AS3 thing – Have you used Flex on any mid to large feature rich projects?
Having to go through someone else flash work to make minor amends or functional changes is often a nightmare something that has reduced to some degree from early Flash 4 onwards, thank goodness for the changes in the MX release, this has been down to improving practices as well as a reduction on the reliance on the timeline.
As a designer yeah I like the timeline to create the special online brochureware solutions. As a developer its pointless and makes life harder no matter how much cajoling and pragmatism I try and delude my opinion with.
Sorry if this sounds harsh, just thought we were in 2009 and moving forwards there have been moves taken over many years to have two version of the Flash IDE, which in some respects we do now in regards to Flex & Flash – Flash can keep its timeline but lets make it even more designer orientated … but isn’t this also where catalyst is sitting? perhaps we really should have the products rebranded to Flash Brochureware and Flash RIA.
Well there’s my 3 pence – for what its worth.
Flabby
The timeline is a fantastic tool for designers. While I’ll be the first at any party to acclaim the benefits of OOP and Design Patterns, it is silly force your artists and animators to employ those techniques. When you try to force someone who is not primarily a programmer to write OOP, you often end up with a confusing mess that can be as bad as any timeline-base FLA.
I’ve tried to embrace the philosophy that my code should be flexible enough to support whatever crazy ideas the designers can come up with. I give the designers the minimal structure and conventions so that my engine can interact with their assets, but beyond that I try to let them create whatever they want, including timeline-based code.
Indeed, I actually prefer timeline-based code to the Library Class Inheritance technique that has become prominent since Flash 8. I find the latter technique to be extremely opaque and difficult to integrate with external code. Indeed, I think Adobe has alienated some very good artists by pushing so hard in this direction with Flash.
Finally, I encourage people to check out the TimelineLite/Max API from GreenSock: http://blog.greensock.com/tweenliteas3/
It just goes to show how powerful the concept of timelines can be. I used it in our most recent project (http://www.aftertheimpact.com/) in order to script sequences of camera movements together in 3D space.
Now this does not mean I support poorly organized FLAs! I still encourage them to put all their functions in a central location, and to clearly organize and label their library.
Nice post, I definitely agree. The ultimate question is whether developers who choose a pure code approach are hindered by the timeline, which, especially now in AS3, I believe in most cases they are not (but people still like to complain about it). For the vast majority of Flash users, there is an enormous convenience and practicality in developing as a mix of timeline code and external code, especially for animation — the heart of many Flash presentations.
I have found that often the people who instigate the ‘real coders vs. wannabes’ argument are those who are really trying to convince themselves that they are in the ‘real coder’ category (maybe mommy didn’t hug them enough). Knowing how to program in Java, C, or even machine language does not make one a ‘real coder.’ Real-coders/developers do not have this inferiority complex, but understand the software concepts/methodologies and can apply them, if needed, to different languages.
Bravo!
I’ve been wondering for years where the voice of reason has been concerning timeline work as it relates to object oriented coding.
I first learned Flash using F4. In order to do complex work we had to create individual MovieClips (often with layers of sub-movieClips) that could be reused without damaging bigger structures. A generic button with specific animation, a character with the ability to animate independently depending on outside influences that could be dragged out of the library and dropped on a timeline, a window ‘container’ that is re-sizable, draggable and included it’s own scrubber and controls for video – video that is imported and contained at runtime etc. – all these different ‘components’ that functioned independently, reliably and were reusable made complex projects manageable.
All these visible library ‘objects’ were part of a concrete system that let a ‘visual’ and ‘mechanical’ coder like me grasp coding as if the parts of the code were real mechanical things with mechanical properties…
As a result many of the ‘old school’ Flash crowd were able to invent interfaces and other applications that were impossible to build from a purely code based system – because the complexity of keeping all the parts in a mentally abstract ‘code only’ form was/is to convoluted.
Timeline coding must by definition evolve into ‘object oriented’ development and allowed a whole group of mechanically inclined folks to get into Flash. These are people who a generation before would have been building engines and cars or doing construction in the physical realm.
The recent trend towards abandoning the timeline has frustrated this whole group of ‘visual object oriented’ programmers since Adobe has drifted towards an emphasis on purely code based development .
Hopefully the newer tools in Adobe’s pipeline that take timeline work and convert it to pure code will foster a re-emergence of timeline experimenters – from this end i would love to see an easier way to build on the timeline and see what the machine thinks that work should look like in pure code. Especially as a learning tool – it would greatly aid the process of connecting the two methods and learning AS3.
A seven or eight year old example of what Flash4 could do can be played with at: http://www.2GoTo.com – it’s just an old working example experimenting with the potential of F4. (navigation and menus trigger ‘on roll-over’ at the top and sides of the windows)
David, I agree entirely, real Flash developers are able to comprehend and implement OO principals in both visual and code paradigms
Absolutely, putting code in the timeline requires appropriate reasons and very importantly, timeline best practices (single layer for actionscript, always on the root level of the movie clip, library items well named and organised, etc)
Flavia,
You got my attention. I’d like to take the opportunity to reply to your comments as they were quite specific and made some assumptions.
Before I get to answering your specific points here, I want to recap my position:
The timeline is very useful , not only when a client gives you an impossible deadline and thus you have to produce heavily timelined, throw away solutions in order to meet the clients expectations (usually agreed by your Account Manager), but also in a more structured, architected solution environment, where being able to optimize the solution by using all the tools at your disposal also includes using code on the timeline where it is more appropriate and quicker than forcing it into a class file. As has been pointed out by far better coders than me, Flash is NOT Java or C, so use it for it’s dynamic strengths. This also allows developers of disparate abilities and skill levels to produce more or less the same solutions whilst learning better development practices, process and methodologies.
I should start by giving you a little background on me. I have been using Flash since 1999, Flash 3 when we were using timeline based Actionscript 1.0 if we were lucky. Those were tough times and to make anything complicated required a huge amount of ingenuity and hacking (usually involving the timeline). Since then I have been lucky enough to work with and get to know some of the best Flash/actionscript developers in the industry. I spent many years (and many versions of Flash and actionscript) learning better and better coding techniques, ultimately leading to OO and pattern based methodologies. I have coded on some huge RIAs for service companies, banks, broadcasters and more, including the likes of Microsoft and Adobe themselves. I am a prerelease tester for Adobe on Flash, Flex and a lot more. I am a certified Flash developer and designer. I am a published author on Actionscript 3 for Flash and Flex. I assure you, I know “this AS3 thing†…intimately. Sounds to me like you don’t get this pragmatism thing. Have you used any pragmatism on your projects?
The timeline is not vestigial and I’m sorry that you think it should only be used for animation. It is simply treated that way by more traditional code-only developers, who haven’t come across a timeline based tool before and those who believe that if you’re not doing pure code then you are an amateur. Let’s not waste time focusing on the reasons behind this attitude again at this point. The important thing is that there are multiple tools within Flash that allow multiple solution approaches, each of which should be examined against your development requirements in order to take the most pragmatic route. None should be excluded or artificially devolved simply because of a blinkered approach or an ‘Emperor’s new clothes’ attitude.
As you’re clearly having trouble with the application of the concept of pragmatism here, let’s examine it. The dictionary defines it as:
Pragmatism: A practical, matter-of-fact way of approaching or assessing situations or of solving problems.
In the case of the good Flash developer this means examining what your client wants and formulating the most practical way of solving their problem using all of the tools at your disposal. This most definitely includes things like the timeline. If you believe otherwise then you need to stick to Flex. Just because the timeline seems like a less formal option than pure code, that doesn’t make it evil.
A study of the Nursing profession in the 70’s revealed that many in power in the profession strongly believed that formal models of practice were the best solution. The study, however, went on to concluded that there was an over reliance on formal methods and tools leading to an erosion in solutions based on more rounded experience and pragmatism.
This study and it’s conclusions are not lost on me as a developer and these observations are present in many professional environments including software development. The more formal, traditional methods are, in their own right, very useful and produce great, modular, reusable solutions, however, to truly be a master of solving all and any clients requirements you must be able to take advantage of all the tools at your disposal at the right time and in an appropriate manner.
This is true. However, going through nightmare Flash is nearly always because the original creators haven’t followed best practices and good convention. This can include burying your code in multiple movie clips in multiple timelines, but here also best practices need to be observed. No tool is useful if poorly used. The ability to put the majority of code into external code files has always been a best practice solution but never loose sight of the fact that there are many clients who just want a working site in a week or two and this usually does not allow for well structured code to be architected and implemented. Even if it did in this example, what would be the advantage? The client will never want this maintained. They intend to allow it to run it’s course and then throw it away. Use the tools at your disposal to produce an optimal solution. Be pragmatic.
I think we have arrived at the core of the problem here: Your opinion is deluded. You are exactly the person to whom my original post was targeted. The timeline is NOT evil. Pure code is not the only option. Using the timeline for ALL it’s strengths, as well as external code, to their appropriate best practices, is a sign of a master of Flash. Actually, using any tool set to it’s fullest capacity is a sign of expertise in any given environment. It is ridiculous to suggest that using the timeline is “…pointless and makes life harder…â€
I see the big picture and I know that having more development solution tools is better than having less, provided I use them well and wisely.
Of course, all developers should use best practices, good process and pragmatism when deciding on the most appropriate client solutions. This is as true for the more timeline/visual approach as it is for the code based solutions. Personally I generally use a combination of visual elements, timeline and class based coding, getting the best out of each method, depending on the client requirements
As for your comments on Flex and Catalyst, well, some might say, loosely speaking, that if you put Flex and Catalyst together you end up with Flash again. Flash didn’t outlive it’s usefulness as a development tool, it is an exceptional development tool. It is every bit as capable of creating great AS3 OO pattern based solutions as Flex. So it doesn’t have MXML. Flex doesn’t have a timeline. So what? There are many top Flash developers out there who regularly tell me that they feel let down by Adobe for treating them like they are not real developers any more unless they use Flex instead of Flash. Many of us love using Flash to develop with and are happy to supplement our code development tools with the likes of FDT rather than move to Flex. Even now, there is the very reasonable argument that Flex and Flash should be one tool, allowing each type of developer / designer to choose the working tool sets / panels they want to use to produce their best solutions. You want timeline: turn it on. You want MXML panel: turn that on instead. You want visual design tools: Turn them on, etc. However, if I were to be cynical, I would say that there’s less money in that unified model for Adobe.
It really concerns me when I hear intelligent developers speaking about the timeline as though it were a bad thing. It is neither inherently good nor bad. That is down to how well you use it. It is an extra solution option and to ignore it or treat it with unjustified contempt is the sign of a inexperience or a small mind. Until the Flash revolution, keep an open mind, be pragmatic and use all the tools at your disposal to their fullest. That includes appropriate code in the timeline!
Hey good stuff…keep up the good work! 🙂