User Interface Considerations

One of the first things users notice about your web application is its look. Before they have started to use the application for its intended purpose, they are already subconsciously forming opinions about it and reacting to it. Are the graphics and pictures well-placed and appealing? Does the application look well-organized (even if it is not), or is it cluttered and chaotic? Are the colors and fonts pleasing to the eye, or do they grate visually?

Unfortunately, since it can be one of the least complicated parts of web applications to write code for, user interfaces are often taken for granted. They are frequently neglected for the more "complicated" portions of our projects, like gory database layouts and storage.

Web applications are not like your standard program for a graphical operating environment, such as Microsoft Windows, Mac OS X, or KDE and Gnome for Unix. In these environments, the look and feel of applications is more constrained by the set of controls and appearance of the windowing systems' widgets. Many basic applications for these systems have a common base appearance, and most controls and widgets have similar if not identical behavior.

Web applications based around HTML and associated technologies have the advantage of being extremely flexible in the user interface they can present. The possibilities for creative and pleasant user experiences are limitless. However, the possibilities for creating atrociously confusing and unusable UIs are equally limitless.

Understanding Your User Interface

It might be useful to first discuss what we mean by user interface. We are basically defining the user interface of an application (or web application) as the part of the system with which the user interacts. This includes any content served to the user, such as HTML pages, image files, and content from the database. For better or worse, this also includes the web browser. Even though the software is not under your control, you need to worry about how the user using the "Back" and "Forward" buttons in the browser will affect the execution of your program.

We next need to look at what sort of application we are writing and tailor our UI for that. If we are writing a content-centric web application, such as a searchable online encyclopedia or a wiki (a content-serving system supported by a community of users who can easily modify and update the content), we will change how we present the application to the user. The content being served to the user will take up a majority of the real estate provided to us by the host browser. We should encourage the use of the "Forward" and "Back" buttons in the browser for navigation and make use of colored hyperlinks to inform the user whether he has visited a link (see Figure 14-1).

Figure 14-1. A content-centric site, www.wikipedia.org.

More dynamic web applications, such as an online store, an online stock trading application, or a university's class registration program, are going to have a greater number of forms, so our presentation will be different. For these, we will want to provide clearly visible links or buttons with which the user can move around the application and be drawn away from the "Forward" and "Back" buttons. Also, we will not want to have hyperlinks change color after the user visits a link since that link is less likely to be pure content and more likely to be part of the application. Screen real estate devoted to helping the user understand what he is doing will also likely be higher.

While we will provide more tips along these lines later, the immediate goal is to impress upon readers the importance of thinking about this part of the application as soon as planning of other components begins.

Planning a User Interface

One of our primary goals when designing a user interface is to help users work their way through our application so they can find what they want and navigate with relative ease. Sites that confuse users and leave them unable to find what they want annoy them and make them not want to bother (which is of particular concern if the site is an online merchant).

Know Your User

One of the first things you should worry about when designing your user interface is who your users are. Spend some time thinking about what kind of users they might be and what some of their properties are.

• Are they likely to be younger or older people?

• What language are they likely to want to use? Will English suffice, or should the web application make an effort to be localizable?

• How tech savvy are they likely to be? If you casually mention to make sure that their proxy server is not filtering SSL connections, are they going to have any idea what you are talking about?

• Are they likely to have disabilities, such as blindness or reduced typing ability?

• Are you prepared to handle the non-trivial percentage of your users who have some degree of color-blindness?

• Is this strictly an internal corporate web application used by staff whom you can train?

• Are they at your web site because they want to be (they are shopping for vacation packages in Europe) or not (paying an electrical bill)? Web sites of the latter category should make an extra effort to be friendly and help the user through something they would rather not be doing.

Arming yourself with the knowledge of who your users are and why they are using your web application will be a key foundation for planning your user interface.

Invest in Proper Design and Layout

When surfing the web, you will occasionally come across a web site with an awful look and feel. The colors are atrocious, the page is filled with annoying animated graphics, or the layout is simply innavigable.

Developers who are competent programmers and computer users capable of both writing HTML and firing up a simple drawing program (such as Microsoft Paint) still find themselves struggling to come up with a professional and fluid-looking user interface. Sometimes, a developer or manager will "know somebody who knows HTML" and ask that person to design the UI for the application, resulting in a phenomenon scornfully referred to as "cousin art."

In general, if you are trying to develop a professional web application for use by large numbers of people, you should consider bringing in two peoplea user interface designer and a professional graphics designer. A user interface designer is someone who is familiar with the pros and cons of various interface designs and is likely to know what users respond well to and what bothers them.

Similarly, we would like the professional graphics designer to be involved in the process of designing the user interface for our web application based on the input of the user interface designer. At the very least, we would like this person to provide us with some prototypes. The designer does not have to be a top-notch expert in the field, but somebody strongly familiar with the process will provide more help than not.

If the project is so small that there is no budget for graphics design and nobody is available with the appropriate skills, then your strategy should be to keep the user interface simple and straightforward. Just because it does not have flashy graphics, blended colors, and rotating three-dimensional objects does not mean it is lousy.

Indeed, if you look at many of the major web sites related to what you will be providing, you will find the ones that you prefer to work with are simple and concise.

Plan Page Sequences in Advance

If you were to look at the process groups use for putting together large applications, you would find that they frequently write large documents called "specifications," where they lay out how the application will look, how it will work, and with which dialog boxes the user will interact at certain times. These specifications are often based on use cases preconceived ideas and plans for how users will navigate through the web application. Similarly, we should be planning our web applications well in advance and make sure that we know what the user will be doing in each part of the site before we sit down to write any code.

One of the key parts of these application specifications is to plan out page sequences for certain macro "actions" users can execute on your web site. For example, if we were the authors of an online blogging engine and we wanted to plan pages for creating a new user account, we might choose to create a sequence of pages as shown in Figure 14-2. This technique is often called storyboarding.

Figure 14-2. Planning the sequence of pages for adding a new user to our application.

Also, we should always make a point of preparing for errors, including how we want to display errors for the user. A simple page with the text

 Warning: mysqli::mysqli() [function.mysqli]: Access denied   for user 'mbuser'@'localhost' (using password: YES) in   /home/httpd/www/phpwasrc/chapter10/connect.php on line 37 

is likely to be viewed unfavorably by users and considered an unacceptable design by the people paying for the development of the application. In addition to these system errors, we should be able to warn the user about something in which he has inputit is unlikely that he was born in 1582. At any point, we should be prepared to jump to an error page that can help the user understand what has happened and send him back to where he can rectify the problem.

Test the Interface

Once you have planned your interface, you will certainly want to test it. If you have not yet had much time to write any of the code for the application, consider writing a quick prototype or having the graphics designers do a mockup with static HTML pages. Although everything will not be in its final form, you can at least start testing it out and seeing what people think. The people using it should be as similar to your target audience as possible (not your development team).

Large online merchants will perform elaborate usability testing seminars, where they have specific tasks they would like users to complete. They will observe the users as they attempt to do so and will often have the user comment while he works through the process. Using the information learned from these sessions, they can decide whether to tweak their design to correct any problems.

Other options include focus groups, where you get a group of potential clients or customers together and talk with them. It becomes a perfect opportunity to ask them what they would like to see in your application, what problems they commonly have with similar applications, or whether they have any suggestions about how to make their experience better.

Tragically, not everybody has pockets deep enough to fund such studies, especially if we are writing a small internal application to help our human resources department track new job applicants. However, we would be wise to ask a couple of people from the department to spend some time going over the design and trying any prototypes. Nothing will prove more frustrating than spending months (if not years) and large sums of money putting together a complicated system that nobody knows how to use.

Helping Users in Trouble

Although we should always strive to make our web applications as unambiguous as possible, there will be times when users find themselves confused or unable to resolve a question they have while using the program. The complexity of these questions can range from "Where do I go to delete my account?" to "Oh no! I accidentally ordered 320 plasma TVs! Help me fix it!" As application authors, we have a number of options for providing the users with help:

• Frequently Asked Question (FAQ) lists are extremely useful, especially for sites that are more content-oriented, where users might have trouble finding information. These should be easily found in a "Support" or "Help" link on which the user can click. They should be written by people who normally help the users with problems (as opposed to marketing people).

• Reasonably large web applications might find it worth their while to invest in a knowledge database system, where previous customer problems are entered along with their resolutions. Make sure these can be searched by current users.

• For things like forms, immediate context-sensitive help can be useful. If there is a field called "Account Number," and there is potential confusion (it might be the user's credit card number, normal account number, or retirement account number), we might want to provide some help in the form of a small popup window. Note that this is one of the few times users will not mind a popup window (and most browsers will not block these) if it proves helpful (see Figure 14-3). However, they will not be amused if the help merely says something like "Please enter your account number here."

  Figure 14-3. A useful, context-sensitive help popup window.

  

  
  

• There should be a way for users to get in touch with somebody, perhaps through e-mailing a web form, or even an integrated chat program. There are many options, and many groups will have different plans for the exact amount of support they will provide. In the end, there should be some way for users to get the help they need.

Design Tips and Strategies

What follows is a list of common tips and suggestions for improving the user experience for the clients or customers of your web applications. It is not exhaustive, but covers some points that seem particularly relevant and interesting to keep in mind when designing your applications:

• Keep it simple When you are providing instructions or directions to the user, keep it as concise as you can. Use a single sentence if possible. Users will consistently clue out any text if it is presented in paragraphs or sequences of long text.

• Respect the user's bandwidth Even if a majority of your users use broadband connections to the Internet or are clients in another department on the same internal network, including lots of high-resolution images on a page is only likely to slow things down.

• Keep visited links the same color in forms-centric applications We mentioned this before briefly: In content-centric applications, it makes sense to use the default HTML behavior of marking visited links with a different color. In a forms-centric web application where the data input by the user changes frequently (such as a banking application), this makes less sense. We can use styles (see the "Cascading Style Sheets (CSS)" section) to implement this.

• Match page titles to your content While it makes perfect sense for content-centric sites to title each page to accurately reflect its content, we might instead choose to just have all pages use the title "New Account Creation" for a user registration process. This helps deter the user from attempting to bookmark a page that does not make sense and jumping back to it later on.

• Provide ample navigation options in the page If your web application would be confused by repeated use of the "Forward" and "Back" buttons, you would be better off providing clear and obvious navigation buttons within your pages. For example, after the user either completes an order or is in the process of viewing his shopping cart, a "Return To Shopping" button reduces his temptation to use browser buttons and hopefully reduces some of the hassles you might face in dealing with this.

• Put labels next to icons Web sites that have large pictures on their front page and no text labels below them are considered "cool" by some but are often regarded as frustrating by people who find themselves unable to figure out what the graphics mean. By placing a label near the graphics, we can remove any ambiguity and confusion.

• Avoid the use of frames This is a very controversial statement to make and is argued about heavily in discussion groups, but we will discourage the use of frames. Apart from serious security holes found with them in recent years (affecting all browsers), they can also be extremely confusing to users who will be uncertain where their content is coming from (in the case of cross-site frames) and will bookmark pages, only to find themselves going back to somewhere else they did not expect. While there are valid uses for frames, they are few and far between.

If you ever have doubts about something you are including in your user interface, it is a good idea to ask people what they think about it, perhaps by visiting a few sites whose interface you find particularly good or trying it on a few people before deciding what to do with it.