Web Application Interface Standards & Guidelines

Why standardize?
The purpose for standardization is to make our products easier to use, without
enforcing uniformity.
With standards for our applications:
Vocabulary, controls, navigation and information are located in similar
places across applications
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 the task they're trying to perform.
What is an application?
Two important differences between informational web pages and what we
consider web applications are:
Applications are self-contained units that create data or make changes to
data, often transactionally.
"Jump-outs" to unrelated web pages in the middle of a process are
discouraged so users don't lose and have to re-enter data.
What is addressed by the Web Application Interface Standards and
Guidelines?
We recognize that applications, as identified above, have needs that differ from
the needs of informational pages. Thus, we feel the need to provide a somewhat
different standard for applications. The new "UW Administrative Applications" look
is very similar to the new look for informational pages, but avoids functionality
unrelated to the current application, and tries to give users an indication that
they are in a secure area where they can change data.
In addition to creating a standard graphic UW identity for applications, we
propose a standard terminology (vocabulary) for common functionality. Finally,
we make recommendations on issues beyond look and verbeage, to help inform
and guide application design.
Table of Contents:
Layout
Vocabulary
Guidelines/Recommendations
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.
Application and Individual Page 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. In addition, a Login page:
Provides a login button linked to the pubcookie mechanism.
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, 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 NDC/pubcookie team. From this
page, the user will also have the option to also 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 | Logout
The application's name/logo may appear symmetrically opposite the
"University of Washington" image, preferably looking distinct (i.e. uses a
different font and/or colors). Clicking on the application's name/logo may
link back to the login page.
Sample Code to Use
Generic page 1 view code
Sample Application 2 view code
Sample Application 3 view code
Sub-Header Area
If appropriate, the application may use breadcrumbs in the sub-header
area, as defined for informational pages.
However, applications should avoid using the breadcrumb look for non-
breadcrumb type links (e.g. their own toolbar) to avoid confusing users. A
toolbar may adopt the look of the standard toolbar in the same space.
Any non-standard toolbars, tabs, or other navigational aids should leave
some blank space to distinguish themselves.
Footer
Application footers do not need a "last updated date", but should provide
the name of the application's owner and their contact information.
Symmetrically opposite the seal, an application may display its own logo
or any other logos as appropriate.
Example:
Web Application Vocabulary
Term Icon Definition and Usage
LOG IN
LOG ON

Takes user through authentication
process
LOG OUT
EXIT / QUIT

Takes one out of restricted
(authenticated) space.
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 nothing
(see Student systems)
CLOSE WINDOW X
(X with a square around it)
Closes browser window.
Takes one out of an application
without destroying authentication.

CLEAR
RESET

Clears a form
links
Jump to another web page
anchors
Jump to a place within a page, e.g.
TOP, BTM, NEXT
EXPAND
VIEW DETAIL
+
Displays detail about currently
selected record (e.g. in a list)
COLLAPSE
CONTRACT
-
Hides detail about currently selected
record
PgUp
PgDn
Printable Version
Creates a web page or PDF document
suitable for printing
FAQ
TUTORIAL
HELP

CHANGE
Requests change of information
currently displayed in inquiry mode,
i.e. takes one to an update screen.
SAVE/UPDATE/SUBMIT
SEND

Performs edit and update process.
Errors are handled as in the EDIT
function.
Appears on update page.
Send <Email>
Sends email or other type of
notification
EDIT
Used in multi-page actions.
Edits current page against business
rules.
Does not save the update.
ADD
Appears on update page.
Adds as new record.
DELETE
Deletes currently selected record
COPY
Creates a copy of the currently
selected record.
Displays the copy in an update
screen that must have an ADD but
not a DELETE.
Clears any unique ID fields and drops
the cursor into the first one.
CANCEL
Deletes the transaction just
processed.
Appears on a page confirming an
update or on the update page itself.
SUSPEND Places an image of the update
transaction into an individual's
personal holding area.
Appears on update page.
RESUME
Returns one to the last update
transaction suspended in this
session.
Appears on inquiry page.
RETURN
Builds last suspended action. (How is
this different from RESUME?)

HELP
Takes one to any help functionality
provided by the application. This
includes FAQs, Support Contact
Information and Tutorials.
MAIN MENU
Builds standard base menu that the
user would normally see after
authentication
MENU
Takes one to the next higher screen
in the hierarchy that brought one to
the current menu.
Appears on a menu screen.
SEARCH
FIND/SELECT

Takes one 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
FIND is usually associated with
searching for something within a
page
SEARCH RESULT
LIST

Takes one to screen that was the
result of a selection process, if more
than one item was selected.
NEXT >
Builds next page in the logical unit of
work.
Implies an implicit store of the
current set.
ALSO: used in multi-step processes
("Wizards")
BACK
PRIOR/PREVIOUS
<
Builds prior page in the logical unit of
work.
Implies an implicit store of the
current set, i.e. existing work wil not
be lost.
FIRST
TOP / BEGIN /
START/BACK<<
<<
Builds first page
LAST
BTM / END
>>
Builds last page
GOTO
Brings up a particular record number
FINISH
Ends user input in a "Wizard" process
Implies there is no backing out after
this step
APPROVE
Forwards the action to the next party
in the approval chain.
Creates entries in an audit trail but
does not authorize submission of the
data for processing.
DISAPPROVE
Returns the action to the party who
forwarded it for approval.
Creates entries in an audit trail but
does not authorize submission of the
data for processing.
FINAL APPROVAL
Approval equivalent of SUBMIT
Performs edit and update process.
CHANGE ROLE
Builds the last accessed domain level
through which the user was directed
to the current action.
NOTIFY
Performs edit, update and processing
of information.
Appears on page designed to
broadcast information (calendars,
rule changes, etc.)


Web Application Interface Guidelines & Recommendations
1. Use appropriate server-side technology.
A wide range of server-side technologies (Perl, PHP, CGI, Zope, etc.) 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
a. Select and write your HTML to a specific W3C schema, such as HTML 4.01
transitional or XHTML 1.0 transitional. Declare which schema you are using
in a DOCTYPE statement.
b. Avoid coding practices deprecated by W3C.
c. Separate content and presentation by using logical markup and
stylesheets.
d. Check your pages with the W3C validators (HTML validator, CSS validator)
e. When doing client-side processing such as Javascript validate-on-entry
scripts, use methods that will work with the widest range of possible
clients.
3. Avoid unnecessary restriction of the user's configuration.
Browser technology allows the user to set their default text-size, adjust the width
and height of the browser window, and even read in their own stylesheet. The
configuration choices they make help meet their personal needs.
Conversely, an individual may not be aware of the settings in his browser or how
other settings they choose (such as display screen-area) will affect how Web
pages will 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 that 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
a. 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.
b. Minimize the use of fixed dimensions, such as for tables. Use relative
dimensions when possible.
c. 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
a. The application design process should include an evaluation of the range of
hardware and software application users will have.
b. Determine through testing the specify browser vendors and versions that
support the application reliably. In particular, test your application on
current UWICK and Nebula software.
c. Do not assume that just because the application works on the current
version of a browser that it will work on the next version - test it.
d. For applications with a general audience, such as large groups like
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.
e. For an application with a specific, limited, stable, and known audience,
requirements can be more restrictive (such as requiring MSIE 5 or 6) but
only with advance review and approval of support staff and application
users.
o Clearly 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.
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 their 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 the Making UW Web Sites Accessible To Everyone site for in-depth
information about accessible Web design.
Recommendations
a. Follow as much as possible the federal Web-based Intranet and Internet
Information and Applications (1194.22) standards.
o Always provide ALT attributes for IMGs and other non-text
elements.
o Provide context and orientation information in forms and tables.
o Minimize use of frames, as they are difficult (but not impossible) to
navigate with adaptive technologies. If you do use frames, properly
title each frame element.
o Additional detailed tutorials with plenty of examples are available
on the WebAIM site.
b. Separate content and presentation by using logical markup and
stylesheets. This approach greatly simplifies your HTML, allows
handicapped users to apply their own stylesheet, and lets you provide
alternative stylesheets for various browsers or client technologies (such as
PDAs).
c. Design your application so it is possible to use it entirely from the
keyboard using the tab key and other standard keyboard shortcuts. If a
mouse is required to successfully use your application, it will be
inaccessible to some people.
d. Consider ergonomic aspects of color use.
o Insure good contrast between text and background. Text should be
on areas of uniform color. Avoid text over graphics or other
patterned backgrounds.
o Avoid blue as a color for lengthy blocks of text. The center of the
eye (fovea) lacks blue receptors so tracking across multiple lines of
blue text is more difficult than if the text is most other colors.
o Avoid using color exclusively to communicate meaning. For
example, about 10% of men and a fraction of a percent of women
are red/green color blind - the two colors look the same. It would
be unwise to use red to indicate danger and green to indicate safe
unless the meaning is clear in other ways.
e. Test your pages with standard accessibility checkers such as Wave and
Bobby.
6. Look, feel and functionality should be consistent within an application.
Consistency allows the user to improve their skills as they use the application,
applying lessons they learned in one area elsewhere in the application.
Recommendations
a. Use standard C&C application terminology and graphics.
b. If you develop additional conventions, document them in a style guide for
your application.
c. 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
a. 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
a. At each point-of-entry into an authenticating application, include
instructions on how to properly terminate the secure session.
b. Develop a privacy statement appropriate to your application, following the
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.
c. 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.
d. 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.