Saturday, 10 January 2009

Functions, functions, functions

Being originally trained in graphic design, I missed out on formal training in computer programming. The subtleties of programming were all self taught and learned as needed, rather than learned in a logical and structured way. This, and the fact that I come from an art background (definately part of seeing the world a little differently) perhaps explains why I tend to come onto programming solutions to my interactive media problems in a round-about way.

The purpose and value of functions is a perfect example of this. A programmer could probably explain it to me until they were blue in the face, but in fact the best explanation I have ever had came accidentally in two halves, while actually looking for a solution to something else.

The following is actually bits taken from two different chapters in the Flash MX 2004 ActionScript reference ("Using built-in functions" and "Returning values from a function"). Why they didn't just explain it this way in the first place I will never know. Still, if having it explained this way makes sense to you I share it below for your benefit:

A function is a block of ActionScript code that can be reused anywhere in a SWF file. If you pass values as parameters to a function, the function will operate on those values. A function can also return values.

To call a function, simply use the function name and pass any required parameters.

For example, the following function returns the square of the parameter x and specifies that the returned value must be a Number:

function sqr(x:Number):Number {
return x * x;

Some functions perform a series of tasks without returning a value. For example, the following function initializes a series of global variables:

function initialize() {
boat_x = _global.boat._x;
boat_y = _global.boat._y;
car_x =;
car_y =;

Saturday, 3 January 2009

More Coding for Fun (while still solving the design problem)

Well, as usual I take the opportunity in the holidays to practice and develop my Interactive Media skills. Last time I made a Ukulele Tuner, this time, prompted by a relatives' purchase of a OO gauge railway for Christmas (and my own love of making things and building models) I put together a program to speed up scale calculations to make it easier for me when (and if) I find time to make scale model buildings for my relatives' railway.

Here it is produced in Flash with ActionScript, graphics produced in Fireworks and exported as PNG 32. Ultimately I will compile it into a windows executable using Zinc or Flash Studio once it has been thoroughly tested:

The model railway community on the Model Rail Forum, the New Railway Modellers forum and the Model Railway Forum were very helpful. Although I like to make models when I have time, I am by no means an OO or even a model railway expert at this point in time, so input from the potential user base was absolutely vital.

I guess the lesson I would want my students to take from this is that you don't have to be an expert in a field to successfully design for it. But you do have to do thorough research and be genuinely interested in learning about the field and learning about what is important to your client/the user. If you haven't learned to be interested you may find that what you produce meets the needs of precisely no-one - and you won't even get paid.

This lesson was summed up nicely by a designer who has influenced my approach to creative practice, Ivan Chermayeff. In a long time ago interview with ID magazine (I think it was ID), in an article called "Design: Another Reconsideration", Ivan simply states that "designers should be interested in everything" (para).

I think he is right. Almost the one industry a designer will not design for is his or her own industry. They will be employed to design for a variety of other industries throughout their career however, so an interest in other people's area of expertise is vital. After all, design is about problem solving (another lesson from Chermayeff), so designers need to be interested in the problems and get inside them, because as Ivan once described - solutions come directly out of an understanding of the problems (para).

That's why my research took me directly to the community of model railway enthusiasts. Because in talking to them (here, here and here) I would come to correctly understand the problem (the issues surrounding calculating scale conversions for model railways, the scales themselves, what the user needs it to do etc.) Once I understood the problem, the solution was pretty much obvious, all I had to do was apply my new understanding to the interface, visual appearance and make it work.

And the result? The community feedback was positive about the current version, so I know I have been successful. While a few suggestions for even further development have since been made, for now I have a working product that actually meets my own needs, and the needs of real live users.

Only possible, because the users were consulted about the design problem, and their input turned into a solution. Problem solved.