2.3.1 Initial Idea or Concept
The concept or purpose of a multimedia system is often expressed at the start of the project
in just one or two sentences, e.g:
"The system should assist computer science or software engineering students in
understanding the concepts of class, object and inheritance."
"The system should allow Web users to carry out a virtual tour of a zoo, giving them
factual information about the species in the zoo, background information about animal
behaviour and habitats, including still pictures or video of animals in the zoo. Travel
information, opening times and prices should be provided, and the site should be
aimed at encouraging as many people as possible to visit the zoo in person."
"The system should allow two people to play a game of chess over the internet, with
a shared model of a chess board and direct manipulation to make moves. The
system should also allow players access to a database of previous games, and
advice from an intelligent agent."
"The system is to provide an online booking system for theatres and cinemas in a
medium-sized town. Video clips of extracts from films, shows or plays currently
playing, or soon to be playing, should be available to assist users in making their
choice. Secure credit card payment facilities should be provided for those proceeding
to book tickets."
"A multimedia biography and bibliography is required covering the life and works of a
well-known author, e.g. RL Stevenson, Lewis Carroll, JR Tolkien, JK Rowling, Terry
Pratchett, etc. This should include details of all the characters in their books, with
illustrations and clips from films or cartoons based on the books."
Post hoc Concept Specification Exercise
2.3.2 Refining the Initial Concept
Given the initial requirement or concept in a form similar to the previous examples, the first
stage for the project team is to refine the requirements, in consultation with the client, and
possibly also potential users of the system.
If the client is not ready or able to specify requirements in more detail at this stage, the project
team will need to supply their own ideas, and proceed as far as logical flow definition, before
bringing the elaborated specification back to the client for further feedback.
The following is a checklist of the areas, which need to be clarified through the process of
1. Domain of use (see Topic 1): e.g. graphic art, advertising, entertainment, education,
eCommerce, information, or other.
2. Metaphors from the context of use: frameworks or metaphors arising from or relating
to the application context, which are likely to be familiar to users, and might form the
basis for the design, e.g. storybook, treasure map, etc.
3. Goals and anticipated outcomes of the project.
4. The content of the application: a description, in general terms, of the nature and
scope of the material which the application will contain.
5. Dominant genre: will the system be closest to a self-standing work of art, a film, a
virtual world to be explored, an encyclopedia, a simulation, etc?
6. Intended environment of use: is the system for individual or group use? If for use by a
group, is it competitive or collaborative, is the delivery platform a PC, a mobile device
(phone, personal organiser, wearable computer, etc.), or a specialised virtual reality
system, for example?
Will the delivery platform be self-standing or networked? If networked, how much will
be local to the user, and how much distributed across the network? What will be the
minimum configuration of the platform on which the system will be expected to run
with acceptable performance?
7. Intended users: the range of intended users in terms of language, culture, age,
education and expected background knowledge and experience.
8. Modes of interaction between user and system: this is linked to the previous issue,
because the environment of use must include devices and systems to support the
intended modes of interaction. The input modes could include speech recognition,
haptic (gesture or touch) input, keyboard, optical character recognition, handwriting
recognition, position indicator (mouse or other similar), joystick, 3D input controller,
9. Required functionality: what (if anything) does the system need to do in computational
terms, e.g. simulate in real-time the behaviour of a car or an aeroplane, compute the
total cost of a loan over a given period at a given interest rate, etc? If significant
computational functionality is required, it needs to be specified precisely in a way that
can be verified at the testing stage.
10. Available budget: both for the software development process, for any required
hardware, and any content to be imported, for which a licence or purchase fee needs
to be paid.
11. Timescale: the amount of time needed for completion of the project.
2.3.3 Scenarios in Requirements Capture
It is seldom possible to fix the requirements and goals completely at the outset of a project.
Some of the questions relating to the detailed specification may be answered very simply and
finally; others may have no simple answer at this stage, or may be able to be answered only
Nevertheless some statement of assumptions should be made and agreed with the client
under each heading.
Since the requirements specification is not set in stone at the start, but an evolving document,
it needs to be kept up-to-date and consistent with the high-level and detailed design as they
At the high-level design stage, the high-level storyboard (HLS) captures the designer's
proposals for meeting the specification.
At the detailed design stage, the detailed level storyboard (DLS, or just "storyboard") is the
central record of the design. A prototype implementing some or all of the detailed design may
also exist, acting as a sample or demonstrator of the designer's intentions. The prototype will
be used in evaluation in order to iteratively refine the interface and improve the usability and
efficiency of the system.
Indirectly, evaluation of the prototype may also lead to amendment of the requirements
specification. Following evaluation, the prototype will be changed to fix any usability or
functionality problems identified. The specification may then need to be updated to retain
consistency with any additions or changes to the features, behaviour, or capability, which
have been incorporated in the prototype.
Scenarios can also be of great assistance in focusing discussion with the client and with
potential users on what the system is for, and what kind of usage it is intended to support or
facilitate. If they are unable to suggest some plausible use scenarios, then it is going to be
very difficult to build the system.
A scenario is closely related to what is called a "use case" in object-oriented design. However
the use of scenarios proposed here is based on their use in Human Computer Interaction, as
described for example by Carroll and others in "Scenario-Based Design".
The use case or scenario is a valuable tool both in refining the requirements in consultation
with the clients, and in evaluating a prototype design, either on paper or in a live system:
A scenario is a story describing a specific episode of use. The level of detail will
depend on the level to which the system has been designed.
Potential scenarios can be discussed with potential users as well as with clients, to
check if they are realistic and representative.
A collection of several different scenarios should be evolved, covering a range of
uses, and a range of user characteristics and purposes.
A collection of scenarios may be appended to the detailed specification, and may be regarded
as part of the formal requirements for the delivered system: at the very minimum, the system
must support these scenarios.
The initial set of scenarios needs to be refined as the design process moves from high-level
to detailed design. New scenarios may also be added to cover parts of the system not
referred to in the original set.
2.3.4 Case Study: Student Handbook System
Consider the following:
Gerda is 26, lives in Germany, and is looking for a one-year postgraduate
course in multimedia or eCommerce in the UK. As well as the content of
the course, she wants to know what sports facilities there are on campus --
she is a keen hockey player.
Heriot-Watt's MSc in Information Technology (Software Systems) is one of
the courses to meet Gerda's academic requirement, and she decides to
use the multimedia student handbook to check on the sports facilities.
Gerda starts up the system, selects sports from the front-page menu, and
searches for hockey. She finds that there are men's hockey teams, and
mixed teams, but no women's hockey teams. She decides also to check up
on the range of cinemas in Edinburgh, in particular looking for cinemas,
which show non-English language films. She finds details of the Edinburgh
Filmhouse, and starts up a browser to access the Filmhouse Web site for
There are several points worth noting about this scenario:
It is invented (though it could of course be based on a real person and situation).
It tells a story, and as such represents one possible thread through the information
space, which the multimedia system presents. There will therefore be many parts of the
system not visited in this particular scenario.
It includes biographical details of the protagonist, to give context and plausibility to the
It is a "top-level" scenario, in that details of the user's interaction with the system are
vague and non-specific. The specifics (e.g. what links the user selects, which keys are
pressed or buttons clicked) depend on the detailed screen design and navigational
structure, which will not have been decided at the early stages of design.
3 Structure, Content & the High-Level Storyboard
The first step in design is to identify the media content, and how it will be structured, both
internally, and as presented for navigation to the user.
In this topic the issues surrounding content identification and structuring are introduced.
The first stage in planning the content of the application is outlining.
The outlining process:
Uses same basic technique as outlining content for an essay, identifying main
sections of the content under specified headings, then identifying subsections and
subsection headings within each section, and so on.
The main difference (from an essay) is that it translates the outline structure (the
content entries) into branches (points of decision) on the screen.
Thus the major headings in the outline become the options available to the user in the
main menu of the program; subheadings form subsidiary menus on branched
This branching provides a halfway-house between the linearity of a standard
film/video outline, and a hypermedia network, which includes lateral as well as
At the high-level design stage, the outlining is refined down to the level of "scenes" or
"interaction sequences" or "high-level tasks" (from the perspective of the user of the system).
These correspond to chapters or sections in a textual document, and are the nodes on the
outline or logical structure diagram.
3.2 Content Identification
Starting from the detailed requirements specification, the next stage in high-level design is to
list the major components or artefacts which the system will require as its building blocks.
Composite media blocks such as text, pictures, audio, or video, as well as any program code,
which will be needed to implement the required functionality should be included.
For each block or component item, the following properties need to be ascertained and
The media types involved, e.g. still drawings, photographs, audio (speech, music,
sound effects, etc.), live action videos, computer-generated animations, cartoons,
The expected running time (for sound samples, film clips or animations).
The extent to which new content (or code) is required, or existing available content
(or code) can be reused.
If existing material is to be reused, the copyright or IPR issues associated with reuse,
and an estimate of the time and cost of creating or adapting the content.
A catalogue or database should be established at this stage, listing the separate components
it is anticipated will be needed to fulfil the requirements. This will form part of the high-level
storyboard, which is the definitive record of the high-level design. (The structural and
navigational diagrams described in the following sections comprise the other major content of
the high-level storyboard).
Although the necessary content may appear to follow directly from the requirements, there
are nevertheless choices to be made even at this stage. The QOC (Question, Options,
Criteria) method of design space analysis (described in detail later in Topic 4), may be used
here, as in other areas of the design process, to structure the discussion and document the
design decisions reached.
Initial content choices may need to be changed later in the light of emerging constraints, e.g.
of time, availability, space and size restrictions, copyright issues, etc.
Multimedia Essay -- Content Identification
3.3 Navigational Mapping
The navigational map of a system is a diagram showing the components as nodes and the user-
accessible links as branches. You have already seen examples (e.g. the navigational map of a
Web site developed in the practical activity at the end of Topic 1).
The navigational map represents the structure of the system as seen by the user. In contrast, and
in some ways cutting across this, is the system-determined sequencing of presentation --
represented in design tools, and in film-based metaphors, by the time-line. This represents the
order in which, left to itself, the system would present the material to the user or viewer. This could
be termed system-side sequencing.
System-side sequencing defines the "logical flow" of media artefacts presented to the user. At one
extreme (e.g. a feature film on DVD) this may represent a linear path through a complete subset of
the material, governed by choices (of sound track, subtitles, version, etc.) made by the user prior
to requesting "play". While most systems are not at this end of the spectrum, the majority will
include sections, perhaps quite large sections (in terms both of running time and storage space),
which are intended to "play" continuously and autonomously once initiated.
However, it is a basic principle in the design of interactive media that the user should always be in
control, so the designer should always ensure that it is possible for the user to interrupt the system
during a system-driven presentation, for example to pause, stop, advance, rewind or quit the
We shall use the term detailed storyboarding for the sequencing and synchronisation of several
media elements to provide a system-driven presentation sequence. (The use of Macromedia
Director for detailed storyboarding is described in detail in Topic 6.)
Components with internal logical flow (in the film metaphor, often thought of as "scenes") should
be shown as a single block on the navigational map, with links to other components to which the
user can branch on interrupting the play sequence, or on its completion. In effect the navigation
map specifies the links between the scenes (or other content components), and so defines the
story or stories that the presentation can tell.
Any system, which allows non-sequential access by the user qualifies for the description,
hypermedia (defined in Topic 1). A hypermedia system provides connections (usually called links)
between components, directly accessible to the user, by means of which the user can choose one
of a potentially large number of possible paths through the system or material.
In designing a navigational map for a new project, it is useful to distinguish in more detail between
different subclasses of non-linear structures within the overall "hypermedia" category. A more
detailed classification of navigational map structures is as follows:
1. Linear: users are constrained to navigate sequentially from one scene to the next (see
2. Hierarchical: users navigate along the branches of a tree structure, defined by the natural
logic of the content (see Figure 24)
3. Nonlinear: users navigate freely through the content of the presentation, not constrained
by predetermined routes (see Figure 25)
4. Composite: users may navigate freely (non-linearly), but are occasionally constrained by
linear presentations of particular material and/or information that is more logically
organised in a hierarchy (see Figure 26)
Figure 23 - Linear Navigation
Figure 24 - Hierarchical Navigation
Figure 25 - Non-Linear Navigation
Figure 26 - Composite Navigation
4.2.1 Introduction to Detailed Storyboarding
We have already used the term "high-level storyboard" to describe the document, which is the
primary output from the high-level design process. This includes the major content blocks, the
logical structure, and the (high-level) navigational map.
Storyboarding at the detailed level corresponds closely to the meaning of the term in film
production. In this topic we shall use the term "storyboarding" to imply this detailed-level
In this context, storyboarding has the following features:
It is a powerful and simple technique for capturing ideas about the form and
appearance of a system.
It is derived from the world of film and video production.
In planning a scene, a storyboard is created representing the different shots that will
be linked together to form the scene.
In multimedia design we can use a pencil and paper drawing, or a sketch created with
a drawing tool on a computer, to identify the main features of one screen, to a chosen
level of precision.
A series of such drawings can be linked together to illustrate the links and transitions
Each structural block or scene identified in the high-level storyboard will have a general
description of its content in the high-level storyboard. This is analogous to a section of the
"application script" in film terminology.
The first stage in detailed-level storyboarding is to refine the application script where
necessary to include a detailed specification of:
The video or animation sequences that have to be captured and created.
The pre-existing resources that are to be included, and how they need to be edited or
The user interface components, both standard and custom-built, which will be
Any additional required functionality.
The navigation map of the paths through the material available to the user.
The storyboard itself is a graphic representation of the proposed multimedia application,
which is essentially a realisation of the specification. In particular the storyboard:
Can use standard templates.
Makes explicit the hypermedia linking, at screen level.
Provides a framework against which the history of the development of the application
can be monitored and controlled, through the production log, in which the production
progress of each media unit and component is recorded as annotations of the
Supports the combination and composition of the many and varied resources, which
need to be created and collected to make up the complete system.
Macromedia Director is the tool, which most directly supports the storyboard metaphor for
multimedia production. This is introduced in detail in the Topic 5. For the rest of this topic we
will concentrate on systems for delivery on the Web, and introduce the use of a particular
Web authoring tool (DreamWeaver) as the main support for the storyboarding process. (An
alternative Web authoring tool could be substituted without major change.)
Figure 40 - Storyboard
An example of a storyboard for part of an interactive tutorial on animation is shown in Figure
40. The detailed navigational map for the same section is shown in Figure 41. Note: Textual
annotation can be used in place of sketches to indicate the contents of screen areas. The
icons and other interface resources needed can be listed with the navigational map, as in
Figure 41. When the design has been carried through to the prototype stage, the initial
storyboard can be annotated (as in Figure 40) with screen shots of the final look of each
Figure 41 - Navigational Map
Multimedia Essay -- Detailed Storyboard