Reading: Identify Relevant Multimedia Elements

Reading: Identify relevant multimedia elements

Identify relevant multimedia elements

Inside this reading:

Designing multimedia products

Project boundaries and proof of concept

The prototype

Storyboards

Schematic diagrams

Detailed information

Navigation maps

Some principles of good design

Flowcharts

Task analysis

Concept analysis

Negotiating the design

Summary

Designing multimedia products

The design of multimedia products continues until the master disk is sent to the printers, or if it is a web-based, until the master is moved from development into production. Most products are then regularly ‘tweaked’ or edited to improve the content, navigation or general look and feel.

Project boundaries and proof of concept

The first need before design begins is to assess the limitations and scope (or boundaries) of the project. Will the product be delivered via the web? If so, maybe this means that virtually no video can be used, and that all audio and graphics will need to be heavily compressed. If the product is to be a hybrid (delivered on both CD/DVD and the web), then the developer might produce two versions; one compressed and one with video grabs.

Once the project boundaries are signed off, then it is often difficult to change. This fact must be explained to clients very early in the analysis stage. Managing directors have been known to take a simple five-minute look at a product and state something like:

Hmmm, two things! I thought the video clips would be much larger when I look at it through my Internet Explorer browser. Just double the size will you…Also I think we should be able to navigate to any screen in the entire product by only clicking one button. Yes that would be great!

(And obviously this occurs after you have compressed over 250 video clips to less than 100K each and completed the hierarchical navigation of the backend of the product).

The best way to avoid this is to produce a functional ‘proof of concept’ and get sign-off before starting the official product.

The prototype

After the analysis is completed, the proof of concept built, and the elements and media files are collected and collated, it is time to move into the design phase. Designing is where the developer conceptualises the way the finished product will navigate, appear and function, by use of a prototype.

To build the prototype the developer needs storyboards, navigation maps and design guidelines.

There are many ways or models for initiating designs (as for example, the way shown below, a typical model that could be used for project development).Whatever model is used, one of the main strategies that is recommended is that there is continuous review of the design.

Figure 1: A project development model

Another example of a continuous evaluation process is basically as follows:

Funding
Planning
Designing
Production
Testing
Marketing

This one expands the areas of production, testing and marketing. This model has similarities to the famous design methodology designed by Dick and Carey, taught to many multimedia professionals during the late 1980s and 1990s.

Storyboards

Storyboards are graphic representations or sketches of what the screens will look like in detail. They are an excellent way to convey ideas to clients, management and co-workers.

Storyboard sketches and notes describe each image, movie segment, sound, text and navigational cue. They regularly show text areas, graphic boxes, navigation buttons, switches (such as for sound on and off) and menus. Storyboards should also have text on details such as:

general colours (backgrounds)
font sizes and types
balance of screen design (symmetrical, asymmetrical, etc)
response information
what sound and video will play when buttons are clicked
positions of hot spots
common user movements (such as ‘next’ buttons) and or hotkeys
optical weight (something that draws the user’s attention, usually a graphic)
scrolling screen information (which is difficult to explain graphically)
approximates sizes of boxes and other features
what buttons will do (for example, fade, move, etc).

The two common approaches often taken to storyboarding are schematic diagrams and storyboards with more detailed information. The approach depends on the scope of the project, the size and style of the team. The extent of detail depends on the project.

Schematic diagrams

Rough schematic diagrams may suit small projects, or even at the start of a large one, to help other team members conceptualise and visualise the end product. /
Figure 3: The schema for a storyboard

Detailed information

A storyboard with detailed information is used if the project needs to be described in great detail with words and sketches for each and every screen image. It may also detail sound, navigational choice to describe specific colours and shades, attributes, button shapes, styles, responses, script and voice inflections.

Storyboards can take many forms. The following diagram is a simple sample sheet that would generally accompany a pictorial storyboard. Such a sheet would have information on individual screens and the information and action that would appear on specific pages.

Figure 4: Sample sheet to accompany a pictorial storyboard

Often large expensive projects spend a great detail of time on storyboards, as many developers believe that if they get the storyboard agreed on and signed off, then the project flows smoothly, as it eliminates costly changes later. (Remember it is easy to update or change a sketch, it is not as easy to change the ‘look and feel’ of over 1000 screens in a multimedia application).

In both cases, a project outline storyboard will be needed. This should outline the structure and content of the application. Such storyboards can also act as navigation maps in some cases.

Storyboards can be handwritten, produced in packages like PowerPoint or even in graphics packages like Paint or Photoshop. Note the following, a rough hand written form:

Figure 5: Example of handwritten storyboard

Minimising movement

Another useful feature of storyboards is to visualise the placement of elements and navigation buttons.

Generally it is wise to control the placement of such things to allow the users to focus on content. An example of this is if the ‘Next’ button moves around the screen, the user will often become frustrated as they are focussing their attention on a process instead of important information.

Also, if graphic sizes are not consistent, the graphics could appear all over the page and push other elements (such as text) out of alignment. This again may cause lost concentration ands the user might miss vital information. The general rule is to make it easy for the user to read, use and navigate.

So, if storyboards are adhered to, then the elements should be designed (cropped, re-sized, etc) to fit the space. Spatial arrangement is especially hard for clients to visualise without storyboards.

Below is another example of a storyboard, this time created in PowerPoint. It is another simple way of increasing the ‘mental image’ for all involved.

Figure 6: Storyboard created in Microsoft PowerPoint

Navigation maps

Mapping the structure of a multimedia product is an essential task in design. Navigation maps (or site maps) assist the process as they help to:

organise content into logical blocks
organise information into a hierarchy (or not!)
explain the logical flow of the proposed product to the client
explain to programmers and developers how the users will navigate through the software and what areas to control or block.

In general four organising structures are commonly used in navigation maps for multimedia applications (also shown below in Figure 7).

1Linear: Users navigate sequentially (similar to PowerPoint presentations, one screen or idea followed by another with limited navigational control).

2Hierarchical: Similar to linear, but with the potential to branch into areas of interest (similar to a typical hierarchy chart of positions in a company). This format is often used in topic-based navigation.

3Non-linear: Users can navigate anywhere they want in any order. This is often called an exploratory navigation scheme.

4Composite: Generally allows free navigation, but controlled for key information where the model reverts to linear for short periods.

Figure 7: Diagrams to show four organising structures commonly used in navigation maps

There are many advantages and disadvantages for allowing users the freedom to navigate where they want to. Again it depends on the content, the users and the business goals. In some ways, this can be ascertained and potentially agreed on after completing the initial business analysis. In Figure 8 below, the screens are arranged in a straight line with only forward or back movement through the project. This is a good choice if you need to present information in a specific order.

Figure 8: An example of a linear structure — screens are arranged in a straight line with only forward or back movement through the project. This is a good choice if you plan to present information in a specific order.

Because the model in Figure 8 does not allow a user to ‘jump’ from module to module it may not be the best model for discovery based interactive adventures.

Some principles of good design

Any well-designed system, not matter what structure is chosen, should always allow the user to know:

exactly what section they are in
how to exit or restart the program
how to find help
how to use the index or search tools
what sections are important.

Allowing the user to know basic navigation principles can be achieved by:

colouring sections
using page titles
supplying directional text or markers
using different icons or graphics to indicate importance or locations
using familiar navigation buttons.

Flowcharts

Flowcharts also help in designing effective multimedia. Flowcharts illustrate the process in which a user will enter, engage and exit the multimedia product. They are particularly useful to ‘double check’ that the navigation structure works and is designed efficiently.

The two most common ways of creating flow charts are to use task analysis or concept analysis.

Task analysis

Task analysis is basically breaking up a task into components. For example if a task analysis was designed for driving a car, it could be something like:

Find keys/Open door
Sit in car/Put on seat belt
Check handbrake and gears/Start engine
Check mirrors for traffic etc/Put in gear
Indicate/Apply accelerator…

One of the main ideas behind task analysis is to ensure users get the information in the right order.

Concept analysis

Concept analysis is where information is organised as concepts, not just in linear sets. An example would be studying the history of Australia. One could study it in relation to a timeline (for example, 1770 Captain Cook to 1788 The first fleet, etc). However if someone looked at it conceptually they might study the subject and virtually ‘jump’ around from relevant topic to topic (from Indigenous Australians to government, to colonisation and society, for instance).

It is just a different way of organising information. In many ways the web is built in this conceptual format, as one can hyperlink from idea to idea without restrictive boundaries.

Whatever model is used, a multimedia developer must decide on the best model to follow as early as possible in the design stage.

Figure 9 below has a sample flowchart to illustrates how a user would navigate through a program.

Negotiating the design

One of the main obstacles in multimedia development is obtaining agreement on the end product. This is often complicated because the client cannot write the detailed specifications by themselves (that is, they don’t know what the limitations of the technologies are and aim either too low or too high).

The expectations of clients might be understood, not as their inadequacy, but as a product of multimedia salespeople and consultants overselling multimedia in the last decade of the 20th century, and in some quarters the industry was given a questionable label (a fact somewhat true of the whole IT industry, especially around the time of Y2K).

What regularly happens is that the client agrees on the general direction and signs off, however once they start to use the system and understand how it fits together, they then often want amendments. There are of course simple ‘on the surface’ changes, however if the client or manager is not IT savvy, then they may well not know the difference between back-end and surface changes.

Even when specifications outline the precise nature and scope of the development work, some clients still see any amendments they propose as minor. Some apparently ‘minor’ requests can in fact require a total redesign.

There are no 100% guarantees. Much of the skill of a successful multimedia developer is to explain the product development cycle as simply and unambiguously as possible to all the key stakeholders.

However once this is done and sign-off is achieved, the developer must ensure that any additional work requested is funded, and clients are aware that the work is a matter of modification and not repair!

This is why showing clients a pictorial representation can be so vital.

Summary

Design in multimedia begins with clear and mutual understandings between the developer and the client as to the product boundaries and the scope of the project. This can be achieved by producing a functional proof of concept, to be signed off by the client. After analysis, a prototype based on the chosen model or structure can be developed, using storyboards, navigation maps and design guidelines. A range of pictorial methods can be used to examine the functionality of the product and its adherence to principles of good design for users. Pictorial images such as storyboards and especially flow charts are also vital in communicating design and function to key stakeholders.

1730_reading.doc