Controlling Implementation.

The process of implementing a multimedia application which it is sensible to adopt depends very much on the size of the application, the kind of implementation technology used, and the project environment in which it is being developed (under contract to some third party, as an exploratory development in an academic environment, etc.). As a result, these notes will be restrict to general advice and sound principles applicable in most cases.

Modularity.

A key term in the development of any piece of software is modularity. This means the development of an application by constructing it out of a number of independent units that are put together to form the finished application. A modular approach gives your several advantages:

• small units can be built, tested and 'signed-off' - there is no need to worry about them once they have been constructed, they form reliable, 'off-the-shelf' components;
• an application can be constructed by a team of people who develop their modules independently;
• constructing applications in small pieces reduces cognitive load; humans can only hold a limited amount of information in their heads at one time, so working on a set of simple building blocks is easier than trying to build a complex object in one go.

A modular approach to implementation mirrors the design process that we have already seen in our mapping and storyboarding approach. See how modular implementation follows a reversal of our design steps, we:

• have a single, high-level design idea for an application;
• start to break that idea apart with thematics maps and storyboards;
• list the assets needed to implement our design;
• develop our assets (each constitutes a module, of sorts) and test them;
• start to integrate our assets as we build pages (we'll assume that we are talking about a web application for the moment), testing each page as we build it;
• integrate our pages into a tested, completed site that corresponds to our design idea.

Using your ghost story application as an example, draw a diagram showing your design idea fanning out into modules, and then these modules being put back together to form the completed application. Annotate your diagram with a description of the actions that you had to take (packages, what you did in them) to produce your modules, and with a description of the testing and correction actions that you had to take to make sure they worked. Also, annotate your diagram with a description of the actions that you had to take to integrate your modules.

Prototyping and Experimentation.

The development of a multimedia application will very seldom follow a direct path from initial idea to final implementation. It is usually necessary to experiment with ideas, to try them out on users, and to be prepared to build several versions of an application as required improvements become apparent. It is a good idea not to do this in a haphazard way, but to plan for each prototype and learn lessons from it. This prototyping approach to application development can be envisaged as a kind of spiral - it circles out from an original design idea, through repeated applications of the development sequence, getting closer all the time to the final product. This spiralling should follow a disciplined pattern:

1. Initial design idea.
2. Map and storyboard original idea, develop assets.
3. Implement and integrate modules, test them for functionality.
4. Evaluate the resulting prototype, with users and experts, noting the results carefully.
5. Modify original design idea as required.
6. Modify maps, storyboards, assets as required.
7. Re-implement, re-integrate, re-test.
8. Repeat 4., and keep on going around this loop until the prototype has reached as state in which it can be released to a wider audience.
9. Publish, continue to collect user feedback, and repeat from 4. as required.

In our module assignments it is difficult for us to arrange a formal exercise that cycles around this process more than once or twice, since we don't usually have opportunities for user experimentation, and we are usually focusing on some specific implementation or development technique. It is, however, a good idea for you you to keep this process in mind as you develop your work - try and be your own user and evaluator, and make an explicit note of the aspects of your work you need to improve.

Using your ghost story as an example, try and draw a 'spiral diagram' showing the versions and improvements that your finished page(s) went through, or are still going through. Could you have formalised this process so that it corresponded to the pattern above? If you had, what would the evaluations have said? what re-designs were carried out?