Unit 4.3. Tips for Web Design
Working on the Web
This unit contains some general tips for designing Web pages in your storyboard and prototype. There are no right answers, and there are pros and cons for every design choice you might make. However, there are general rules and conventions that most Web developers have adopted. Below are some tips and advice that might prove helpful, and some pitfalls that you can avoid.
Search Screens
Consider whether you need to offer the user a search screen. The primary function of most applications is to retrieve information for the user. Whether this is referred to as reporting, records retrieval, display, inquiries, queries, or viewing records, it is the same task of quickly accessing and showing a user the information that is needed. The majority of the time, people go to an application for information.
For this reason, many applications begin with a “search screen.” A search screen is used to find a particular record so that the record can be viewed or updated, or even deleted. Sometimes the search confirms that the record does not exist in the system. At other times, multiple records may be returned that all meet the criteria for the search.
Starting from the data entry screen is akin to thinking like a developer. Developers often focus on the need for screens that interact with the database, such as data entry screens and screens to update data. For example, a developer might know that an application needs to add a record to the STUDENT table, so the developer designs a screen that lets users enter a first name, last name, and so on. That will not make sense as a starting point for a user. It is true that database applications require data entry screens. However, that cannot be the first screen that a user sees. A user may want to check what data is in the system before entering a new record. How does a user find the record that they need to change? If you start with a search screen, you can include a button called “Add a New Record.” If you want to present a data entry screen to the user first, make sure to include a button that reads “Search.” Otherwise, from the user’s perspective, all he or she can ever do is enter records.
For search screens, think about which identifiers are meaningful to a business user. For a database with student records, are users required to know a student ID number to look up a student? Can first name and/or last name be used to look up students?
Also imagine each of the following cases, and envision the screens that you would need in each case:
Multiple records are returned from a search
One record is returned from a search
No records are returned from a search
Reusing Screens
In many cases, the same screen can be used for multiple purposes. This is common for screens that both add and update records.
Draw a screen that allows a user to add a student to the system. The user needs to add the student’s first and last name, address information, employer, and a phone number. For an example, refer to Figure 4.1, which you build later in this book as part of the sample application.
Figure 4.1. Screen to add a student’s personal information.
Now draw a screen for updating a student’s record, as shown in Figure 4.2.
Figure 4.2. Screen to update a student’s personal information.
In Figure 4.2, the user can enter information about the student’s first and last name, address information, employer, and a phone number, as in Figure 4.1. However, since this screen updates an existing student, the student has been assigned a student ID number by the system, and the student’s ID number and current name are displayed.
Compare these two screens. Except for the heading, the screen layout is identical. Often, screens to add records and update records can often be combined into a single screen. Since the screens in this application will be generated dynamically, using PL/SQL, the appropriate title can be given to the page at the time it is put together.
Combining screens appropriately has many benefits. If two separate screens are designed, one for updating and one for inserting, then the screens might be given to two different programmers to develop. Not only would the programmers be duplicating each other’s efforts needlessly, but also it is likely that differences will crop up between the screens, and this is confusing for everyone. For example, screens should include some kind of error checking on what the user has entered, as is covered in Chapter 14, “JavaScript Form Validation.” If this validation is not handled identically, then the screens will function differently, in ways the user does not expect. The add-new-record screen may allow a dash to be entered in the middle of a zipcode, whereas the update screen requires the zipcode to be five or nine numbers only, without a dash. Data that is accepted by the add-new-record screen will be rejected by the update screen as invalid. Small differences in layout and appearance are also likely. Rather than requesting two screens, design this as one screen. One programmer would then create a screen that either displays a student ID and database information in the case of an update, or does not if the user is adding a record. Moreover, the customer will be paying for one screen instead of two.
Keep this in mind when creating a storyboard or prototype. Identifying screens that can be reused for multiple purposes can simplify the design and reduce the number of screens you are working with, and it makes sense from a programming perspective, too.
Navigation Design
Navigation is an important consideration. It is vital to plan for how users will move through an application. Part of creating a storyboard is deciding the order in which users can navigate to pages. Make sure that no page is a dead end, or “orphan” page, that does not provide a menu or some other means to get to another page in the application.
On the Web, navigation is most often accomplished by clicking on buttons or links. For more on buttons that submit forms, see Chapter 6, “Advanced HTML: Forms, Nested Tables, and Nested Frames.” For more on JavaScript events like clicking on buttons, see Chapter 7, “Introduction to JavaScript.” A few other JavaScript events can trigger loading a new page, such as changing a value in a drop-down list or changing a radio button selection, but for the most part, buttons and links are the connections holding an application together.
This is where knowing the users comes in. What are the day-to-day tasks that users will need to accomplish? As stated earlier in this chapter, users may need to access very different areas of the system, such as areas for updating data or viewing cumulative reports that reflect the most current data. Avoid forcing users to navigate through five screens to get to the one they want every day. Identify each task the user needs to accomplish, and create a link for each area. Then create the screens the user needs.
Links can be grouped into menus. Menus make navigation more flexible. If users have a menu or a consistent list of links available to them at all times, they can move easily from one area to another as needed.
Also consider what will happen when users save changes. In most cases they should be returned to the same screen to see that their changes have taken effect. Then they may make more changes and click the “Save” button again, or use a different button to take them to another area of the application entirely.
Tips for Page Layout
If you are responsible for designing a Web application, it is important to adhere to some of the principles of Web design. These are some guidelines for Web page design, from the perspective of a Web designer. Not everyone will agree with even these general rules of Web design, but it is good to know the rules before deciding to break them.
Consistent Look and Feel
As a user clicks through pages in a Web site or application, they should have the impression that they are moving about within the same world. Every page must be identified with the application. This can be achieved by using consistent color schemes, fonts, graphics, and backgrounds on all screens in an application. Some of the real estate on each page may be devoted to a logo or company name.
Positioning a logo in the upper-left corner of a screen is extremely effective. The upper-left corner is the first place the eye travels to on a page, so it is considered “prime real estate,” and placing a logo there will have maximum impact. Creating an association based on a certain logo or look and feel is known as branding. Branding is important for Internet sites, because organizations want to establish their presence on the Web. Even within a company, different applications may have to compete for attention or funds, so branding may be helpful to promote an application, and the new logo may appear on t-shirts or pens to attract attention for the application.
Text
Hold up this book to a computer screen, and compare the page width with the screen width. Chances are that the computer screen is wider than your book. If text is printed from one side of a screen to the other, it is a tiring trip for the eye. Use narrow columns for large blocks of text. Visit some news Web sites and you will see that most, if not all, use narrow columns of text in their articles, even when doing so means having blank space to the sides of the column, or making the article stretch further down on the screen.
Blank space on a page is better than too much clutter. In the world of print media, blank space, or “whitespace,” is a waste of increasingly expensive paper. On Web sites, designers strive for a clean look and feel, and too much clutter on a page is considered distracting. Try using more empty space when possible.
The original HTML specification did not allow developers to use more than one font. However, for some time Web pages have been able to handle multiple fonts. That does not mean a developer should strive to use as many as possible on a page. Mixing font faces, font sizes, and font colors on a page can distract from the information you are trying to convey. Unless you are commissioned to create a Web page for Times Square, be very careful when you are mixing different fonts.
Although the Web is a familiar interface, there are application screens where the user might benefit from instructions about what the screen does. On the other hand, remember that instructions will be seen every time the user navigates to a page, long after the user’s first visit. On later visits, once users have mastered the application, perhaps from performing the same tasks upon it daily, lengthy instructions may become an annoyance, and instructions take up space, or “real estate,” on the page. One solution is to remove instructions from a page, but provide a link that the user can click on to receive instructions for that page. Instructions can appear in a separate pop-up window, which can be done using JavaScript, as shown in Chapter 7, “Introduction to JavaScript.”
Writing for the Web is also different from writing for print media. A print publication may have an opening “Welcome” page, with grandiloquent text that serves as an introduction. Some of this text can seem bloated or inappropriate on the Web. Most Web pages exist to effectively communicate information.
 | Don’t underline text for emphasis. Underlined text will be confused with a hyperlink on the Web. |
Frames
Some design disputes are over whether to use frames or not to use frames. Frames have many helpful uses. To show how frames can be implemented, the sample application included in this book makes use of frames. First, let’s consider some of the benefits of using frames.
Frames can serve as an excellent tool for navigation. A frameset divides a screen up into separate regions, or frames, as described in Chapter 5, “Introduction to HTML: Basic Tags, Tables, and Frames.” One or more of the frames can be devoted to menus for navigation. This makes the application more “user-friendly.” No matter which part of the application a user is in, the user knows where on the screen to look to move to another screen.
Frames are also a good tool for promoting a consistent look and feel. One frame can be devoted to displaying a company logo, application name, or artwork, and remain fixed in place while other parts of the page change or are scrolled through. For example, the top frame in a page displays a logo, while the bottom frame contains a large report that the user can scroll through downwards. Having the logo consistently at the top of the screen creates the impression of being in the same place, despite other frames that change.
Frames are absolutely necessary when one part of a page must remain stationary, while another part of the page can be scrolled through.
Frames have their detractors. Frames can look messy when each frame is displayed with a scrollbar. If a user wants to bookmark a page that uses frames, the original frameset is bookmarked, not the specific combination of frames that the user is seeing. That can be an acceptable result for an application, as opposed to a Web site.
Buttons and Links
Buttons and links allow users to move through an application. A user will come to depend on them and expect to find them easily.
Buttons should be placed in the same part of the page on every screen. There is no reason to have a “Save” button on the bottom of one screen, a “Save” button on the top of another screen, and a “Save” button mischievously off to the side of a third screen. The Web offers many outlets for creativity without this kind of innovation. Users do not wish to hunt for the “Save” button, nor do they appreciate clicking on the wrong button by mistake because it appears in a different place than they have come to expect.
One easy trap to fall into is to give buttons inconsistent labels. The label is the text that appears on the button itself. If this label reads “Save” on one screen and “Store” on another, that is unnecessarily confusing. “Next” and “Continue” are often used within the same application to accomplish the same task of moving the user to the next screen in a sequence. Choose one label or the other for a more professional application.
Cryptic links will not be clicked on. Newspaper headlines will sometimes have teaser headlines to draw the readers’ attention. Once the reader is looking at the headline, they can drop their eye downward to view the article. On the Web, the reader cannot simply glance over to the article to get an idea of the content. The user must click on a link to find out what the text in the link means. If a user is presented with a page full of links, they are not likely to explore every link simply to decipher each one’s meaning. A title such as “Discount Books” is much more effective, and more easily remembered, than a link that reads, “A Penny Saved is a Penny Earned.”
Horizontal and Vertical Menus
Consider horizontal and vertical menus to help users navigate through the application. A horizontal menu is a collection of links listed across the top of a page. A vertical menu is a list of links positioned to the left or right side of the screen, usually underneath the horizontal menu. These menus, or navigation bars, are a staple of the Web, and are known familiarly as “nav bars.”
Typically, the horizontal navigation bar has links to general areas of the application. This navigation bar does not change while the user moves through one area or another. If an application has several general areas that each have different functionality, then a horizontal menu may be appropriate.
Vertical menus, on the other hand, change depending on which section of the application the user is in. The options listed in the vertical menu are specific to the area that the user is currently visiting. When a new area is clicked on the horizontal menu bar, the vertical menu bar changes to reflect what is available in the new area.
Accessibility
The Web is largely a visual medium, and users with vision impairments should be kept in mind. Moreover, it is a legal requirement to do so in the United States. The Americans with Disabilities Act (ADA), enacted in 1992, establishes requirements for businesses of all sizes to offer equal opportunities to their workers.
A screen reader, or text-to-voice speech synthesis program, reads the text in an HTML document, but needs information about any images it encounters. It is easy to provide an image label by including an ALT attribute in each image tag. The ALT attribute specifies alternate text that can be displayed or read in place of the image. A screen reader can read the value in the ALT attribute when it encounters an image. Including an ALT attribute is good practice in any case, since users may set their browsers not to display images because of the longer download times required for images. You may also have seen alternate text appear in a yellow box when the mouse is positioned over an image. Sample HTML is shown below.
FOR EXAMPLE
<IMG SRC= "inst.gif" ALT= "Instructor Information" HEIGHT=50 WIDTH=50>
A common error is to neglect to include an ALT attribute for images used as buttons and menu item images. Every image on a page should have an ALT attribute.
In addition, each page should also be assigned a title, using the <TITLE> tag. A screen reader will often start with the title of a page, so an informative title is extremely helpful.
Approximately 10 percent of people have some form of colorblindness. The majority of people who are colorblind experience red and green hues as shades of gray. The other .01 percent experience a much rarer form of blue and yellow colorblindness. An application that uses red and green to demarcate text from backgrounds could confuse a significant portion of the audience. Experienced designers account for colorblindness when choosing a color palette.
Reviewing the Design
To test the validity of your design, walk through the application the way each type of user would. Imagine having to perform tasks, such as going to the new system for information, and see if the design meets your needs.
Compare the design against the CRUD matrix. “CRUD” stands for Create–Read– Update–Delete. For each table of information in the database, how will these four operations be handled? For operations in which the application is responsible for providing this function, does it do so?
Keep notes about the tasks that the system is designed to handle. These imaginary walk-throughs that you conduct will provide the basis for testing later on in the SDLC. To test an application thoroughly, testers must attempt to use the application the way the users will, and they need scripts with specific tasks to attempt. Your notes are a valuable head start for the testing process.