Michael Gaigg: Über UI/UX Design


Windows 8 UX design guidelines

Posted by Michael Gaigg

The Windows 8 UX design guidelines are out. They are part of the Dev Center for Metro style apps and provide some nice learning resources that include

  • Design Principles - Understand the basic principles of great Metro style app design.
  • UX patterns - Learn how to correctly implement common patterns in Metro style apps like navigation, commanding, and touch interactions.
  • UX guidelines - Discover recommendations and requirements for building Metro style apps with the proper look, feel, and user-interaction model.
  • Downloading design assets - Get started designing apps quickly with a portfolio of reusable wireframes, redlines, fonts, and other useful design resources.
  • Assessing usability of apps - Assess your app's design to ensure the user experience is outstanding, and that users will find it useful, usable, and desirable.

Highlights of Week 32/2010

Posted by Michael Gaigg


Design Guidelines: 404 Error Pages

Posted by Michael Gaigg

404 error

404 error

The 404 or Not Found error message is an HTTP standard response code indicating that the client was able to communicate with the server but either the server could not find what was requested, or it was configured not to fulfill the request and did not reveal the reason why.

Possible Reasons

Possible reasons for 404 error pages can be

  • click on a broken link
  • the page has been deleted
  • mistyped URL

Depending on your internet service provider (ISP) the standard 404 page can vary greatly in terms of visual display and information on the error itself. In order to not loose visitors it's strongly suggested to create a custom 404 page. A good custom 404 page will help people find the information they're looking for, as well as providing other helpful content and encouraging them to explore your site further.

Design Guidelines for 404 Pages

A good 404 error page conveys a right message and leads the visitor to where he intends to go:

  1. Tell visitors clearly that the page they're looking for can't be found.
  2. Use language that is easy to understand, non-technical, friendly and inviting.
  3. Display an error message that explains what could have gone wrong.
  4. Offer means to recover (e.g. list site's naming conventions, spell check functionality, most common problems).
  5. Offer links to other important links of the site (e.g. most popular, homepage, FAQ).
  6. Provide a way for users to report a broken link (easy form, email the webmaster).
  7. Do not display ads.
  8. Avoid redirection of 301 and 302.

Other Considerations

No matter how beautiful and useful your custom 404 page, you probably don't want it to appear in Google search results. In order to prevent 404 pages from being indexed by Google and other search engines, make sure that your webserver returns an actual 404 HTTP status code when a missing page is requested.

Got a nice 404 page?

Send me screenshots of your 404 error pages - I'd love to see them!

Thx to Claude Betancourt who sent me this 404 page (Figure 1) of Dow Jones Indexes telling me that "behind the scenes we capture all CGI and request scope variables, log it and email the admins to correct the error if necessary." Nicely done!

Sample 404 page from Dow Jones Indexes

Figure 1: Sample 404 page from Dow Jones Indexes

Another nice one with a funny little video:

Uh-oh, you hit a 404

Uh-oh, you hit a 404



Design Guidelines: Radio Buttons versus Checkboxes

Posted by Michael Gaigg

Design guidelines for checkboxes

Design guidelines for checkboxes versus Radio buttons

Users hate formulars, it is work to them. Filling out forms on the web is no different, that's why getting web form design right is difficult, even simple forms can be challenging.

A good start is using the correct form element, or in the words of this blog entry to know when to use Radio Buttons versus Checkboxes:

General Design Guidelines

  1. Use standard visual representations
  2. Visually present groups of choices as groups (e.g. use subheads)
  3. Lay out your lists vertically with one choice per line
  4. Use positive and active wording for checkbox labels
  5. If possible, use radio buttons rather than drop-down menus
  6. Always offer a default selection for radio button lists
  7. Make radio button options comprehensive and clearly distinct
  8. Associate each button/box with a label
  9. Define accesskeys for frequently used checkboxes and radio buttons
  10. Use checkboxes and radio buttons only to change settings, not as action buttons

Radio Buttons

Radio Buttons are used when a list of two or more options is mutually exclusive and the user must select exactly one choice.

<legend>Gender</legend><br />
<input id="female" type="radio" name="sex" value="female" checked>
<label for="female">Female</label><br />
<input id="male" type="radio" name="sex" value="male">
<label for="male">Male</label><br />


Checkboxes are used when a list of options exists where the user may select any number of choices – including zero, one or several.

<legend>What is your favorite type of salad dressing?</legend><br />
<input id="French" type="checkbox" name="dressing1" value="checkbox">
<label for="French">French</label><br />
<input id="Italian" type="checkbox" name="dressing2" value="checkbox">
<label for="Italian">Italian</label><br />
<input id="Russian" type="checkbox" name="checkbox3" value="checkbox">
<label for="Russian">Blue cheese</label>

Opt-in Checkbox

A stand-alone checkbox is used for a single option that the user can turn on and off.

<input id="accept" type="checkbox" name="yes" value="checkbox">
<label for="accept">I accept the terms and conditions.</label><br />


Suggested reading:

Understand Web Content Accessibility Guidelines & Section 508

Posted by Michael Gaigg

So you know what Accessibility is and how it improves your ROI and why everybody benefits. Now what exactly is Section 508 and how does it correlate with W3C's Web Content Accessibility Guidelines (WCAG 1.0)? And most important, how can you create an accessible.htm that complies with these standards?

Overview: WCAG & Section 508

Section 508 and Web Content Accessibility Guidelines

The main institutions involved (as shown in the illustration above) are:

  • GSA (U.S. General Services Administration) represented by the IT Accessibility and Workforce (ITAW) who is the governments principal advocate and coordinator for Section 508 implementation. Other agencies and organizations may offer similar information, but ITAW is recognized as the governmentwide policy resource for Section 508.
  • World Wide Web Consortium (W3C) represented by the Web Accessibility Initiative (WAI) who developed the Web Content Accessibility Guidelines 1.0 that was approved in May 1999 and is currently the stable and referenceable version.
  • Users that visit websites. In the illustration I mention Government websites as the institution with the biggest need, that is because the Accessibility Guidelines are mandatory for governmental implementations.

Before I continue to explain how the WCAG relate to the Section 508 Standards it is important to get a grasp of what the respective guidelines propose and which checkpoints are included.

Checkpoints: Section 508 Standards

The purpose of Section 508 Standards is explained by Authority 29 U.S.C. 794d: “The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.”

Section 508 Standards [SECTION508-STANDARDS]
Checkpoint Description 508
Non-text elements A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content). (a)
Multimedia presentation Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. (b)
Color Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup. (c)
Style Sheets Documents shall be organized so they are readable without requiring an associated style sheet. (d)
Server-side image maps Redundant text links shall be provided for each active region of a server-side image map. (e)
Client-side image maps Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape. (f)
Data tables Row and column headers shall be identified for data tables. (g)
Markup & tables Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. (h)
Frames Frames shall be titled with text that facilitates frame identification and navigation. (i)
Flickering Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. (j)
Text-only page A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes. (k)
Scripting languages When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology. (l)
Applets, plug-ins or other applications When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l). (m)
Electronic forms When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. (n)
Navigation links A method shall be provided that permits users to skip repetitive navigation links. (o)
Timed response When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required. (p)

Checkpoints: Web Content Accessibility Guidelines

The guidelines as described by the W3C explain how to make Web content accessible to people with disabilities. “The guidelines are intended for all Web content developers (page authors and site designers) and for developers of authoring tools. The primary goal of these guidelines is to promote accessibility. However, following them will also make Web content more available to all users, whatever user agent they are using (e.g., desktop browser, voice browser, mobile phone, automobile-based personal computer, etc.) or constraints they may be operating under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free environment, etc.). Following these guidelines will also help people find information on the Web more quickly. These guidelines do not discourage content developers from using images, video, etc., but rather explain how to make multimedia content more accessible to a wide audience.”

Web Content Accessibility Guidelines [WCAG10]
# Description
01. Provide equivalent alternatives to auditory and visual content.
02. Don't rely on color alone.
03. Use markup and style sheets and do so properly.
04. Clarify natural language usage.
05. Create tables that transform gracefully.
06. Ensure that pages featuring new technologies transform gracefully.
07. Ensure user control of time-sensitive content changes.
08. Ensure direct accessibility of embedded user interfaces.
09. Design for device-independence.
10. Use interim solutions.
11. Use W3C technologies and guidelines.
12. Provide context and orientation information.
13. Provide clear navigation mechanisms.
14. Ensure that documents are clear and simple.

Considerations when implementing for Section 508 Compliancy

Section 508 has three Levels of priority: Level 1, Level 2 and Level 3. WCAG has also three levels of priority, but they are slightly different and named A, AA, AAA. This is an important distinction especially when testing with automated tools like Bobby because - and be aware of this - Level A compliancy NOT EQUALS Level 1 compliancy. Here is why:
When the ITAW handed Paragraph 1194.22 to the WAI (step 1) and after the WCAG 1.0 were completed and handed back to the ITAW (step 2) the Access Board released a Note to §1194.22:

  1. The Board interprets paragraphs (a) through (k) of this section as consistent with the following priority 1 Checkpoints of the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) (May 5, 1999) published by the Web Accessibility Initiative of the World Wide Web Consortium:
    Section 1194.22 Paragraph WCAG 1.0 Checkpoint
    (a) 1.1
    (b) 1.4
    (c) 2.1
    (d) 6.1
    (e) 1.2
    (f) 9.1
    (g) 5.1
    (h) 5.2
    (i) 12.1
    (j) 7.1
    (k) 11.4
  2. Paragraphs (l), (m), (n), (o), and (p) of this section are different from WCAG 1.0. Web pages that conform to WCAG 1.0, level A (i.e., all priority 1 checkpoints) must also meet paragraphs (l), (m), (n), (o), and (p) of this section to comply with this section.

Item 2 is especially important because it means that a discrepancy between WCAG and Section 508 exists that requires a Section 508 Level 1 conformant site has to meet more than just Level A of the WCAG.

Step 3 and step 4 complete the process to create accessible.htm - it is basically up to you to apply the guidelines and produce accessible code.

Best Practices for Accessiblity

Follow my Best Practices blog entries to get more in-depth knowledge on what exactly you need to do to meet all the Section 508 compliancy checkpoints as outlined by the WCAG. Blog entries available so far:



What is Accessibility?

Posted by Michael Gaigg

The purpose of web pages is to interactively display information. The Hypertext Markup Language was designed to encode meaning rather than appearance. Therefore

Accessibility is the extent of access to information on a webpage through user agents (e.g. browsers, screen readers,…) which translate HTML into hypertext structures (links, headers, tables, forms,…) in order to give the users a surplus value.

“As long as a page is coded for meaning, it is possible for alternative browsers to present that meaning in ways that are optimized for the abilities of individual users and thus facilitate the use of the Web by disabled users. Those disabilities are:

  • Visual Disabilities
  • Auditory Disabilities
  • Motor Disabilities
  • Cognitive Disabilities” [NIELSEN96]

Since Web pages are highly visual and interactive the most affected groups as far as accessibility is concerned are the visual disabled, i.e. blind users or users with other visual disabilities like color blindness and users with motor disabilities using alternative input devices or sometimes even just the keyboard instead of the mouse.

Everybody benefits!

In the same way a sidewalk curb is necessary for wheelchair accessibility it also benefits parents with strollers, children with rollerblades and elderly persons trying to cross the street. The same is true for web pages. Designing for accessiblity will not only benefit users with disabilities but will also increase your:

  • Market Share Benefits
    • SEO (search engine optimization)
    • Repurpose
    • Literacy
    • Bandwidth
  • Technical Efficiency Benefits
    • Maintenance
    • Server Bandwidth

Visual Web Design

Posted by Michael Gaigg

First impressions matter! Luke Wroblewski, an excellent speaker with original insights which I had the pleasure to hear at last year's UI-12 (User Interface 12) in Boston, states in his latest article that users coming to your site from a search engine will do one of three things:

  • Look over the page and determine it is not relevant to their goal
  • Look over the page and determine it might be relevant to their goals then quickly scan the page for the information they need
  • Look over the page, quickly scan the page, find the information they need and then stay awhile.

All this happens within seconds. Therefore it is necessary to translate the first impressions (what am I looking at? functional role present?) into meaningful interactions, i.e. scanability, further (inter)action, which leaves us with the following

Guidelines for Visual Web Design

  1. Set initial expectations by communicating what kind of information it provides.
  2. Provide a way to quickly scan that information in order to locate something of value.
  3. Allow people to immerse themselves in the information they want and explore other relevant information when they choose to.
Suggested reading: