Website Designing

Design_Phase.doc

The Design Phase - how you are going to do it

Design your application

The design phase includes:

· content design,

· instructional design,

· structure design,

· page design,

· flowcharting,

· storyboarding,

· interactivity design,

· design of file management, file transportation and file storage, etc.

These design issues will be expanded in following sections. When preparing the design and planning documentation, these design issues need to be included with clear section headings. The format of the document is less important when compared to its content and clarity. This phase should start with a high-level design or the architecture planned for your application. This part of documentation is an overview of how you intend to meet the requirement specifications developed in the previous analysis phase. It will include diagrams and text to specify the following:

· overall structure of the application;

· typical screen and/or frame layouts;

· the time-line for the application;

· navigational controls and interactivity;

· the content and format of information that will form the message; and

· the platform and transmission medium.

Content and instructional design

You should have a general idea of what will be included in the application, even at the early stage of development. The design of content involves many experts from different fields (especially from the client side). To have a detailed list of all the files to be used is not necessary and hardly possible at this stage. Nevertheless, you should have a plan covering what type of files are needed, how you will obtain them, the likely formats, what preparation and editing tasks are required, copyright and licence agreements, etc. A multimedia application is designed and developed for a specific purpose. You should keep the intended purpose in your mind during the course of your application development. You need to pretend to be the users and ask others to test your design concept and re-think again to ensure every media element and every interaction step is necessary. In your design and planning documentation, you may have to state the reasons for certain a designed task. It is important to understand that we are developing an application to deliver the information, not just to display the technology.

Overall structure and flowcharting

The structure and flowcharting will show the major modules (pages) of the application and how the modules (pages) are to be linked together. This can be represented in many different ways - for example, Data Flow Diagrams, State Transition Diagrams, Structure Charts, Screen Hierarchy Diagrams, Flow Charts, etc.

When making your own designs, use the information gathered during the analysis phase to help you write down the major chunks to be presented on the screen/stage. Always try several different possible designs in outline first before going into detail. Fit the pieces together in different ways and select the optimum way to meet your client's needs. Identify both the major pieces of data and the procedural steps that will have to be taken to process that data. For each part of the main structure define the:

· goal of this page or this component of the movie;

· tasks the user will perform in this page;

· content needed for each page.

· Screen layouts

Sketch screen layouts on grid paper or make a dummy screen using a computer package and print them out as a screen dump to show all the screens of each main type so that everyone knows what they will be working within. For example, show where the corporate logo will go and how big it will be if it is to appear on every screen/page. It is important to ensure that the layout fits the screen the users will be using and has room for all the components required, such as, control buttons, error messages, icons, titles, labels, etc. Always check that text is large enough to be read and that "hot" areas are big enough for all hands and device types that are trying to select inside their boundaries. Any system works better if it uses standard and consistent approaches. Control buttons with the same function should be in the same place on every screen that uses them. Similar functions should work the same way on every screen.

Timelines and Storyboards

Provide a diagram to show the time-line involved for the whole movie and, if necessary, for any part that is critically time-dependent. This involves drawing a simple diagram that shows time varying along the x-axis and above that various lines showing when different segments of media data will be displayed and how long they will be shown - for example, the opening (or splash) screen displays for 10 seconds followed by a narration of 25 seconds that introduces a video that needs two minutes to display in its entirety but starts 3 seconds before the narration ends. In traditional film, television and multimedia design this may be done with a "storyboard" that lists a scene-by-scene description in the order in which the final film will appear. Some designers will make a rough sketch of each scene and summarise the action to take place. The content or scenes may be prepared in a totally different order of course, but in the final production movie they will be put together in the time order defined in the storyboard or time-line. The movie will be a simple linear movie, a collection of scenes that will always be in the same order, even if flashbacks are used, because there is no user interaction except to rewind the finished product in total.  In Web page design, such storyboard presents the layout of each page. Since gridded papers are often used for drawing storyboard, storyboard is also called 'design grid'. In interactive multimedia applications, the order of scenes in any one "performance" may not be fixed, but the principle is still the same. You must show how the various segments are linked in the order they will appear in the finished product. On the time-line you should show major points or time zones at which the user may jump forward or back to other parts of the application and whether this will be allowed anywhere in the scene or just at certain points. Later you may expand the storyboard to develop a detailed "script" that lists all the narration and text in one place. (Not to be confused with a program script which lists the instructions given to the computer and its software to control how the application works.). This storyboard script places the text and narration in time order. Into this you can insert place markers for the video clips, audio files, animation sequences, graphics files and narration files as they occur in the time-line. Usually it is best to write separate scripts for all but the simplest of such complex features such as animated movies and video.

Interface, navigation and Interactivity

It is important for the end user to feel that they are always in control of the application. The look and feel of the user interface, which encompasses the screen layout and the controls provided on it, will often determine whether the user feels confident with the application or not. It is equally important for the client that the application only allows the user to do the things that they want the end user to do. These features must be specified. User centred design of navigation controls allow the user to move at will through the application. This is an important part of interactivity. However, there are other features that may be provided, like being able to turn the volume down, replay selected parts only of a movie, change the colour palette, and input data, which allow the user to change the presentation of your application. Taken a stage further if you wish to allow it, user interaction could even cause a change to the story in a movie or change the behaviour of character in the story. The limits of what the application will allow must be defined in your design specification. Three very important points to remember are:

· the user interface should be as intuitive as possible to the end user,

· interface should allow for user's error,

· makes use of aural feedback sparingly.

Delivery Platform and Delivery Media

The target platform or platforms - that is, the range of equipment the user might have available to them to access you application - must be specified. Parameters that you should define for each of the platforms you will allow include:

· CPU - for example, PC or Macintosh or Silicon Graphics, etc. and the particular model;

· operating system - for example, WINDOWS NT, MAC OS 7 or Unix;

· device interfaces and drivers - for example, SVGA for the monitor, 16-bit sound card;

· memory - how much must be free for the application to use;

· monitor size and colour depth - for example, 14 inch and 256 colours;

· drives - for example, 4x standard speed CD, HDD with 100MB free; and

· delivery medium- e.g. modem with Internet access or Broadband access

File management and transport medium

When planning your multimedia application, it is important to know where you will store your files (the media files to be used, temp. file generated from the development, different versions of file, and different versions of application) and how you want to control the access. It is also important to work out the file naming convention (how to name a certain type of file, how to differentiate different version of file, the file extension, etc). Multimedia applications may be delivered in a number of different ways other than CD or Web. In fact, it might be appropriate to use more than one of the available transport media or to drop the use of it altogether in order to overcome some of the current limitations of the Web. You should be aware of what is available from other media for just this reason. Possible transport media currently in general use are:

· Hard disk

· CD-ROM

· DVD

· Videotape

· Kiosk - as in supermarket sales videos

· Corporate network - Intranet

· Internet/WWW

The technical specification

The technical specification or design document combines structure, screens, scripts, time-lines, navigation design, user interface, content, etc, into one document with which everyone can identify and work. It provides the main outline for the project and is the document from which the prototype or working model and then the final production will be made.

Now review your technical specification

It is a good time to review your technical specification now. You will review it and other parts of the application many times before the project is finished. This does not mean that you will change it each time you review it. You are checking to see if it does need to change. The earlier a fault is discovered, the faster, easier and cheaper it is to correct. Check it against the client's original ideas, their corporate mission statement and the particular mission of the application as defined in your functional specification. If it does not "gel", change the technical specification until it does "gel" before you start to make anything.