Unit 4.2. How to Design a Web Application

Who is the User?

The first and most important step in design is to identify the user of the application. If an application is built for a group of people, but no one can use it, then it is not a good application, no matter how flawlessly it works or how brilliantly it was coded. Remember, too, that the user is often paying for the application, which is another good reason to make the user your first consideration.

There might be several types of users. If this is the case, identify each distinct group of users and check that the design meets each group’s needs. Suppose that the accounting department and the auditing department of a large corporation both need the application that you are building for them. Determine what each department will need from the application. Make sure there are not other groups of users whose needs are not being addressed. Then create a design that you think both departments can use. Finally, be sure to verify the design with each group.

Nothing will focus an application’s design like identifying the user, and making sure the application meets the user’s needs. If you cannot identify the user, you are in trouble.

Storyboard

The next step in design is to create a “storyboard.” The idea of a storyboard has been borrowed from film and television, where a storyboard is used to map out successive scenes to help chart an entire film or show. It is a useful tool for communicating what something will look like before it exists. Once a storyboard is approved, the production schedule can be set up, and the film or show can be made. In the Web application world, storyboards depict each successive application screen in detail. They serve as a blueprint for an application. They are more effective in most cases than a verbal description; programmers and users and designers can look at the same sample screen and understand it, even if the programmer is wondering how to build it, and the user is wondering if the screen will help in day-to-day work. In any design meeting, it will not be long before words fail and someone seeks out a whiteboard or piece of paper and starts drawing screens. These early scribbles can take on the status of hallowed historical documents once the application is built.

A good test of a storyboard is to show it to someone else, even someone unfamiliar with the application. If that person has trouble following the screens, ask yourself why and reexamine your choices. Designers like to use the word “intuitive” when describing a good design. This means it is fairly easy for someone who is new to the design to understand it.

Create a storyboard either by hand or through a software tool. Many kinds of software—flowchart software, presentation software, and graphics software—let users draw boxes, text, buttons, or drop-down menus on a page. This is all that is needed to give an idea of the page layout. Note that these tools do not generate HTML. That type of tool is discussed in the next section, “Build a Prototype.”

Build a Prototype

A prototype is a model of the application. Prototypes are built to give users an even clearer idea of how an application will work. The prototype is built for display on a computer screen, so that a user can see what the application looks like.

For a Web application, prototypes should be built in HTML and JavaScript. Developers can reuse the HTML and JavaScript code when building the application.

What is the difference between building a prototype and building an application? A prototype is not fully functional. Buttons do not have to work; a prototype may be presented to the user with an explanation such as, “When the user clicks on this button here, they will see the following screen,” as the designer manually opens the next HTML page in the sequence. A prototype is not connected with a database. Instead, “dummy data” is shown on each screen, to give users an idea of what a screen will look like when it is filled in with data. The HTML Web pages that you create in Chapter 5, “Introduction to HTML: Basic Tags, Tables, and Frames,” and Chapter 6, “Advanced HTML: Forms, Nested Tables, and Nested Frames,” are examples of prototype Web pages. Later in this book, you take these HTML pages and make them fully functional using PL/SQL and the Oracle 9iAS.

Again, the question must be raised: Why spend time on building a prototype? Why not build a fully functional application instead of a prototype? The question should really be phrased: Why build a fully-functional application and then have to change it numerous times at great expense, when it is much easier to build prototypes and change them until a design can be settled upon? It is a fact that users often change their minds once they see a prototype. A user might say, “I realize that is exactly what I asked for. But now that I see it, I need to change it.”

Tools for Building a Prototype

Building prototypes is simplified by the many tools available on the market, classified as HTML editors or Web development tools, such as Dreamweaver™ or HomeSite™. These types of tools offer a graphical interface to help write HTML code. Often they will utilize color-coding for different types of tags, which helps avoid typos and HTML coding errors. They can also let the user switch between the HTML view of a page, and the page as rendered in a browser, making it easy to track your progress. Tasks like creating a table can be accomplished via menu items and buttons and clicks, instead of writing out the HTML opening and closing tags for tables. Web designers refer to “painting” a button or a drop-down menu on a screen, and “painting” a screen. A Web designer has learned to work with at least one of these tools, and can build an HTML prototype for the programmer to use.

It is also a good idea for programmers to learn one of these HTML tools. Not every programmer on every project is handed an HTML prototype as a starting point for developing code. If a programmer is given a picture of a screen to build, instead of HTML code, the programmer has to start coding from scratch. The programmer can put the HTML elements of a page together more quickly if they can use a Web design tool, instead of writing the HTML code “by hand.” Another time to use a Web design tool is when a legacy application is being moved to the Web. The screen design is clear from the old application, but it must be recreated in HTML code. Again, knowing a Web design tool gives the programmer an edge. The programmer can use the tool to concentrate on creating the look and feel that the users want. After all, these tools are created for just that purpose. Once the programmer has an HTML prototype, the programmer can switch gears and start making that page functional using programming expertise.

Design Document

A storyboard or prototype needs to be accompanied by a design document. Story-boards and prototypes provide the visuals. The design document provides text that explains the visuals in more detail. For a screen that lets users update information about a student, this document lists each field on the screen and explains where the data is stored in the database.

The design document also describes the actions that can be taken on the screen, and the possible results. Buttons on the screen should be listed one by one in the design document, with a full description of what will happen when the user clicks them. The design document provides the additional detail needed by the programmer.