Web Application Interface Standards and

Guidelines
Why standardize?
The purpose for standardization is to make our products easier to use, without enforcing
uniformity.

With standards for our applications, the following advantages are realized:

 Vocabulary, controls, navigation, and information are located in similar places across
applications.
 Developers spend less time on the prototype and design of new applications.
 Developers are able to leverage knowledge and code across applications.
 With a common vocabulary, communication between developers is enhanced.
 Users spend less time learning how to use each new application.
 Users recognize standard elements as they switch between applications.
 Users leverage prior knowledge to navigate each application and have a better focus on
their task.

What is an application?
There are two important differences between informational Web pages and what we consider
Web applications:

 Applications are self-contained units that create data or make changes to data, often
transactionally. Applications are focused on one business area at a time.
 "Jump-outs" to unrelated Web pages in the middle of a process are strongly discouraged
because users might lose and need to re-enter data.

What is addressed by these standards and guidelines?

We recognize that the needs of applications, as identified above, differ from the needs of
informational pages. Thus we feel the need to provide a somewhat different standard for
applications.

 Layout: In creating a standard graphic UW identity for applications, the "UW

Administrative Applications" top header graphic is very similar to the look for
informational pages. It avoids functionality unrelated to the current application, and it
tries to give users an indication that they are in a secure area where they can change data.
  Vocabulary: We propose a standard terminology (vocabulary) for common
functionality.
 Guidelines/Recommendations Finally, we make recommendations on issues beyond
look and wordage, to help inform and guide application design.

We have provided information based on our expertise and hope that this will be a living
document - i.e., that other developers will contribute their own experiences and suggestions.

Contact Us
Modified: October 3, 2005
UWIN® is a registered trademark of the University of Washington

Layout: Recommended Common Application

Elements
Login and Logout Pages
A login page is a public page accessible to anyone. As such, it can have the standard UW look
for informational pages. However, a login page does two additional things:

 It provides a login button linked to the Pubcookie mechanism.

 It states which browser levels are supported by the application (i.e., levels with which the
application has been tested). It is recommended that this statement "bracket" browser levels,
e.g., "works with levels 4-5", as opposed to stating an open-ended "level 4 and above." The
latter will leave you scrambling to test and fix any problems that come up with new browser
releases.

Beyond that, the page can explain what the application does, how to obtain access, how to
provide a link to a demo or training site, etc.

A logout page is accessed when a user clicks a logout button. Functionally, this action destroys
any application-specific authorization and then displays the standard logout page, which is
maintained by the Pubcookie team. From this page, the user will have the option to destroy the
generic Pubcookie authentication they obtained by providing their UW NetId and password.

Page Layout
We're adopting most of the look of the informational WWW pages (see examples below).
Differences include:
Header

 The standard toolbar (Search | Directories | Reference Tools) is replaced by Help | Log Out.
 The application's name/logo may appear symmetrically opposite the "University of Washington"
image, preferably looking distinct (i.e., using a different font and/or colors). Clicking on the
application's name/logo may link back to the login page.

Sub-Header Area

 If appropriate, the application may use breadcrumbs in the sub-header area, as defined for
informational pages. Avoid using arrows or < signs when not displaying breadcrumbs.
 Any non-standard toolbars, tabs, or other navigational aids should leave some blank space so
that they are distinct from one another. Example.

Footer

 Application footers do not need a "last updated date," but should provide the name of the
application's owner and their contact information.

Example:

Application Owner
owner@u.washington.edu
 
Contact: 206-543-5555 (optional)
 

 Symmetrically opposite the seal, an application may display its own logo or any other logos as
appropriate.

Web Application Vocabulary

Term Icon Definition/Usage

LOG IN
   Takes user through authentication process
LOG ON

LOG OUT    Takes user out of restricted (authenticated) space

EXIT / QUIT  Would not be used when leaving an application but
 remaining within a "family" of applications like the HEPPS
or Financial desktops
 Omit entirely if QUIT does not destroy Pubcookie (See UW
NetID Log out)

 (X with a square around it)

 Closes browser window
CLOSE WINDOW
 Takes user out of an application without destroying
authentication

CLEAR
   Clears a form
RESET

links    Jump to another Web page

anchors    Jump to a place within a page, e.g., TOP, BTM, NEXT

EXPAND  Displays detail about currently selected record (e.g., in a

VIEW DETAIL
+ list)

COLLAPSE
-  Hides detail about currently selected record
CONTRACT

PgUp    

PgDn    

Printable Version     Creates a Web page or PDF document suitable for printing

FAQ    

TUTORIAL    

 Requests change of information currently displayed in

CHANGE/EDIT   inquiry mode, i.e., takes one to an update screen

SAVE/UPDATE/SUBMIT    Performs validate and update process

 Errors are handled as in the validate function
  Appears on update page

Send <Email>    Sends email or other type of notification

 Used in multi-page actions

Validate/Check for
   Validates current page against business rules
Errors
 Does not save the update

 Appears on update page

ADD  
 Adds a new record

DELETE    Deletes currently selected record

SAVE AS/COPY/CLONE    Creates a copy of the currently selected record

 Returns to previous page without updating a record

CANCEL    Appears on a page confirming an update or on the update
page itself

 Takes user to any help functionality provided by the

HELP   application, including FAQs, support contact information,
and tutorials

HOME    Displays the main menu

SELECT    Choose items from a list

 Takes user to screen used to specify criteria for retrieving

information (either as records or as reports)
 If more than one, optionally prefaced by name, e.g., UW
SEARCH   SEARCH
 FIND is usually associated with searching for something
within a page

 Displays next page in the logical unit of work

NEXT >
 Implies an implicit store of the current set
  Displays prior page in the logical unit of work
BACK
<  Implies an implicit store of the current set, i.e., existing
PRIOR/PREVIOUS
work will not be lost

FIRST
<<  Displays first page
TOP / BEGIN / START

LAST/END >>  Builds last page

GO    Brings up a particular record number

 Ends user input in a "Wizard" process

FINISH  
 Implies there is no backing out after this step

 Forwards the action to the next party in the approval chain

APPROVE    Creates entries in an audit trail but does not authorize
submission of the data for processing

 Returns the action to the party who forwarded it for

DENY   approval

Web Application Interface Guidelines and

Recommendations
1. Use appropriate server-side technology.
A wide range of server-side technologies are available. Use the ones that meet your needs and
that help you comply with the other guidelines.

2. Client-side technology should be compliant with the W3C Document Object Model.
Complying with the W3C DOM generally means that pages should consist of well-formed code
that validates properly against W3C standards and schemas.

Web technologies are largely based on open standards defined and maintained by W3C.
Adherence to those standards insures that our applications will work with the widest range of
software, including editors, validators, browsers, and assistive technologies.
This approach also provides a good foundation for any additional client-side functionality,
including Javascript, Java applets, or Flash.

Recommendations

 Select and write your HTML to a specific W3C schema. Declare which schema you are using in a
DOCTYPE statement.
 Avoid coding practices deprecated by W3C.
 Separate content and presentation by using logical markup and stylesheets.
 Check your pages with the W3C validators (HTML validator, CSS validator.)

3. Avoid unnecessary restriction of the user's configuration.

Browser technology allows the user to set a default text-size, adjust the width and height of the
browser window, and even read in a custom stylesheet. These configuration choices help meet
personal needs.

Conversely, an individual may not be aware of the current browser settings or how other choices
of settings (such as display screen-area) affect how Web pages appear.

The objective is to design your application so that it works across the widest range of possible
configurations that the user may be using, whether by choice or chance.

"Flex" designs, which adjust to whatever ratio of browser window height and width the user
chooses and that allow the user to choose the browser text-size most appropriate for their needs,
are preferred over fixed designs.

Recommendations

 Design your application so its minimal functional screen size is 600x800 pixels or less when the
browser text-size is set to the medium (or default) setting. It can work in larger areas if available,
but it is desirable that it work in the minimum area of 600x800. Try not to make large monitor
sizes, higher display-screen-area settings or very small browser text-size prerequisites for using
your application.
 Minimize the use of fixed dimensions, such as for tables. Use relative dimensions when possible.
 Use relative font sizes. However, do not specify a font-size of less than 80% to avoid unreadable
text on high-display screen-area settings and small browser text-size settings.

4. Coordinate hardware and software requirements with departmental support staff.

Often, the person using a Web application is not the person who installs and updates the software
on their computer. Departmental support staff often instruct staff to avoid do-it-yourself
modifications of their software. The person may be relying on the UWICK software or they may
be using a Nebula networked computer. For these and other reasons, the audience for an
application may choose not to make the software changes the developer would prefer they make.
Recommendations

 The application design process should include an evaluation of the range of hardware and
software users have.
 Determine through testing the specific browser vendors and versions that reliably support the
application. In particular, test your application on current UWICK and Nebula software.
 Do not assume that because the application works on the current version of a browser it will
work on the next version. Test it.
 For applications with a general audience (such as students, faculty, staff, or alumni)
requirements for specific software or settings should be kept to a minimum.
o Non-authenticated applications should work for the widest possible range of clients that
may access the application.
o Authenticated applications by definition will only be used by browsers capable of secure
connections (version 4 or later).
o Clearly state restrictions, if any, on all entry pages of the application.
 For an application with a specific, limited, stable, and known audience, requirements can be
more restrictive, but only with advance review and approval of support staff and application
users.
o Again, state restrictions on all entry pages of the application.
o Think strategically. Even if it provides useful functionality, an overly restrictive approach
can be a trap. As the application succeeds and its use grows, it may be necessary to
rebuild it for the larger, more diverse audience.
o Applications should work on both Macintosh and Windows computers. Requiring users
to replace their computers to use your application can be a major imposition.
o Be aware that labs financed by PIs on campus frequently save money by using open
source software, usually Linux (UNIX). To keep applications accessible by this
constituency, avoid using Windows-specific formats. For example, instead of Excel use
the more generic CSV format.

5. Pay attention to accessibility issues.

It is UW policy to provide reasonable access for the handicapped in all of its services.

Attention to accessibility insures that an otherwise capable person is not prevented from doing
his or her work by an inadvertant design choice by the application developer.

Web technologies have many features built in to enable accessibilty. Simply using these
technologies as they are designed to be used will go a long way toward making your application
accessible.

All federal Web sites must now comply with Section 508 of the Rehabilitation Act. While
Section 508 does not apply directly to the UW, it does set a standard that UW applications are
likely to be compared to. If you are developing an application that will be shared with public
funded higher education or the federal government, it will probably have to comply with Section
508 before it will be acceptable to such organizations.
See Making UW Web Sites Accessible To Everyone for in-depth information about accessible
Web design.

6. Look, feel, and functionality should be consistent within an application.

Consistency allows users to improve their skills as they use the application, applying lessons
they learned in one area elsewhere in the application.

Recommendations

 Use standard C&C application terminology and graphics.

 If you develop additional conventions, document them in a style guide for your application.
 Before inventing a new convention, check with other application developers to see if an
appropriate one already exists.

7. Coordinate design so users can move from one application to another without changing
configurations.

Users of UW applications often want to move quickly between one application and another.
Unnecessary variation in designs and inconsistency in terminology and graphics is a burden on
the user.

Recommendations

 Application developers should keep in touch as they make design decisions. Regular meetings,
email lists, and good project documentation help to share design concepts and identify
problems.

8. Help users understand their role in security and privacy aspects of the application.
The UW has major legal responsibilities to insure the security of our systems and the privacy of
the information they contain.

Help users understand the role they play in security, such as how to properly and completely
terminate a secure session.

Users are very sensitive to how information they enter into a Web application will be handled.
Reasonable assurances that their privacy will be protected are helpful, but do not promise more
than we can give.

Recommendations

 At each point-of-entry into an authenticating application, include instructions on how to

properly terminate the secure session.
 Develop a privacy statement appropriate to your application, following Writing a Privacy
Statement guidelines.
o Be careful not to promise more than the UW can deliver. Because we are a public
institution, much information is available to the public on request. Even when protected
by specific laws (such as patient information), the information can still often be obtained
by legal procedures such as discovery motions and subpoenas.
 On any page where the user enters information, provide a link to the privacy statement. If a
page is part of a linked set of pages for entering information, the link only needs to be on the
first page in the set, but it should be on all pages that are entry points into the set.
 The link to the privacy statement should be near where the person begins entering information
(not out of sight at the bottom of the page). The link can be in a small font-size.