Web Application Interface Standards

8/13/2019 Web Application Interface Standards

1/10

Web Application Interface Standards & Guidelines

Why standardize?

The purpose for standardization is to make our products easier to use, withoutenforcing uniformity.

With standards for our applications:

• Vocabulary, controls, navigation and information are located in similarplaces 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 weconsider web applications are:

• Applications are self-contained units that create data or make changes todata, often transactionally.

• "Jump-outs" to unrelated web pages in the middle of a process arediscouraged so users don't lose and have to re-enter data.

What is addressed by the Web Application Interface Standards andGuidelines?

We recognize that applications, as identified above, have needs that differ fromthe needs of informational pages. Thus, we feel the need to provide a somewhatdifferent standard for applications. The new "UW Administrative Applications" lookis very similar to the new look for informational pages, but avoids functionality

unrelated to the current application, and tries to give users an indication thatthey are in a secure area where they can change data.

In addition to creating a standard graphic UW identity for applications, wepropose a standard terminology (vocabulary) for common functionality. Finally,we make recommendations on issues beyond look and verbeage, to help informand guide application design.

Table of Contents:

• Layout • Vocabulary • Guidelines/Recommendations

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

Application and Individual Page Layout

Recommended Common Application Elements

http://www.washington.edu/webguides/apps-guidelines/layout.htmlhttp://www.washington.edu/webguides/apps-guidelines/layout.htmlhttp://www.washington.edu/webguides/apps-guidelines/vocab.htmlhttp://www.washington.edu/webguides/apps-guidelines/vocab.htmlhttp://www.washington.edu/webguides/apps-guidelines/guidelines.htmlhttp://www.washington.edu/webguides/apps-guidelines/guidelines.htmlhttp://www.washington.edu/webguides/apps-guidelines/guidelines.htmlhttp://www.washington.edu/webguides/apps-guidelines/vocab.htmlhttp://www.washington.edu/webguides/apps-guidelines/layout.html


2/10

Login and Logout Pages

A Login page is a public page accessible to anyone. As such, it can have thestandard 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 thisstatement "bracket" browser levels, e.g. "works with levels 4-5", asopposed 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 newbrowser releases.

• Beyond that, the page can explain what the application does, how toobtain 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 thestandard logout page which is maintained by the NDC/pubcookie team. From thispage, the user will also have the option to also destroy the generic pubcookieauthentication they obtained by providing their UW Netid and password.

Page Layout

We're adopting most of the look of the informational www pages (see examplesbelow). Differences include:

Header

• The standard toolbar (Search | Directories | Reference Tools) is replacedby 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 maylink 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-headerarea, 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 leavesome blank space to distinguish themselves.

http://www.washington.edu/computing/pubcookie/http://www.washington.edu/computing/pubcookie/http://www.washington.edu/computing/pubcookie/http://www.washington.edu/computing/pubcookie/http://www.washington.edu/webguides/apps-guidelines/applicplain.htmlhttp://www.washington.edu/webguides/apps-guidelines/applicplain.htmlhttp://www.washington.edu/webguides/apps-guidelines/applic1.htmlhttp://www.washington.edu/webguides/apps-guidelines/applic1.htmlhttp://www.washington.edu/webguides/apps-guidelines/application.htmlhttp://www.washington.edu/webguides/apps-guidelines/application.htmlhttp://www.washington.edu/webguides/apps-guidelines/applic2.htmlhttp://www.washington.edu/webguides/apps-guidelines/applic2.htmlhttp://www.washington.edu/webguides/apps-guidelines/applicastra.htmlhttp://www.washington.edu/webguides/apps-guidelines/applicastra.htmlhttp://www.washington.edu/webguides/apps-guidelines/applic3.htmlhttp://www.washington.edu/webguides/apps-guidelines/applic3.htmlhttp://www.washington.edu/webguides/apps-guidelines/applic3.htmlhttp://www.washington.edu/webguides/apps-guidelines/applicastra.htmlhttp://www.washington.edu/webguides/apps-guidelines/applic2.htmlhttp://www.washington.edu/webguides/apps-guidelines/application.htmlhttp://www.washington.edu/webguides/apps-guidelines/applic1.htmlhttp://www.washington.edu/webguides/apps-guidelines/applicplain.htmlhttp://www.washington.edu/computing/pubcookie/http://www.washington.edu/computing/pubcookie/


3/10

Footer

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

• Symmetrically opposite the seal, an application may display its own logoor any other logos as appropriate.

Example:

Web Application Vocabulary

Term Icon Definition and Usage

LOG INLOG ON

• Takes user through authenticationprocess

LOG OUTEXIT / QUIT

• Takes one out of restricted(authenticated) space.

• Would not be used when leaving anapplication but remaining within a"family" of applications like theHEPPS 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 applicationwithout 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

EXPANDVIEW DETAIL

+

• Displays detail about currentlyselected record (e.g. in a list)

COLLAPSE

CONTRACT -

• Hides detail about currently selectedrecord

PgUp

PgDn


4/10

Printable Version

• Creates a web page or PDF documentsuitable for printing

FAQ

TUTORIAL

HELP

CHANGE

• Requests change of informationcurrently displayed in inquiry mode,i.e. takes one to an update screen.

SAVE/UPDATE/SUBMITSEND

• Performs edit and update process.• Errors are handled as in the EDIT

function.• Appears on update page.

Send

• Sends email or other type ofnotification

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 currentlyselected record.

• Displays the copy in an updatescreen that must have an ADD butnot a DELETE.

• Clears any unique ID fields and dropsthe cursor into the first one.

CANCEL

• Deletes the transaction justprocessed.

• Appears on a page confirming anupdate or on the update page itself.

SUSPEND • Places an image of the update


5/10

transaction into an individual'spersonal holding area.

• Appears on update page.

RESUME

• Returns one to the last updatetransaction suspended in thissession.

• Appears on inquiry page.

RETURN

• Builds last suspended action. (How isthis different from RESUME?)

HELP

• Takes one to any help functionalityprovided by the application. Thisincludes FAQs, Support ContactInformation and Tutorials.

MAIN MENU

• Builds standard base menu that theuser would normally see afterauthentication

MENU

• Takes one to the next higher screenin the hierarchy that brought one to

the current menu.• Appears on a menu screen.

SEARCH

FIND/SELECT

• Takes one to screen used to specifycriteria for retrieving information(either as records or as reports)

• If more than one, optionally prefacedby name, e.g. UW SEARCH

• FIND is usually associated withsearching for something within apage

SEARCH RESULTLIST

• Takes one to screen that was theresult of a selection process, if morethan one item was selected.

NEXT >

• Builds next page in the logical unit ofwork.

• Implies an implicit store of thecurrent set.

• ALSO: used in multi-step processes("Wizards")


6/10

BACK

PRIOR/PREVIOUS


7/10

1. Use appropriate server-side technology.

A wide range of server-side technologies (Perl, PHP, CGI, Zope, etc.) areavailable. Use the ones that meet your needs and that help you comply with theother guidelines.

2. Client-side technology should be compliant with the W3C DocumentObject 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 byW3C. Adherence to those standards insures that our applications will work withthe widest range of software, including editors, validators, browsers, and assistivetechnologies.

This approach also provides a good foundation for any additional client-sidefunctionality, including Javascript, Java applets, or Flash.

Recommendations

a. Select and write your HTML to a specific W3C schema, such as HTML 4.01transitional or XHTML 1.0 transitional. Declare which schema you are usingin 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-entryscripts, 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 widthand height of the browser window, and even read in their own stylesheet. Theconfiguration choices they make help meet their personal needs.

Conversely, an individual may not be aware of the settings in his browser or howother 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 widestrange of possible configurations that the user may be using, whether by choice orchance.

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

Recommendations

a. Design your application so its minimal functional screen size is 600x800pixels or less when the browser text-size is set to the medium or default

http://www.w3.org/DOM/faqhttp://www.w3.org/DOM/faqhttp://www.w3.org/DOM/faqhttp://www.w3.org/DOM/faqhttp://validator.w3.org/http://validator.w3.org/http://jigsaw.w3.org/css-validator/http://jigsaw.w3.org/css-validator/http://jigsaw.w3.org/css-validator/http://jigsaw.w3.org/css-validator/http://validator.w3.org/http://www.w3.org/DOM/faqhttp://www.w3.org/DOM/faq


8/10

setting. It can work in larger areas if available, but it is desirable that itwork in the minimum area of 600x800. Try not to make large monitor

sizes, higher display-screen-area settings or very small browser text-sizeprerequisites for using your application.

b. Minimize the use of fixed dimensions, such as for tables. Use relativedimensions when possible.

c. Use relative font sizes. However, do not specify a font-size of less than80% to avoid unreadable text on high display screen-area settings andsmall browser text-size settings.

4. Coordinate hardware and software requirements with departmentalsupport 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 instructstaff to avoid do-it-yourself modifications of their software. The person may berelying on the UWICK software or they may be using a Nebula networkedcomputer. 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 ofhardware and software application users will have.

b. Determine through testing the specify browser vendors and versions thatsupport 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 likestudents, faculty, staff, or alumni, requirements for specific software orsettings should be kept to a minimum.

o Non-authenticated applications should work for the widest possiblerange of clients that may access the application.

o Authenticated applications by definition will only be used bybrowsers capable of secure connections (version 4 or later).

o Clearly state restrictions, if any, on all entry pages of theapplication.

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 applicationusers.

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 andits use grows, it may be necessary to rebuild it for the larger, morediverse audience.

o Applications should work on both Macintosh and Windowscomputers. Requiring users to replace their computers to use yourapplication 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.

http://www.washington.edu/computing/software/uwick/http://www.washington.edu/computing/software/uwick/http://www.washington.edu/computing/software/uwick/http://www.washington.edu/nebula/http://www.washington.edu/nebula/http://www.washington.edu/nebula/http://www.washington.edu/nebula/http://www.washington.edu/computing/software/uwick/


9/10

Attention to accessibility insures that an otherwise capable person is notprevented from doing their work by an inadvertant design choice by theapplication 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 waytoward 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 applicationthat will be shared with public funded higher education or the federalgovernment, it will probably have to comply with Section 508 before it will beacceptable to such organizations.

See the Making UW Web Sites Accessible To Everyone site for in-depthinformation about accessible Web design.

Recommendations

a. Follow as much as possible the federal Web-based Intranet and InternetInformation and Applications (1194.22) standards.

o Always provide ALT attributes for IMGs and other non-textelements.

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, properlytitle each frame element.

o Additional detailed tutorials with plenty of examples are availableon the WebAIM site.

b. Separate content and presentation by using logical markup andstylesheets. This approach greatly simplifies your HTML, allowshandicapped users to apply their own stylesheet, and lets you providealternative stylesheets for various browsers or client technologies (such asPDAs).

c. Design your application so it is possible to use it entirely from thekeyboard using the tab key and other standard keyboard shortcuts. If amouse is required to successfully use your application, it will beinaccessible 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 ofblue text is more difficult than if the text is most other colors.

o Avoid using color exclusively to communicate meaning. Forexample, about 10% of men and a fraction of a percent of womenare red/green color blind - the two colors look the same. It wouldbe unwise to use red to indicate danger and green to indicate safeunless the meaning is clear in other ways.

e. Test your pages with standard accessibility checkers such as Wave andBobby.

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

http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20000920/http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20000920/http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20000920/http://www.section508.gov/http://www.section508.gov/http://www.section508.gov/http://www.washington.edu/computing/accessible/http://www.washington.edu/computing/accessible/http://www.washington.edu/computing/accessible/http://www.access-board.gov/sec508/guide/1194.22.htmhttp://www.access-board.gov/sec508/guide/1194.22.htmhttp://www.access-board.gov/sec508/guide/1194.22.htmhttp://www.access-board.gov/sec508/guide/1194.22.htmhttp://www.webaim.org/tutorials/althttp://www.webaim.org/tutorials/althttp://www.webaim.org/tutorials/althttp://www.webaim.org/tutorials/contexthttp://www.webaim.org/tutorials/contexthttp://www.webaim.org/tutorials/contexthttp://www-3.ibm.com/able/webcourse/u4l2.htmhttp://www-3.ibm.com/able/webcourse/u4l2.htmhttp://www.webaim.org/tutorials/http://www.webaim.org/tutorials/http://www.webaim.org/tutorials/http://www.btexact.com/ces/colours/colours.pdfhttp://www.btexact.com/ces/colours/colours.pdfhttp://www.btexact.com/ces/colours/colours.pdfhttp://www.temple.edu/inst_disabilities/piat/wave/http://www.temple.edu/inst_disabilities/piat/wave/http://www.temple.edu/inst_disabilities/piat/wave/http://www.cast.org/bobby/http://www.cast.org/bobby/http://www.cast.org/bobby/http://www.temple.edu/inst_disabilities/piat/wave/http://www.btexact.com/ces/colours/colours.pdfhttp://www.webaim.org/tutorials/http://www-3.ibm.com/able/webcourse/u4l2.htmhttp://www.webaim.org/tutorials/contexthttp://www.webaim.org/tutorials/althttp://www.access-board.gov/sec508/guide/1194.22.htmhttp://www.access-board.gov/sec508/guide/1194.22.htmhttp://www.washington.edu/computing/accessible/http://www.section508.gov/http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20000920/


10/10

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 anotherwithout changing configurations.

Users of UW applications often want to move quickly between one application and

another. Unnecessary variation in designs and inconsistency in terminology andgraphics is a burden on the user.

Recommendations

a. Application developers should keep in touch as they make designdecisions. Regular meetings, email lists, and good project documentationhelp to share design concepts and identify problems.

8. Help users understand their role in security and privacy aspects of theapplication.

The UW has major legal responsibilities to insure the security of our systems andthe privacy of the information they contain.

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

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

Recommendations

a. At each point-of-entry into an authenticating application, includeinstructions on how to properly terminate the secure session.

b. Develop a privacy statement appropriate to your application, following theWriting a Privacy Statement guidelines.

o Be careful not to promise more than the UW can deliver. Becausewe are a public institution, much information is available to thepublic on request. Even when protected by specific laws (such aspatient 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 enteringinformation, the link only needs to be on the first page in the set, but itshould be on all pages that are entry points into the set.

d. The link to the privacy statement should be near where the person beginsentering information (not out of sight at the bottom of the page). The linkcan be in a small font-size.
http://www.washington.edu/webguides/guidelines/forms/privacy.htmlhttp://www.washington.edu/webguides/guidelines/forms/privacy.htmlhttp://www.washington.edu/webguides/guidelines/forms/privacy.html

Documents

Web Application Interface Standards