Extensibility

(from Wikipedia)

… is a system design principle where the implementation takes into consideration future growth…

…the design includes all of the hooks and mechanisms for expanding/enhancing the system with new capabilities without having to make major changes to the system infrastructure….A good architecture provides the design principles to ensure this—a roadmap for that portion of the road yet to be built…These excess capabilities are not frills, but are necessary for maintainability and for avoiding early obsolescence.

…can also mean that a software system’s behavior is modifiable at runtime, without recompiling or changing the original source code.

—-

This idea is useful when building projects that have iterations or phases. Sometimes the client knows they’re going to want multiple versions of a given project. Realistically though, this happens all the time, even when one is working with little outside influence. An idea doesn’t usually look the same on the screen as it does in our minds or in a script. It needs tweaking and fine-tuning. As designers, we often go through myriad iterations before reaching the final product. Over time, I’ve come to realize ways to save myself future hassle by taking time upfront, at the start of a project, and planning what pieces might change how I can design them to be more flexible and more economic. This ‘brain-time’ early on reduces the ‘oh crap’ time later.

Thinking in terms of extensibility: Grouping

The simplest and earliest tricks we learn as Flash designers is to create symbols. This saves filesize because Flash only has to load each symbol once, even if it’s used a number of times. The other great advantage of using symbols is that you can edit it once and affect every instance in your file. The symbol in the library acts as a prototype, or for you philosophers out there, it’s much like a platonic form, the ethereal ideal from which all earthly instances are based. More generally, symbols could be considered to be a way of grouping. The group of instances has a common set of basic characteristics that are described by the symbol in the library. New characteristics can be added on top of those inherited from an instance’s group (like giving a movieClip instance a tint or changing it’s alpha on the stage).

Arranging problems into generic groups reduces the effort needed to solve them. Functions can be made more generic by passing in variables. Instead of writing code out for 4 tweens, why not write a tween function and pass into it the movieClip you want to tween as a variable. You can make the function more generic by passing more variables (start point, end point, duration, etc.).

This, taken to it’s logically conclusion, begs the question, ‘If I can write functions to reuse within a given file, why not write code that I can reuse for multiple files?’ Enter Object-Oriented Programming . Object-Oriented Programming (OOP) allows you to save code in Actionscript class files and access it from Flash by creating an instance of that class. A movieClip, for example, is an instance of the movieClip class. Each movieClip has several properties (x, y, width, height, alpha, etc.) and behaviors (onEnterFrame, onRelease, onRollOut, etc.). These properties and behaviors can be reused in a new class by extending the movieClip class, so that your new class will allow you add to the functionality of movieClip and will contain all the properties and methods that a movieClip does. You can also write classes from scratch. The idea, in short, is invent to the wheel once.

To learn more about OOP in Flash 8 or Flash MX 2004, check out Object-Oriented ActionScript For Flash 8 by Todd Yard and Peter Elst. A new edition for AS3 is also available, but nearly any book on AS3 will have to address OOP. Actionscript 3 is almost entirely OOP-based, though AS2 is geared toward OOP, it is a bit more forgiving of non-OOP-based code.

The Other Extensibility: ‘modifiable at runtime’

There’s probably no better exercise for extracting information into generic groups than XML. An XML document is essentially a text file, it looks a lot like HTML, except that the tags are completely made up. A tag in XML has no predefined meaning, it’s up to the application to decide what the tags mean. How’s that for generic?

Flash can pull data from XML at runtime. The XML can be used to swap images, swap text, and even change behaviors if the Flash file has been so setup up. That means that an SWF (Flash’s export format) can be altered without republishing from Flash or even having Flash installed! This can save tremendous amounts of time for a file that requires frequent updates and it can even empower clients to make small changes without having to come back to the designer. All because a little ‘brain-time’ was utilized at the beginning of the project.

There are other methods of customizing at runtime as well. I had a project a while back that was a Flash presentation. It required an IP address specific to the location of the presentation. Since the presentation was going to be given twice at two different locations, it was assumed that a duplicate presentation would need to be made. What’s more, the IP addresses weren’t easy to find beforehand, and this customization may have to take place the day of each presentation. I suggested instead, that a text input come up at the beginning of the presentation so that the presenter could enter the site-specific IP address, it would be stored temporarily, and later displayed in the presentation. This saved a handful of hours and a whole lot of headache, made me look like a genius, and didn’t even require that the presenter edit an XML file beforehand.

The Problem with Extensibility: Selling it to Clients

Design is an expensive business. Good design is very expensive. And there’s nothing like a design budget to make a client seem stingy. It’s a business that often requires designers to justify their existence and their rates.

At first blush, extensibility planning often seems like an unnecessary expense to a client, and may seem like wasted time to a novice designer/developer, but in truth, when it’s done well, it’s a no-brainer. A little brain-time upfront can save designer and client alike a whole lot of headache down the road. It ultimately tends to save money during the revision process as well. Clients (as a big amorphous group) are famous for changing their minds, and the less that you, as the designer, have to wrestle with when this occurs, the better your life will be. The trick then becomes selling it to the client at the start of the project. Some extensibility, of course, can occur without the knowledge of the client. The client doesn’t usually have to know the fine details of your library structure or coding nuisances, nor do they care. For more ambitious extensibility though, the ‘brain-time’ will be evident in the budget.

Imagine you’re the first person to suggest a car without a crank. Let’s forget for a moment the awful consequences and inefficiency of a combustion engine. You’re engineering this car as a freelancer for a large auto manufacturer. The dilemma is that it will take several extra months to engineer properly, and once it is completed, it will require a bit more testing than the existing model (because it’s new and slightly more complicated). This extra time on your behalf translates into a greater price tag for the manufacturer and hence, is significantly less attractive than the status quo. The upshot, however, is that drivers of your vehicle won’t have to crank the car (which might also prevent them from losing an arm). The appeal of this convenience compounds for drivers that live in snowy areas. Your job then (in addition to engineering the thing), is to explain to the manufacturer what this will do for their business, even though it will cost them more upfront, it will ultimately be a huge moneymaker (and may save on lawsuits from people losing their arms). This is the essence of selling extensibility.

The problem is that clients have extreme difficulty ignoring their immediate bottom line, even if it will dramatically improve their bottom line in the foreseeable future. We see this everywhere nowadays, a company cuts wages, not thinking they will lose employees or hurt morale (and therefore productivity) or that the employees may not be able to afford the goods produced by their own company. It is an unfortunate consequence of unchecked capitalism, and to some degree, human nature. Understanding that, selling extensibility must be approached with patience. I’m convinced though, that the frustration of repeated explanation will be trumped by not having to go through completely avoidable and repetitive design changes. And hopefully a little ‘brain-time’ and a little ‘explanation-time’ will still save a whole lot of ‘oh-crap’ time in the end.