Print and publications

Object oriented programming for designers, a quick look


Designers usually tend to avoid working directly with the Adobe ®Flash® programming language called ActionScript®, because there is a misconception that programming in general, and object oriented programming in particular, are complex subjects in realm of software engineering, not art and design.

Contrary to general belief, object oriented programming and design fundamentals are easy concepts to learn and all the core concepts can be explained roughly in a single short session. In the following text, I’ll try to explain the basics of OOP in the simplest form for designers who are interested in learning an OOP language in order to prove my point. Let’s begin!

Define the problem before solving it

Another common stereotype about programming is that every program consists of a flowchart-like set of procedures like this:

1‑Do task A

2‑Do task B

3‑If we still didn’t reach the results, go to line #1

4‑Do task C

While this is not completely untrue, in reality solving every problem using flowchart-like procedures creates great complexities. For Instance, just imagine the complexity of breaking down the activities of a car driver when starting a car into a flowchart.

0‑Search for your car

1‑Go to your car

2‑Is it your car?

3- If so, take out the key

4‑if negative, go to line #0


You can clearly see that we can create a book as thick as an encyclopedia and still be unable to begin defining the actual activity of driving. In other words, procedural problem solving is a weak tool for modeling the complexities of the real world. That’s why developers call complex procedural programs “Spaghetti code”!

OOP to the rescue

OOP approaches the real world problems by breaking them down into “objects”. The meaning of the term “object” in OOP is very similar to its meaning in the physical world; Objects, say, a car, have properties like color, material type, name, physical dimensions and owners. Some objects can be broken down into smaller subsets of objects. For[R1] example, in case of a car, we can break down it into gearbox, steering wheel, engine, etc. However, for the sake of simplicity, sometimes we prefer to “see” the entire set of related objects as bigger object which have grouped the entire smaller objects inside it. Also note that each part of a car doesn’t necessarily “know” about inner workings of another part, but they all work together. Developers call this feature “encapsulation”.

Objects can produce “events” like “brakes active”,” door open”, “airbag active” . In addition, you can control objects by predefined “statements” (i.e. commands) which developers call “methods”, like ” start”,” stop”, “accelerate” or “turn left”. Please see the basic possible structure of a typical object:

Object:Anatomy of a typical object

Car:Possible properties, events and methods of a car

As you can see now, starting a car, in this case our red Ford, can be easy as this:


In this example, “car” is the object, “start()” is the method, the dot(.) indicates that we are activating the start() method of the car and finally, semicolon (;) indicates the end of our statement.

Now let’s see how we can change the car’s color:


As you can see, we changed the property color of the car object to red.

We can also define our car a little more:





Event listeners and Event Handlers

Now let’s see how we can check if our car is running. First, we have to attach a “Listener”, something which actually “listens” to the event like a sensor, to the car:

car.addEventListener(EngineEvent:running, announce);

Developers call this statement an” event listener”. The statement attaches a “listener” using the addEventListener “method” or statement. This method listens to see if the “running” event is triggered. The “running” event is inside the subcategory of “EngineEvent”. When the event actually happens, the “announce” function will be activated.

The function is a block of code which actually does the thing we want to do when the event happens. We call this block of code an “event handler”.

function announce (eventObject:EngineEvent):void{

Trace (“car is running”);


The function name is “announce” and the event type that it will accept for processing is “EngineEvent”, because back in the previous line of code we stated that we want to listen to that specific type of event. Please ignore the “:void”, because it’s not directly related to our discussion. Inside the curly braces { } , which define the beginning and end of the function, is the statement that we want to activate when the car actually starts running:

trace (“car is running”);

The trace statement is a simple but very useful ActionScript® statement that simply prints what we enclose inside the parentheses, which in our case is a string (A set of characters or numbers) announcing that the car is running.

Now that we know the trace statement, guess, what this statement will do?

Trace (car.maximumSpeed);

The result is the number 150, which we assigned earlier in our code.

As the last sample of code to show you how easy OOP is to understand and use, guess what this block of code will do?


f (car.currentSpeed>car.maximumSpeed) {

trace(“Warning, You are exceeding car’s maximum speed!”);



Now, imagine every element of a Flash animation or application you see is an object or a set of objects that are grouped together; a player in a game, a user in an application or a movie that is played inside a flash animation are all examples of objects. These objects can have their own properties, events and methods just like the car we used as our example.

Like a child that learns how to interact with the real world objects one by one, learning flash objects are a step-by-step process. However, before that, you should learn the syntax of the ActionScript® language, issues like when and why to use dots, curly braces and correct character cases and also study more about the fundamentals of OOP.

I hope this short article has encouraged you to enter the interesting world of working with multimedia projects, using OO ActionScript®.

Creativity vs. faux-science

Looking into communication problems with the sophisticated client

The Clients who are knowledgeable scientifically, usually have higher tendency to try to take control of the design process. This leads to a less effective solution at the end.

This article tries to share more than ten years of experience on how designers try to avoid such situations, how and why they usually fail, and what are some of the possible workarounds.

The problem

The well-educated client, equipped with the tool of analytical thinking, believes s/he can analyze every design problem, finds solutions for it, and applies what s/he has learned from the past to any similar problem at present or in the future (and perhaps consequently even unseats the designer). In their own minds, they only lack the production tools to do a designer’s job.

Designers tend to protect their leadership position through indirect approaches that help them to avoid such situations altogether like:

  • Trying to direct the communications by creating a vast personal space, avoiding the client as much as possible, and avoiding “unnecessary” meetings
  • Using silence as a weapon, avoiding lengthy arguments about the project, and avoid verbally defending their designs out of fear of losing the argument, that is always a possibility for everyone with any level of negotiation skill
  • Leveraging their portfolio, awards, exhibitions, workplace atmosphere, teaching experience, lifestyle and social class to create a “take it or leave it” atmosphere for the client, forcing them to accept their design decisions out of fear of shame and risk of being labeled as uninformed or art-illiterate.

Creating this “sacred” atmosphere around art and design obviously is not an answer to the logical inquiries that arise in the minds of the clients. Even if the mentioned behaviors work on some of the less informed or simply shy clients, the bolder, more analytical minds will always remain unsatisfied.

Design and faux-science

The universal success and ubiquity of scientific approach in solving problems, leads public to disregard other ways of thinking, like various methods of creative and design thinking. In society, the scientific approach is the de facto norm of problem solving and the only type of “correct” thinking. That is why usually the clients’ first step to evaluate a design is to use their scientific leanings; overlooking the fact, that scientific method needs concrete input data from the world outside in order to produce something meaningful, something nearly impossible and inapplicable in many areas of the design process.

Consequently, without real data, clients just re-approve their own reasoning and reassure themselves that their decisions are based on “scientific / logical” methodologies.

If one leaves the two main verifiable inputs of the design process, the user science, and market research aside, the rest rely on instinct, experience, creativity, courage, imagination, and brilliance.

A solution: notice and emphasis the difference



Reviewing fig. (a) that shows a simplified view of the two thinking processes side by side, one can observe the scientific method tends to use, and rightly so, theories that already exist as law, in order to solve present issues. The foundation of scientific knowledge is very solid, stable and scientists return to revise or delete entries only in rare cases and usually after decades of study.

In design method, although some solutions can be applied to various situations, the changes in the problem’s background (Social, psychological, demographic, and temporal, etc), i.e. the “gestalt” part of the problem, rarely let the same “experience” happen again using the same ingredients and production guidelines. One also cannot satisfy the other main requirement of the scientific approach that no two people experience and evaluate the result of a design in the same way. Perhaps that is one of the reasons why obsessions of the software design experts with “design patterns” always have dubious results and their usefulness is difficult to prove.

It can be helpful if a designer masters the differences between the design and scientific approaches and informs the client of the process road map. This way, the client will base her/his reasoning on the correct path from early stages of the project (even by revising the structure of contract) and harmonize with the designer and the problem that needs to be solved, and avoids various unnecessary, energy-consuming issues.

One by-product of this argument is helping us to understand why a client dismisses a designer/design firm after receiving just one round of successful of industrial, advertising, or other kinds of design services. After observing a complete round of successful design project, some clients think that they have found “the formula” – just like the scientific approach, and they can repeat it as many times as they want to the extent of their desire and when they see appropriate. In this viewpoint, paying the designer is a waste of resources, of course. Actually, that is not true. Constraints always change and what used to be a trendy idea (or even the master pattern that produced that idea) one year ago is no longer considered as such.

That is why designers are here to stay.