Software System Construction:Presentation layer – the user interface

10.5 Presentation layer – the user interface

In conjunction with building the business logic the developers will be developing the user interface so that they can test their work and allow users to play with the system. In developing the user interface part of a web site it will be easier if some basic organization is established at the beginning. We will be using DreamWeaver to build the web interface. There are two fundamental building blocks to building a web site with DreamWeaver:

• Make a DreamWeaver template for the web site to control the layout of the pages, e.g., the position and the content of the navigation buttons;

• Define styles for the site and store them in an external style sheet.

10.5.1 Dream Weaver Templates

The main benefits of the template are that (a) a common look and feel can be maintained for the site as a whole and (b) maintenance and site makeovers are made easier. Any pages that are attached to a given DreamWeaver template will be updated automatically when changes are made to the template, such as navigation bars, background colours, standard wording, and graphics. For complex web pages there might be multiple templates, perhaps one for each subsection of the web site; in the theatre site there might be different templates for Internet ticket sales, internal operator ticket sales, and site administration facilities. We will use a single template as the foundation for all the ticket sales processing in TicketManager (figure 10.10).

The DreamWeaver template allows areas of a page to be locked, such as the header and the footer so that all the pages using that template must follow the same design. Furthermore, any changes to the template will be mirrored in all the pages that are attached to that template automatically by DreamWeaver. The fixed area at the bottom of the page is actually a library item – these can be shared site wide by all pages and any change to the content of the library item (e.g., the organization's telephone number) will be automatically updated on each of the pages using that library item.

The TicketManager design is rudimentary, but adheres to the tenets of good web page design. The template fixes the width at 600 pixels to cater for 640 pixel monitors (some pixels are always wasted with borders). This may be rather conservative, but the TicketManager is designed for usability rather than gratuitous style. A graphic designer could enhance the look and feel of the site at a later stage by modifying the template and the style sheet.

Navigation of the TicketManager site is in the header and will therefore be identical on every page in the application. Navigation has been deliberately kept simple and uses text links with a mouse-over defined in a style sheet. The only image in the template is the TicketManager logo above the navigation bar – this site should load quickly, although response time will depend in part on the ability of the server to handle database requests.

10.5.2 Style sheets

If you have used a word-processor you will be familiar with style sheets (you might also be rather confused by them). Style sheets are used on the web to achieve the same result as in word-processing – to have a consistent style and the ability to make site-wide changes at the click of a button. For web site development cascading style sheets (CSS) are used. These can be defined in three places:

• In the document against a specific section of content

• In the header of the document

• In a separate file (e.g., theatre.css)

For the TicketManager application, all the styles will be held in a separate file as this gives the greatest ease of maintenance and will safeguard the consistency of the web site look and feel. All the pages in the site will access the style sheet file, theatre.css (figure 10.11). Styles defined for the presentation of text include: heading1, heading2, bodytext, and smallbodytext. In addition, styles can be defined for hypertext links, table cell backgrounds, and so on, giving the designer a fine degree of control over the appearance of the site. If the styles are used consistently throughout the site then changing font weight, font colour, background colour, etc. and having the change affect every page on the site becomes a simple task.

10.5.3 Browser compatibility and bandwidth

Unfortunately, Netscape and Internet Explorer do not implement the various standards (e.g., cascading style sheets) in exactly the same way. If more sophisticated techniques are used, such as applying styles to tables, or using dynamic HTML to pop up windows, then there is the possibility that the site will work correctly with one browser, but not in others. The situation is further complicated due to older versions of browsers, such as Internet Explorer 3, that do not support the newer features (e.g., cascading style sheets) being still in use. One approach is to write for the lowest common denominator, avoiding anything but the most basic HTML code. Another approach is to add code to the web site to detect the type and version of the user's browser and to serve up the HTML accordingly. This can be done client-side using JavaScript, which DreamWeaver can generate automatically. A more sophisticated system would involve server-side code, such as ColdFusion or ASP, which delivers the HTML best suited to any particular client. The server-side solution affords the greatest flexibility and moves toward a proper separation of content and formatting, allowing delivery to different browser software and also to different platforms, such as a mobile telephone or a personal organizer.

Testing on different platforms with different browsers is therefore essential. It is also important to test the site using different monitors so that we may ask: 'how does it display on a monitor set to 640 by 480 pixel resolution?', 'using different connection speeds, how long does it take to load using a 24k modem?', and 'how does it look on an Apple Mac?'.