Creating the Mock Site

Creating the Mock Site

After all design photo-types have been finalized, it is time to create what might be called the mock or alpha site. Implementation of the mock site starts by cutting a digital comp into its pieces and assembling the pages using HTML and, potentially, cascading style sheets ( CSS ). Try building the site using templates so that the entire site can be quickly assembled. However, do not put the content in place during this phase. Many of today’s modern publishing tools aid in the assembly of sample pages from screen composites. For example, consider the digital home page composites of the Demo Company site shown below.
We then can use a tool such as Macromedia Fireworks (www.macromedia.com/software/fireworks) to “slice” the sample layout into its appropriate pieces.

Designers should be cautious when using the HTML produced by slice and save features of applications such as Fireworks or Adobe ImageReady. These applications often produce non-standard, very complex, or difficult-to-maintain markup.

With the various pieces that make up the Home Page and the various sub-pages of a site, a Web designer can use a Web editor to assemble the components into fully working pages lacking real content; greeking text of the form “lorem ipsum dolor sit amet” should be used to give pages form. The fully constructed mock site may lack real content, but can give developers and testers a true flavor of how the site will eventually work.

Producing the HTML
While visuals and technical elements are very important to Web designers, the heart of nearly every modern Web page is still markup. Creation of HTML/XHTML should be taken very seriously as it must be a stable foundation upon which we will build presentation and interactivity.


Interactivity of page
Build with server and client side programming
Presentation of page
Build with HTML, CSS, flash and media elements
structure of page;
Build in HTML / XHTML


Yet despite its important as the page’s foundation, Web designers often are more concerned with how they creation is. In truth, there are pros, and cons to every method of HTML page and some of their pros and cons are presented in one of the images in the last post.
The reality of creating HTML documents is that there are occasions to use nearly every approach. For example, making a quick change of a single tag often is fastest in a pure text editor, saving out large existing print documents might make sense using a translator.

The Site Plan

The site plan

Once a goal, audience, and site requirements have been discussed and documented, a formal site plan should be drawn up. The site plan should contain the following sections;
Short Goal Statement;
This section contains a brief discussion to explain the overall purpose of the site and its basic success measurements.

Detailed Goal Discussion;
This section discusses the site’s goals in detail and provides measurable goals to verify the benefit of the site.

Audience Discussion;
This section profiles the user who would visit the site. The section would describe both audience characteristics as well as the tasks the audience would try to accomplish at the site.

Usage Discussion;
This section discusses the various task/ visit scenarios for the site’s users. Start first with how the user arrives at the site and then follow the visit to its conclusion. This section may also include a discussion of usage measurements, such as number of downloads, page accesses per visit. Forms being filled out, and so on as they relate to the detailed goal discussion.

Content Requirements;
The content requirements section provides a laundry list of all text, images, and other media required in the site. A matrix showing the required content, form, existence, and potential owner or creator is useful, as it shows how much content may be outstanding. A simple matrix is shown below;

Technical Requirements;
This section provides an overview of the types of technology the site will employ, such as HTML, XHTML, CSS, JavaScript, CGI, Java, plug-ins, and so on. It should cover any technical constraints such as performance requirements, security requirements, multi-device or multiplatform considerations, any other technical requirements that are related to the visitor’s capabilities.

Visual Requirements;
The visual requirements section outlines basic considerations for interface design. The section should indicate in broad strokes how the site should relate to any existing marketing materials and provide an indication of user constriants for graphics and multimedia, such as screen size, color depth, bandwidth, and so on. The section may outline some specifics, such as organizational logo usage limitations, fonts requirements, or color use; however, many of the details of the site’s visuals will be determined later in the development process.

Delivery Requirements;
This section indicates the delivery requirements, particularly any hosting considerations. A basic discussion of how many users will visit the site, how many pages will be consumed on a typical day, and the size of a typical page should be included in this section. Even if these are just guesses, it is possible to provide a brief analysis of the server hardware, software, and bandwidth required to deliver the site.



Content
Item Description Content type Content
format Exist? Owner
Butler Robot
Press Release Press release for new Butler 7 series robot that ran in Robots Today Text Microsoft Word Yes Jennifer Tuggle
Software
Agreement form Brief description of legal liability of using trial robot personality software Text Paper Yes John P. lawyer
Handheld Supercomputer
Screen Shot Picture of the new Demo Company Cray-9000 handheld palm size computer Image GIF No Pascal Wirth
Welcome form
President
Message Brief introduction letter from President to welcome user to site Text Microsoft Word No President’s
Executive
Assistant


Miscellaneous Requirements;
Other requirements may need to be detailed in the site plan, such as language requirements, legal issues, industry standards, and other similar considerations. They may not necessarily require their own separate discussion, but instead may be addressed throughout the other sections of the document.

Site Structure Diagram;
This section provides a site structure or flow diagram detailing the various sections within a site. Appropriate labels for sections and general ideas for each section should be developed based on the various user scenarios explored in earlier project phases. Organizations of the various sections of the site is important and may have to be refined over time. Often, a site diagram will look something like the figure below.

Staffing;
This section details the resources required to execute the site. Measurements can be in simple man-hours and should relate to each of the four staffing areas; content, technology, visual design, and management.

Time Line;
The time line should show how the project would proceed using the staffing estimates from the preceding section combined with the steps in the process model outlined earlier in this post.

Budget;
A budget is primarily determined from the staffing requirements and the delivery requirements. However, marketing costs or other issues such as content licensing could affect the site cost as well.

This is just a suggested site plan- the actual organization and content of the site plan is up to the developer. However, don’t skip writing the plan even though it may seem daunting. Without such a fashion (almost trial-and-error manner), which may result in many false starts and waste time bids form outside vendors on the Web site without a detailed specification.




A site diagram will look something like this one shown;

Search Home copyright key
Site map database-driven
About Contact Us Jobs
History News
Products Releases FAQs
Domes Corporate Events
Robots Production
Balloons Economy
PSVs luxury
Cargo
Sport

A finished plan doesn’t allow you to immediately proceed to implementation. Once the specification is developed, it should be questioned one last time, preferably by a colleague or someone with an outside perspective. The completed specification may reveal unrealistic estimates that will throw you back to the stage of questioning initial goals or audience. If it survives, it may be time to actually continue the process with the design and prototyping stage.