2. Lazar’s Development Lifecycle Define the mission & target users Collect user requirements Create and Modify Conceptual design Create and modify physical design Perform usability testing Implement and market the website Evaluate and improve the website
3.
4. Mission: Characterising Websites Examples Goal Magazine, e-zines, galleries, museums, media clubs, organisation, personal home pages Entertain Universities, schools, charitable foundations, non-profit organisations, government, businesses, political organisations, personal homepages Inform or educate Navarro and Khan’s Taxonomy of Web Site Missions
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
Editor's Notes
The starting point is an initial idea or concept . This can be further defined and refined through brainstorming . Rough storyboards can be used as an aid to visualisation. The topic can then be further researched.. A feasibility study may be carried out and initial estimates of costs, timescales and, where appropriate, projected revenue made. These estimates are often based on previous work. A production overview document called the proposal or brief can then be developed. This document should include an outline of how the subject is to be approached, the scope of the project and the intended audience. A history of the company's work and a budget could also be included. To be successful the proposal must be 'highly readable, and concise' and be slanted to suit the type of production. The proposal is often delivered face to face and hence good personal communications are required. In this situation a storyboard may be used as a graphical aid to communicating the idea. A multimedia developer may then pitch their proposal to a potential client in a bid to get them to commission their proposed project. Alternatively a client may ask 3 or 4 developers to pitch for a given project they have in mind . Once the client and developer have agreed in principle to go ahead with the project a detailed content outline, schedule and budget can then be drawn up.
The next stage is to produce a more detailed requirement specification. The treatment is expanded in detail to include all the aims, objectives and subject scope which were covered in the successful proposal. The requirement specification should cover the minimum hardware and software configuration(s) needed to run the application, the intended audience and the aims of the application. The content outline could also be included along with general navigational and screen layout guidelines. The requirement specification may have to be refined as the project develops. The requirements should also specify when the application is to be developed and at what cost. The requirements specification allow the client and developer to agree the scope, deadline and deliverables of the final product. Once the product has been completed the requirements specification can be checked to ensure that all the specified requirements have been met. These requirements are gathered through consultation with the client and where possible typical end-users. The complexity of the requirements gathering stage depends not only on the complexity of the application but on the quality of the communication between the customer and the application 'producer'. The quality of communication is affected not only by personal communication skills, but by the customer's knowledge of what is possible, and the producer's understanding of the subject matter. This 'knowledge gap' can be 'the single most significant barrier to unambiguous communications'.
Demographic Information – Allows you to check how representative your selected group of target users are in relation to the expected audience for your web site. e.g. if your website is targeted at no specific gender but the responses you have gathered are dominated by a single gender your responses are not representative. Other demographic information could be occupation, salary. Domain Knowledge What knowledge and previous experience are users able to bring to interacting with the proposed web site? For highly specialised websites a knowledge of related acronyms and jargon may prove important. If this knowledge is required, the target user population need to be queried to determine the actual levels of this type of knowledge they have. Computing Experience Novice, expert or intermittent users have different levels of experience and hence, needs. Operating Systems: Unix vs DOS vs Windows. Applications: MS Office Suite vs MS Visual Studio Word processing vs Spreadsheets vs Databases Adapting metaphors? e.g. shopping carts, desktop etc. Record positive and negative experiences in use cases. Computing Environment Intranet vs Internet considerations No centralised database for internet users makes this a difficult exercise. Includes: Browser type, monitor size, colour resolution, connection speed, use of plug-ins Content What content do users want on the site? Examples of content include: Company details, downloads, FAQ’s, latest breaking news, exclusive images or interviews. Does the site content differ from existing content? The client doesn’t always know what the users want, so users should be encouraged to provide ideas for content. Benchmarking Sites to aspire to Ideas for site content Client-Developer-User Triangle. Clients and users don’t always agree on site features. Other Considerations Utilise existing data e.g. company surveys.
