Aral Balkan

To Code or Not To Code

There appears to be a deepening chasm in the Flash world between those who understand and use ActionScript in their work and those who don't. We sometimes incorrectly categorize this as the difference between "designers" and "developers", on the assumption that "designers" do not understand code and "developers" do not understand design. If you've attended one of my talks in the past, you will know that I consider this to be, at best, a convenient over-simplification.

The Mythical Roles of Designer and Developer

The labels "designer" and "developer" may have sufficed in the early days of the web when we were still trying to make sense of this new and exciting medium. More than a decade since, we have discovered that the medium is not entirely new and does not exist in a vacuum.

We've learned that reinventing the wheel can be a costly mistake and that there is a goldmine of existing knowledge that we can make use of from the fields of software development and Human-Computer Interaction. The former have given us processes such as Agile Development and configuration management (version control) while the latter provides us with User-Centered Product Development, with its focus on the user, usability design and usability testing.

Today, the "designer" and "developer" labels, especially the former, to do not tell us much about the what a person is or what a person does – even though they are frequently used to describe both. As a description of job function, they are woefully inadequate in detail: What type of design work do you do – what is your function on the team? Is it graphic design, motion design, information design, object design, usability design..?

The role of the "developer" – at least in a Flash context -- appears to be somewhat better defined. You can assume to some degree of accuracy that the person's job involves implementing the client-side using "the design" (usually a graphic design, sometimes a behemoth functional specification, rarely stories that she has been involved in writing along with the client and user.) You can also assume to some extent that the "developer" has programming responsibilities. What you cannot tell from the title is whether or not she is involved in architecting the application and to what extent. Nor can you ascertain to what level she is involved in or responsible for the usability of the application.

Where these titles lack the necessary granularity in describing job function, one thing is certain: They are overly-restrictive when it comes to describing who a person is. "I am a designer", for example, is often used to justify time not spent learning to program. Similarly, "I couldn't draw a straight line" is an oft-used excuse by "developers" to rationalize a lack of invested time in learning the basics of graphic, motion and usability design. (Contrary to popular belief, many of the best graphic and motion designers in the world – not to mention usability designers – couldn't draw a very impressive straight line either if given an easel and brush and, similarly, some of the most talented artists I know couldn't design a page layout to save their lives.)

At the personal level, you should accept no less than the title of "Artist" and aspire to earn the right to carry the title – a right determined not so much by your accomplishments as by your approach: A relentless pursuit of perfection, where the journey is the destination.

Like it or not, we are the artists of our era and this crazy and wonderful conglomerate of digital media are our easels, palettes and brushes. We can create beautiful things, thought-provoking things, things that can make a change and we can potentially reach more people in more ways than has ever been possible in the past.

Our medium is so broad that it encompasses, among so much else, graphic design, with emphasis on form, contrast, repetition, color and typography; motion design, where framing, editing and composition come into play as well as the animator's toolbox of expectation and expressiveness and the art of the storyteller, director and actor; usability design, information architecture and last, but definitely not least, that newest of art forms: Programming.

Programming as an Art Form

When photography was first developed, it was heralded as a wonderful technical achievement but nothing more. It was seen as the technical act of capturing reality. Over a hundred and fifty years later we can now read the photographic text as a subjective device – a means of artistic expression if you will.

When, over a hundred years ago, the Lumière brothers staged the first public films in the basement of the Grand Café in Paris, audiences ducked, screamed and ran out at the sight of a train pulling into a station on screen. Nowadays, we stay in our seats even in films like Jurassic Park, knowing that we're not really about to be eaten by dinosaurs. We have learned to read the medium and understand it. We now give awards celebrating the artistic vision of those who work in the medium.

In contrast, the first consumer computers began to make their appearances around 1974-1976. I wasn't much involved with computers at this time as I was busy being born  I predict that by 2074, we'll have prizes for artistic merit in programming and computer programs being adored in museums. It's not that far fetched an idea when you realize that a hundred years ago you would have run for dear life at the sight of a train on film!

Pragmatic Programming

As much as I consider programming an art form, I cannot deny the practical applications that are at the heart of its existence. At the simplest level, whether you want to control traffic flow in London or animate a movie clip across the stage, programming makes your life easier and that is its raison 'être.

So, if programming can make our lives easier, why do we fear it so?

It all comes back to the train pulling into the station: It is new and scary. Either that, or we think that we just don't have the time to learn it. To this, one could retort that, yes, programming is (relatively) new but is actually simpler and less scary than most things in life (like relationships or finding a parking space in London) and, given how much time and effort it can save you, you simply do not have enough time to not learn it!

Programming as a Tool

It is important to distinguish between two different applications of programming, based on when the programming is used. The first application is programming as a tool.

Programming can be one of many tools in your toolset during development. In its use as a tool, it contributes to the creation of a digital artifact but does not feature as part of that artifact. Examples for this may include writing an Action in Photoshop to automate a certain task (yes, you may actually have programmed without knowing it) or JSFL in the Flash IDE. In its use as a tool, programming helps make your development process easier by automating certain repetitive tasks. (Some people refer to this type of programming as batch programming or scripting but this is usually used to imply that this application of programming is somehow inferior to "real programming". The same argument is used many times by "real programmers" against programmers that use so-called scripting languages like ActionScript, PHP and Python. I won't lend any credence to such shallow thinking in this article by adopting this nomenclature.)

The effects of the programming tool may be readily apparent in the resulting artifact or they may be completely hidden. For example, an animation created using Expressions in After Effects and output to film will not contain a running program when it is displayed. However, it will have been created, during development, through the execution of programming code. The same can be said for a Flash movie output to a Quicktime video format, for example.

Programming as an Artifact

In contrast to the use of programming as a tool, programming can actually constitute part (or whole of) the artifact being created. In other words, the end result may be the program itself.

Examples of this abound: Any software application you currently use or web site you visit are examples of running programs in action. Flash games, for the most part, are made up of code intermixed with animations and sound. Contrast this to a linear presentation that is output for video, which does not contain any "live code".

Although programming as a tool can be a huge productivity boost, I will be concentrating here on Programming as an Artifact: Writing code that actually becomes your web site, application or game and governs how it interacts with both the user and other pieces of software.

Learning the Medium

In talking about art, I mentioned the concept of the "medium." Our medium, as Flash artists can contain non-linear interaction with multiple geographically-distributed users and incorporate audio, video and text in infinite combinations. Learning programming is the first step in learning to control this medium.

Taking the First Step

To help you take the first step, I have planned a series of tutorials to give you a gentle, visual introduction to ActionScript 2 (AS2). The series assumes no previous knowledge of programming although you should be familiar with Flash and its various constructs (like the MovieClip.)

It is my aim to teach you ActionScript 2 with hands-on tutorials that cover the basics using practical examples that you can immediately apply to your everyday work or play!

In tandem with these tutorials, I will also be teaching 2-day courses in London (UK) as part of Ariaware Training's "Hands-on" series. The classes, called Hands-on: Introduction to ActionScript 2, are scheduled to begin in January 2005, with the first one scheduled for January 27th-28th.

I will also be announcing another course I will be teaching in the coming year, along with a few others to be taught by widely-respected experts in our field.

I'll post the course details and the first hands-on tutorial shortly in separate posts.

Comments

• I love this article for it's polite introduction to programming. -Martin

  by Martin on 2007-01-08 05:07:24