Ethiopian Design

Client-side scripting languages, such as JavaScript and Jscript, can be programmed to provide user interface elements that are not possible in traditional HTML. In general, client side scripting makes dynamic behavior possible without accessing the web server.

For instance, events such as mouse-overs (when the cursor is moved over an object) can be detected and used to create useful feedback for users. Mouse-over events can be used to trigger a visual cue to the user by changing a graphic to indicate that an object is clickable.

This effect is called a rollover. Rollovers can also be used to provide contextual help by presenting messages that explain what will happen if the user clicks on the object.
Another good use for scripts is validating user-supplied data in forms prior to sending the data to the server.

This allows common user errors to be detected and responded to without the latency associated with a server request. Scripts can be used to program other sophisticated behaviors such as interactive forms that update calculations when information is changed.

Despite these positive aspects, scripting also tends to be overused, complicating the interface and slowing user interaction with bloated script code and gratuitous graphics. Rollovers, for example, when used to hid the full description of a link whose title is insufficiently descriptive, force the user to engage in minesweeping (moving the mouse to discover hidden information) in order to do a task.

To implement successful client-side scripts, code defensively. Be thorough and cautiously rule out possible errors in order to produce robust code. Put all script subroutines in the head portion of the HTML page.

This prevents the user from calling routines that have not been defined. Wrap these routines in comment tags so that older browsers will ignore them. Specify which script and version you’re using if you are using routines that are not backward-compatible with older browsers. Know which routines are not cross-platform-compatible and find other solutions.

In addition, follow good software engineering practices. Scripting languages are very similar to general-purpose programming languages and can be just as difficult to debug. Factor the scripts into small, cohesive subroutines that perform one function only. Such routines are easier to write, test, and debug.

For complex scripts, consider creating flowcharts or structure charts to prevent logic errors. Declare all variables and document their purposes and types. Document each subroutine similarly. Keep page-specific variables and constants at the top of the code so you don’t have to wade through all the code to customize it for every page.

In any large project, it just isn’t possible to hand-code each page individually. For any large web site project, it’s necessary to begin by creating, testing, and debugging templates.

Even after mockup pages or other prototypes have been user tested, it’s still necessary to build solid templates to make sure they can actually work for the data they will contain or the function they will serve.

To start, identify how many different types of templates will be necessary, even if it is just as a sanity check for early design phases. For instance, mockups may have been created for a home page and subpages, but what about product pages?

If any set of pages will contain a vastly different type or set of data, a new template should be created and tested. Also test the boundary conditions with regard to page content.

That is, if you test how a template works for the pages with the most and least content, you can be reasonably sure will work for everything in between. Finally, make sure to get approval for any new templates that the client did not review during the mockup stage.

Html Coding Guidelines
These are some general principles to follow in the process of coding HTML.

Code for Speed
Test download times for the slowest reasonable connection that users will have. For the general public, assume no faster than a 28.8-baud modem connection. (For users connecting through a cellular phone, 14.4 baud is often the maximum achievable rate.)

Is the response time still reasonable at that speed? Maximum download time can be estimated by summing the file sizes for all components of your pages. Anything more than about 100K per page may create unreasonable delays for users with slower internet connections.

Code for Rendering
Reduce the number and complexity of any tables that are used, so that pages will display faster, large, nested tables are more difficult to parse and take longer for browsers to render.

Generally, the fewer the tables, the faster that users will able to use screen data. In addition, ensure that all size attributes are used for image and applet tags. Otherwise, browsers may adjust the rendered layout on the fly, making changes as new information is downloaded.

This creates an unstable and potentially confusing user experience, as screen elements jump around while the page is progressively updated.

Code for Accuracy
Use HTML syntax checkers to test the validity of your HTML code. Improperly formed syntax will display unpredictably in different browsers and with different user preferences selected. Also check for common mistakes that sample syntax checkers may not find, such as table data that is outside of <TD> tags.

Code for Maintenance
Document page code liberally with comments so that sections are easily found later. It is especially important to mark header, footer, navigation, and content sections. To the extent possible, also separate content and HTML tags onto different lines.

While this sometimes cannot be done because it will change the layout, it is easier to select an entire line or block of lines if the entire block is content. This minimizes the need to select text from within a line of HTML tags, reducing the possibility of introducing syntax errors while updating content.

Code for Search Engines
Add necessary metatags and text so users can find you pages. Search engines work on the basis of relevance: they find pages with keywords and descriptions similar to the terms you’re searching for.

Those pages with the most words or word meanings matching a query will be returned fist. It is therefore important to include keyword and description metatags with every page. They should include some general terms that describe your entire web site and some that refer to the specific page.

It is also prudent to include any common misspellings or variations in your keywords, as users don’t always know or take the time to figure out the correct spelling for what they want.

It is not, however, ethical or legal to include competitor’s trademarked or service-marked terms in your keywords. Some search engines also index the content of your pages (especially the first 200 characters of the page), so include as many relevant keywords in the text as is reasonably possible (without detracting from the message, of course).

Keep in Mind Evolving HTML Standards
In addition to following current HTML standards as closely as possible, pay attention to new standards, so that your code is likely to be compatible with future browser releases for as long as possible, and so porting the code to new versions will be a minimal strain. See the sidebar “Why XML Is Good for Usability” for details on one of the most important standards that is likely to influence future web development.

To improve project management of web site projects, it is useful to separate the technical components that go into a web site’s development. The categorizations made in this section are not necessarily distinct, but are made based on the roles you might assign to various programmers, the skills required, and the usability issues that might come up.

Web site development can be decomposed into two broad development efforts: client side and server side. Client-side development consists of three general areas: HTML page construction, client-side scripting, and client-side programming. HTML page construction refers to formatting the content and layout of individual pages with HTML, as well as integrating other technologies into HTML pages, such as Java or Flash applets.

Client-side scripting includes JavaScript or Visual Basic scripting that is sometimes included as part of a web page and interacts with the visual components on the page itself. Client-side programming includes Java or Flash programs that run primarily on the user’s browser platform.

Server-side development can also be categorized into at least three possible components: CGI programming, database and enterprise integration, and database development. CGI (common gateway interface) programming refers to general-purpose server-side programming, such as form parsing, date calculations, and other numeric processing that is difficult or impossible to do on the client side.

CGI programs are typically developed using PERL, C++, or a scripting language. Serving the same purpose as CGI programming (but technically different from it) is Java Servlet programming. Database integration is how database technologies are tied to the dynamic web pages. Although CGI programming is often used to access databases, the issues involved with database integration are specific to accessing databases.

Database integration is sufficiently different from other forms of web development that it deserves separate consideration. It includes Java Server Pages (JSPs), PHP, and Active Server Pages (ASPs). Database development includes the design of databases that feed dynamic web pages or that service transactions. Server-side development encompasses CGI and other server-side technologies such as PERL, C++, or Java programs.

With a plethora of web site development tools available, how do you choose ones that will support usability in the development process? Because of the rapidly changing landscape of development systems, no single tool will meet every organization’s needs. We can, however, list some of the more useful features to consider when evaluating tools for your own development needs.

Just as it’s critical to understand the users when developing a web site, it is perhaps even more critical to understand your own developers when choosing a development environment. Simply using freely available tools is not always the most cost effective path. When evaluating tools, consider at least four broad areas for the usability of the tools: project management, site and asset management, coding support, and technology support.

Project Management
What support does the tool provide for project management functions? In particular, support for the following areas would be helpful:

• Collaboration and version control – support for development teams working on a single code base, which limits version confusion and prevents mistakenly overwriting more recent code.
• Design notes – the ability to add notes or tasks to individual pages regarding status or tasks.
• Project management facilities – support for maintaining project task status, assigning tasks to team members, and producing status reports.

Site and Asset Management
How usable is the functionality for building the architecture of the site and managing the digital assets?
• Site maps – can the site be designed visually in either a tree structure or in outline form?
• Site importing and exporting – can existing sites be imported or exported?
• Asset views – can all assets of a particular type be organized in a coherent manner?
• Template creation – can page templates be created easily?
• File transfer – can modified pages be automatically transferred to staging and production servers?
Coding Support
How well does the tool support the coding of individual web pages? The following features are particularly useful:
• Text coloring – use color to automatically differentiate between HTML, scripts, and content.
• Syntax checking check code syntax for valid constructs.
• Link checking check links for invalid or dead links.
• Accessibility checking make sure that ALT tags and other code elements are used to ensure equal accessibility to the content.
• Code indenting help the developer organize the code in a readable form.
• WYSIWYG and code views – switch easily between code and page layout views.
• Script editing and debugging – provide tools for editing and debugging the scripting language of choice.
• Table creation – provide graphic tools for laying out tables and form views for specifying exact parameters.
• Form creation – provide drag-and-drop or other tools for rapidly creating HTML forms.
• No code mangling – automated tools should never change code you’ve written by hand.

Technology Support
Every organization and development team has certain technologies in which it specializes. How well does the tool support the use of those technologies?

• Dependence on nonstandard server technologies – does the development environment depend on server technologies that will limit how you deploy the site?
• Style sheets – is there support for creating, maintaining, and using style sheets?
• XML – does the environment support XML?
• Database integration – how easily can you create database driven sites?
• Plug-in support – does the environment support third-party plug-ins for technologies it does not directly support?
• Project-specific technologies – can you easily develop sites using technologies with which your development team is proficient?

New development environments and new versions of existing tools are continually becoming available. For productivity and, ultimately, for the usability of the web sites you are developing, your team should have usable development tools that fit the way they work and that support your organization’s development processes.

Once the necessary pages and the system functions that will support them are specified (but not necessarily built), data and control flow can also be designed and specified.

There are several visual representations, which build on the 3-tiered architecture approach, that can assist developers in ensuring complete functional coverage and facilitate communications among the design team and in communicating designs to customers.

The visual aids that will be discussed here are the static design, the dynamic trace, and system latency diagrams (See White et al, 1998 for other system design techniques.)
Static design diagrams illustrate the logical organization of web applications.

They are meant to convey an overview of the system that is especially useful for client communications. Shows a simplified static view for a business-to-business e-commerce site. In the Presentation tier, the high-level user tasks are represented by thumbnail screens consisting of “login,” “get account information,” and “purchase products.”

The web server is represented in the middle tier, and database and transaction services are shown in the Services tier. Firewalls separate the tiers. This logical view may or may not represent the actual number of machines needed.

For example, database and transaction serves could coexist on the same machine (although not recommended), and the web server could be distributed to multiple machines for better performance. Likewise, more user screens are required than are shown in this type of view.

A dynamic request trace specifies the data flow for accomplishing specific user tasks and the order in which the information exchanges occur. This view goes a layer deeper than static design diagrams, showing the sequence of events that the system will perform as the users perform their tasks.

Shows a simplified dynamic trace for a purchase task. Here, the user presses the Order button after selecting the items for purchase. The request goes from the user to the web server, then to the transaction server for payment processing, then to shipping for order fulfillment, back to the web server with confirmation data, which formats the confirmation into HTML and sends a confirmation page back to the user.

System latency diagrams are useful for showing how much each system function contributes to overall task time. This is especially useful for optimizing system performance and reducing the effects of bottlenecks. Shows a latency diagram for the purchasing task just described.

Here, we see that the major contributors to response time are the transaction and database services. Increasing web server performance at this point would be ineffectual for reducing system response time.

Instead, the focus should be on the subsystems providing the transaction and database services. Software, platform, and network issues are all potential culprits, as are any back-end services that go outside the enterprise, such as bank or credit card transaction.

Version Control
Version control is another technique for making the programmer’s job easier. It provides a means for maintaining stable versions of your web site or system during and after the production process.

Version control provides a layer of abstraction for programmers that allows them to focus on the changes or enhancements to the system without worrying so much about file-level questions like, Is this the current version of the file?

It is also used to ensure that one developer doesn’t overwrite another’s changes and allows programmers to work on one copy of the code while other programmers can still use the previous stable version of the code. Code files are then “checked in” after all necessary changes have been made. Of course, this is especially important when more than one person is coding.

Several commercial and open-source version control systems exist (e.g., CVS and Voodoo), each with its own capabilities. Most version control systems provide a means for tracking changes to documents or files, including who is making the change, what they did, why they did it, and when it was done. Some version control systems lock files so that only one person at a time can make modifications.

For simple projects, version control can be accomplished without support software by maintaining a central repository of code and making clear who works on which files. In such cases, it is especially important to make periodic backups of the code when it reaches a stable, working state.

This allows developers to dial back to a previous working version if something dramatically wrong happens during development.

Asset Management
Asset management is the systematic practice of tracking various system resources, such as images, content files, Java applets, and HTML files. Some form of asset management is necessary for almost any size project. Asset management exists in some integrated development environments, but it can also be done with just a spreadsheet.

A practical technique for tracking production is to create a spreadsheet with one line for each web page and one column for each element that needs to be tracked. For example, columns might exist for HTML, text, graphics, navigation, JavaScript, and so on. The status of each element can be tracked in the individual cells. Creating a database for tracking bugs is also a useful technique both during and after production.

A systematic divide-and-conquer approach can be applied to the software development portion of the web site production process by dividing the problem into discrete parts and addressing their respective development issues separately.

One paradigm for doing this is to decompose the system architecture into three tiers, or layers. This approach, referred to as a 3-tiered (or, more generally, n-tiered) architecture (see White et al. 1998æ Sadtler et al. 2000), divides the architecture into the following tiers:

Tier 1. Presentation Tier: Includes the user interface, typically a web browser
Tier 2. Business Logic Tier: Includes the web server and any server-side programs that run under it, such as CGIs or Java Servlets
Tier 3. Services Tier: Includes legacy systems, databases, and other back-end services.

The Presentation tier refers to the user platform. Typically this is a web browser running on a personal computer, but it can also refer to a Java applet running in a browser, a Java application running by itself, or any other client software capable of accessing the web server.

The Business Logic tier includes the web server, CGIs, and other web server technologies that run within the web server (such as server-side includes), or in support of it (such as server plug-ins). For many web projects, only Presentation and Business Logic layers are used.

For more complex sites, such as those serving dynamic content or web applications a third tier, the Services tier, is also used. The Services tier includes databases and other legacy systems that provide information and back end services (such as transactions) for the web server.

There are many advantages to using a 3-tiered architecture, including easier development and maintenance and improved scalability and security. By separating the services, business logic, and presentation, system components can be more focused and cohesive, and less coupled, or dependent, on how other system components are implemented. In addition, by logically (and physically) separating the tiers, components of any tier can be upgraded or maintained relatively independently of the other tiers.

Finally, 3-tiered architectures are often used to map out security measures for the system. Typically, this is done by placing firewalls between each of the tiers. In a standard deployment, the firewall between the Presentation and Business Logic tiers is called the protocol firewall, and it limits which services can be provided by the Business Logic tier the Presentation tier.

For example, the protocol firewall may allow HTTP requests through to the web server, but not Telnet requests that would allow outside users to control the web server. Between the Business Logic tier and the Services tier, a domain firewall is placed that only allows services to be provided to machines within a trusted domain, that is, those in the Business Logic tier.

This type of security structure provides a multilayered defense against potential security threats from outside the system. The main goal for many companies is to protect the legacy systems inside the Services tier, as that tier may contain the most sensitive and mission-critical data.

The Business Logic tier serves as a buffer zone, often called the demilitarized zone (DMZ), which protects the security of the legacy systems in the event that any single machine is compromised.

Of course, good security contributes to system usability because an exploited system may not be able to provide the information or services to the users when they need it. Perhaps more important, users expect that companies collecting personal information over the Web (e.g., credit card numbers) will safeguard that information. A system that is not secure will not be trusted and will not be used.

Software requirements should be driven by usability requirements and task analysis. Establishing requirements and specifications has a long history in software engineering and is a basic component of most standard engineering methods, such as the Waterfall (Royce 1970) and Spiral methods (Boehm 1988).

What those methods do not include are clear linkages from usability requirements. They typically specify what will be built and how it will function, but not why it is needed or how it will be used. Consequently, many systems are built that function according to specification, but are useless.

From task analysis, we’ve established the pages needed for each task and the system functions required for each page. This is a blueprint for the overall system requirements. That is, we can say, “This is the behavior required by the system.” The next step is to take each system function and completely specify its design.

This includes a detailed description of what it does, a description for how it will be implemented, a range of acceptable inputs and outputs, and a list of things that can go wrong and what will be done in each event.

This allows the interfaces between system functions and components to be verified to ensure that the outputs from one component are those expected as input to the next component.

For example, when a user enters an account and password to log in, client-side validation can be written in Javascript to make sure the account name contains only valid letters and numbers before passing the data to the server for back-end processing.

However, we cannot rely completely on validation done on the client side. For a more robust system, the back-end software at the server should also specify what will happen if bad data does come in from the browser (perhaps as part of a communications failure or a security breach), and what to do if a password or user name is incorrect. This level of specification is driven by, but not replaced by, usability requirements.

When building small web sales, coding and production details can usually be kept in the head of a single developer. Any development effort larger than a handful of pages, however, will benefit from some basic software engineering techniques.

This section focuses on simple, practical techniques that you can easily apply to web projects. For a more rigorous, comprehensive treatment of software engineering theory and techniques, see one of the standard software engineering texts, such as Pressman’s Software Engineering (1997).

A classic treatment of organizational and practical software development issues can be found in Fred Brooks’s Mythical Man-Month (1975),
Following proper software engineering techniques (or modifying them for web development) can have a substantial impact on overall system usability primarily because it enables developers to achieve higher quality.

This allows developers to systematically meet usability goals on time and within budget. It also allows for better client communications and improves usability for the system’s development team.

Software engineering processes are similar in spirit to the overall web development process, and they follow similar principles of iterative design and pervasive evaluation.

However, software development has its own, unique contributions to usability (see the sidebar “Why Software Engineers Are Critical for Usability”), and they are reflected in the following engineering techniques.

Whether you are integrating conceptual ideas into your pages (e.g., color or typographical principles) or specific elements (e.g., icons, buttons, forms), the development and integration should follow the pervasive usability procedure.

This requires understanding the utility of specific elements in relation to user tasks and needs, a method for developing quick and easy drafts of the ideas, a means for testing the true utility of specific elements, and a refinement and review process for the chosen elements. Following this approach will lead to a design that serves to effectively communicate the information and ideas intended.

The software development phase of the web site development cycle is the last chance to prevent usability problems prior to final testing. It is also a time when unforeseen issues can arise, often where they are not expected. Many potential pitfalls are technology specific and may change over time.

We focus on production issues that are likely to continue to cause problems irrespective of the current version of HTML standards.

Usability problems
Many of the usability problems that are created during the software development process related to the extra time it takes users to accomplish their tasks. Download time and system performance time continue to be among the top user complaints. Other issues are caused by server-side problems inconsistent development practices within a site, changes to a site over time (beyond the Version 1.0 release), and poor use of other non-HTML technologies.

There is not necessarily a one-to-one relationship between usability problems and solutions. In some cases, a single technique will address multiple problems. In other cases, multiple techniques are needed to address a single issue. This section discusses such problems. The next section discusses solutions.

Poor Response Time
Speed, speed, speed! Users can’t get enough of it. It seems that as soon as hardware and communication technologies speed up enough for acceptable performance, software developers create products that are bigger and slower. A rule of thumb from the early days of client-server systems was that system response times longer than a tenth of a second were noticeable to users and could adversely affect usability.

Even fast web pages today take several seconds to display and sometimes much longer. Overuse and misuse of graphics is a primary contributor to slow download time, as are poorly coded pages. Until technology allows us to achieve display speeds closer to a tenth of a second, users will continue to complain about speed.

Response time, however, is not just download time. It is a combination of data transfer time, server processing time, and browser-side display time. Often the real time-delay culprit isn’t just the transfer of page contents, but the processing time on the server side. Serving a static web page is a relatively simple task for a web server, but for more complex, dynamic pages, the web server may have to perform database queries, process credit card transactions, or request other services from legacy systems. Each server task contributes to the overall time.

Overloaded servers, slow database integration systems, and inefficiently coded server transactions all contribute to slow response time.

A third contributor to poor response time is the time it takes the web browser software to display a web page’s screen image. Overly complex or nested HTML, table code can add considerably to display time.

Unused size attributes for image tags can make progressively downloaded data unusable because the browser constantly shifts screen objects as new objects are loaded. This often makes it practically impossible for users to read any text that may have been displayed earlier.

Web Page Code Inconsistency
Another problem that can surface in production is that different pages written by different coders can be implemented in completely different ways. These differences can change the appearance slightly or dramatically, and can also affect how the page appears while downloading. For example, the decision to code using a single table, multiple tables, or no tables can have a noticeable effect on the final page and how it is presented to the user.

In addition, the use of different coding styles, over time, can become a nightmare for maintenance. The web site will change. That is a given. How much the changes will cost, however, is completely up to you.

For example, what if your client wanted to make a global change to the size of the buttons on the navigation bar? What would normally be a simple change completed in a matter of seconds from a consistent code base (e.g., one built from templates) could take hours for code written inconsistently by multiple people. Usability is also important for programmer productivity.

Platform Incompatibilities
Many usability problems stem from the ways different browsers, or even the same company’s browser implemented on a different computing platform, can interpret the same HTML or JavaScript code differently.

For example, JavaScript code that makes use of time and date functions requires separate functions for older versions of Netscape and Internet Explorer because the JavaScript routines were implemented with incompatible outputs. In addition, proprietary and nonstandard extensions of HTML and JavaScript are sometimes incompatible with various browsers and platforms.

Poor Use of Technology
Companies are always trying to find some technological edge to set themselves apart from the competition. The Web has provided such companies an endless supply of bleeding-edge technology with which to wreak usability havoc on hapless users. Early on we saw a proliferation of huge, beautiful graphics that served no other purpose than eye candy.

Then came animated GIFs, movies, Java applications, Flash, and so on. While each of these is very useful for some purposes, they are often used more for their name than for any useful purpose. For example, many companies are creating splashy Flash presentations in place of their home page because that’s the hot technology of the moment.

This type of design often requires users to download and install the latest plug-ins and requires that the user wait for an extra data file to download, sometimes without any way to bypass it (other than pressing the Back button).

Related to poorly used technology is proper technology that is poorly implemented. In addition to being compatible across platforms, an implementation must be sufficiently robust to handle common user behaviors and errors.

For example, what happens if the user clicks on a link before the web page is finished loading? If JavaScript or other hidden code has not be loaded, any calls to nonloaded JavaScript functions will fail, leaving the web browser and the user hanging.

Poor Product Documentation
Documentation is another often overlooked part of web site production. Whether the project will be maintained in-house or by the client, documentation is very important for using, maintaining and extending a web site. How will the system be used? How will it be updated and maintained?

A site that does not explain how users can most efficiently use it is a usability problem for the users. A site that is delivered without adequate documentation on how it can be best managed, maintained, and updated is a usability problem for the client.

Poor documentation of your own web site will, of course, become a usability problem for you and will likely cost much more in lost productivity than the cost of creating proper documentation.

Not everyone will want to experience your Flash site, regardless of how great and cool it is. Always provide an alternate and easy way for users to get to your content. If users don’t have the plug-in, make sure they see something meaningful.

Make Sure Users Have Control
Give users buttons to skip introductions, animations, and so forth (e.g., “Skip Intro . . .”). The navigation must be available and accessible to the user. It is not fun to search for navigation, particularly when you are searching for information. Embed a link within the HTML of the page that allows users to skip through animations.

Ensure that this always visible to the users. Allow users to turn sound on and off and to control volume levels. Give users access to the Macromedia Flash contextual menu (this enables zooming, sound control, rewinding, and adjusting quality to fit local processing power). Provide navigation that allows users to tab through the choices for accessibility.

Give Users Feedback on the State of the File
Be sure to include a status bar to indicate how far along the movie is in its loading process. Keep the user informed of processes. Provide feedback about status (e.g., loading, clicks received, etc.) and total file size. When you tackle highly interactive interfaces that don’t follow a web paradigm, read up on traditional user interface design for applications. Most of the problems have been solved before and are very applicable to Flash development.

Put Movies on Separate Pages
Link to portions of different movies using URLs. This allows users to bookmark specific sections of the site.

User-Test Your Flash Sites
Be sure to perform proper user testing of your web site. Perhaps you’ll decide those straight HTML pages are better after all!