Sk-etchbook

Here are a few more extracts from my sketchbook relating to the Feel Good brief. Two of them are just rough layouts for the artwork and brainstorming for suitable elements to include in the design. The other is a functionality flow diagram. These are used to see initially in plain English what your interactive content needs to achieve. There are two main approaches to this. Top down and bottom up.

The following extarct is taken from Foundation Actionscript for Flash 8:

Building your ActionScript
As you begin to think in ActionScript terms, you’re always starting from the same point: you know how
you want your designs to work. What you need to think about is the best way to get there. There are
two main ways of breaking down programming problems: top down or bottom up.
A top-downdesign involves looking at the overall task and breaking the problem down into smaller
and smaller chunks, whereas a bottom-updesign means starting by looking at the basic building
blocks, adapting them, and building upward toward the solution.
Thinking from the top down
The top-downmethod is called a functionalmethod, because it looks at the functions that you have
to carry out, or what you have to do at every stage, to perform the solution. You begin by looking at
the aim in general terms or high-level requirements. Then you break up each of those general stages
into separate steps that become easier and easier to manage. These are the individual requirements
that you can deal with in turn on your way to building the complete package.
Sound strange? Let’s say that you’re looking at breaking down the high-level requirement of making a
cup of tea with an electric kettle, a tea bag, milk, and water. If you take the top-down approach, you’ll
first define the top-level design statement, which is
Make a cup of tea and then break it down to its main stages.

1.0Boil some water by filling the kettle with water and switching it on.
2.0Put some sugar and a tea bag into a cup.
3.0If the water in the kettle has boiled, pour some of the water into the cup.
4.0After two minutes, remove the tea bag, add some milk, and stir.

Breaking the task down to this level is called the first iteration.
You’ll then look at each of these tasks and break them down even further:

1.0Boil some water by filling the kettle with water and switching it on.
1.1Fill the kettle with water, two-thirds full.
1.2Switch on the kettle.
2.0Put some sugar and a tea bag into a cup.
2.1Add one teaspoonful of sugar to the cup.
2.2Add one tea bag to the cup.
3.0If the water in the kettle has boiled, pour some of the water into the cup.
3.1Wait until the kettle has boiled.
3.2Pour some water from the kettle into the cup, until the cup is three-quarters full.
4.0After two minutes, remove the tea bag, add some milk, and stir.
4.1Wait two minutes.
4.2Remove the tea bag from the cup.
4.3Add milk to the cup until the cup is seven-eighths full, and then stir.

The top-down approach fits well when you’re dealing with a tightly defined problem. A tight definition
eliminates the need for too many iterations, or breaking the task down again and again, and makes
each stage easy to change if necessary. For anything more complex, though, it throws up some pretty
basic problems. The most important of these is that if the high-level requirement changes, that change
must filter down through all the iterations, making you think about what you do at every stage all over
again.
For example, if you prefer coffee, you’ll have to start at the beginning all over again with a new top-
level design statement:
Make a cup of coffee.
And you’ll need to modify all the instructions at every stage below that, changing tea bagreferences
to spoonful of instant coffee, taking out that wait two minutesstage (because now you don’t need
to wait for coffee to brew), and so on. You may think that this isn’t such a big job in this domestic real-
world example, but it would be very different if your top-level design statement reads like this:
Build a navigation computer system for a combat helicopter with satellite positioning systems, radar,
and weapons management facilities.
You would have a bit more of a problem changing things around when the Army changed its mind
about what it wanted its helicopter to do. You would need to look at all 10,000 requirements for the
system and analyze the impact of the change on each requirement. This could take an extremely long
time, and even longer if you have to prove that you did the analysis of the changes properly (of
course, this ignores the fact that the Navy will invariably want something different from the seaborne
version!).
Experience has taught us to go for the easier option when possible. Speaking of which . . .
Thinking from the bottom up
Making a changein a bottom-up design is nowhere near as difficult as in a top-down design. Taking
the bottom-up approach involves looking at the problem, splitting it up into very general areas, and
asking, “What are the basic building blocks here?” You look for basic structures within your problem
and write general solutions for them before adding specific details to these general solutions to make
them suit the problem that you’re dealing with.
Going back to the tea example, the general building blocks of the problem are as follows:
Moving things from one container (such as a sugar bowl) to another container (such as a cup)
Measuring quantities
Waiting for particular processes to complete (such as boiling the water in the kettle)

If you were tackling this in ActionScript, you’d begin to create actions based around these general
building blocks.
You could start with a movingaction, adding details of whichever containers and substances were
involved:
move(fromContainer, toContainer, thing);
Then you could add a measuringaction, in which you could display “how much” of “what substance”
you want measured:
measure(quantity, substance);
Next, you could add switching the kettleaction, using basic on/off commands:
kettle(on);
kettle(off);
A conditional structure allows you to do something (switch the kettle on or off) only when certain
conditions are met (the water is boiling):
if (water boiling) {
kettle(off);
}
You could then look at the problem and see how to build up to making a cup of tea using these struc-
tures. For example, to fill the kettle you’d want to use the moveroutine to fill it with water from the
tap, so
fromContaineris the tap.
toContaineris the kettle.
thingis the water.
The thingisn’t just any amount of water, but two-thirds of the kettle, so you can express it as follows:
measure(water, twoThirdsOfTheKettle);
So the full statement to fill the kettle would be this:
move(tap, kettle, measure(water, twoThirdsOfTheKettle));
Taking it all in this way, the basic solution might look like this:
move(tap, kettle, measure(water, twoThirdsOfTheKettle));
kettle(on);
move(sugarbowl, cup, measure(sugar, oneTeaspoon));
move(teacaddy, cup, teabag);
repeat {
} until (event(kettleBoiled));
kettle(off);
move(kettle, cup, measure(water, measure(water, twoThirdsCup));

repeat {
} until (event(teaBrewed));
move(cup, trashBin, teabag);
move(milkContainer, cup, measure(milk, oneEighthCup));
stir(tea);
stop();
The two repeatstatements will make you wait (repeatedly doing nothing) until the event you’ve spec-
ified has been detected.
This looks suspiciously like ActionScript already! You’ve lost the timings like “wait two minutes” from
the previous top-down version. Why? Because it doesn’t matter! You’ve moved away from the initial
problem to the extent that what didn’t really matter dropped out of the problem. You never even
considered it. This method can save you a little work and is also useful when the main problem or
design aim is likely to change frequently, which could happen more often than you think. You use a
move routine to fill the kettle with water from the tap. Once you’ve written that general routine, you
can use it over again, with just minor changes for several other actions, including
move(teacaddy, cup, teabag);
With the top-down solution, wanting coffee instead of tea caused you a major problem and you had
to look again at the whole process. If you’re faced with that problem here, the basic building blocks
stay the same; you just have to change a few minor details again, and you can substantially reuse the
existing code:
move(coffeejar, cup, coffeepowder);
That’s much easier. Because the bottom-up design didn’t just look at the top-level problem (making
tea), you generalized theproblem, or abstractedit. So, you don’t care whether it’s tea or coffee or
crude oil—you can still use your basic move()and measure()building blocks again, and you won’t
have to change them when you do. Bottom-up design digs the foundations before building on top of
them, whereas top-down just puts itself down in any old way. When the winds of change blow, you can
guess which one stays standing longer.
This bottom-up design method can be much harder to understand than the top-down alternative
because, as adults, we generally prefer to think functionally. Common sense says that bottom-up
design shouldn’t work, but it seems to work rather well. It really comes into its own with problems that
can be reduced to a few types of building blocks, which means that it works particularly well with ani-
mation and graphic interfaces.