Some IBM products have begun providing mega menus for global navigation, quick access to secondary views, and even direct access to individual artifacts. Feedback has been positive and we have recently drafted design guidance, as part of our IBM One UI initiative, for standardizing mega menu interactions.

The IBM One UI mega menu guidance is based on a combination of our experiences from multiple IBM products, UX-articles outlining best practices, our internal UXR data, and a review of industry practices.

The following is a sample mega menu design. There are no current plans for this design to appear in any IBM product.

Industry practices and user research data

During the course of defining the IBM One UI guidance for mega menus, we reviewed a number of UX articles documenting proposed best design practices for mega menus (along with the rationale behind those practices). As an example, see that Jakob Nielsen gave mega menus a big thumbs up after observing them to be a very usable & useful form of navigation.

Within IBM, we have also tested our own mega menu prototypes, with our UXR Team reporting that usability test participants like mega menus and make solid use of the shortcuts that the menus provide.

Our mega menu practices are also partially guided by an industry review of 35 web apps and sites that provide mega menu navigation. This review has helped us understand the dominant behaviors in the industry as we recognize that user expectations are shaped largely by their everyday software experiences.

A sample of a product experience

IBM Lotus Connections 3.0 began implementing mega menus in part to fix a design problem such that the top-level navigation, when exposed as a series of individual navigation links, didn't fit properly at 1024 px. The mega menus allowed us to provide navigation to all the primary views by collapsing some of them into an Apps menu. This also allowed us to save users clicks (and page refreshes) by providing direct access to secondary views, and in some cases direct access to specific artifacts (e.g., recent communities). By all accounts, this has been a very positive change.

Ethan Perry, our Connections Design Lead reports that he has received positive feedback from several customers, during design discussions, on both the mega menus implemented in v3.0 and on prototypes of more advanced mega menus (which include additional controls such as search mechanisms with autocomplete as well as primary actions that would otherwise only be available by first navigating to another view).

That’s it

We like mega menus. We especially like our mega menus. We hope you do, too.

Need
a better view of Uncle Harry’s hairy nose?Just hover over his thumbnail and you’re all set! Want more info about that
remote-controlled beer pager without leaving your current page?Hover, friend. Hover.

It
has become common practice for many sites and web apps to display certain types
of “pop-up” UI elements on hover (mouse-over).For example, banner menus, contextual help, and preview cards (e.g.,
person cards, movie cards, etc.) all commonly display when users hover over a link,
icon, thumbnail image or other UI element.

The good and the bad…

When
using a mouse (or other device that controls cursor movement &
interaction), this behavior can be really useful – allowing a single UI element
(e.g., a link) to provide two different capabilities for hover and click.For example, it’s common that hovering over a
person’s name link will display a person card; whereas clicking the name navigates
to the person’s profile.

The
biggest criticism to allowing hover to invoke pop-up UIs has been the complaint
that these pop-ups can appear without user intent – for example, when the user drags
their mouse across a screen and inadvertently passes a hover help icon, a link,
or a banner menu.This complaint is
especially strong (and valid) when the pop-up interferes with a user task or displays
something that the user considers of no value (e.g., an advertisement).

Enter the sustained hover!

Sustained
hover is just what it sounds like...we don’t display the pop-up on simple
pass-by, but require that the pointer rest over the underlying UI element for a
sustained period.This allows users to
request the pop-up and usually prevents inadvertent display.

So, what’s the right delay?

We
believe that delay times should range from 300-700 ms, depending on a number of
factors including the likelihood that the user’s cursor will inadvertently come
to rest on a particular UI element (largely determined by placement and density
of pop-up UI hover targets) and user expectations driven from common industry
practice.

For
example, 300 ms appears to be the appropriate delay for invoking a banner
menu.We have user data indicating that
immediate display annoys users who intend to simply drag the cursor past the
menu.However we’ve also found that if
we set the delay to more than 300 ms users report that the menus feel
“sluggish” (this is likely largely in comparison to the common industry
practice of implementing zero delay or a very small delay).

On
the other hand, object preview cards and the like are often invoked from lists
or grids of data and are invoked on hover over thumbnails and/or displayed names
of items.These types of elements often
populate a fairly substantial portion of the UI; therefore it’s generally more
appropriate to allow for a little longer hover.In this case, we believe it to be a best practice to also provide a
subtle, but immediate visual change to the underlying element.This is a good way to tell the user that a
pop-up is coming if he just holds his little horsies for a half second or so

Does sustained hovering solve everything?

Nope.Unfortunately, this technique does not
prevent inadvertent display in the less-common scenario in which users rest
their cursor on an active UI element.It
also doesn’t tackle other concerns of hover-invoked UIs like how best practices
for dismissal and how to handle touch screen interaction.I’ll look to blabber about those in a future
blog post.

In visual perception a color is almost never seen as it really is—as it physically is.This fact makes color the most relative medium in art.–Josef Albers, Interaction of Color

Our perception of color is constantly influenced by the relationship between a given color and it's surrounding color (or colors) and is an important principle to be mindful of when working with color. Below is a simple example of this principle similar to the studies found in the above quoted book (Interaction of Color - Albers, Josef). The two small squares in the illustration below are the same color but have been purposefully made to appear different by placing them on particular background colors.

This principle can also be seen within our products as well. As an example, the 'IBM blue' of our application icons can appear to be different in varying contexts i.e. the dark backgrounds of our mobile applications and the lighter backgrounds we use in our web UIs. The following two Connections icons are identical but have been placed on a light and dark background. It's not as stark as the above example, but you can see how the left icon appears to be more vibrant than the icon on the right, even though they are both identical.

This is the user experience KPIs talk that I gave last Monday at the Boston UPA 2012 conference. It was a very well-attended local UX conference (~560 UX professionals!) and had a lot of great sessions (32 in total). The detailed session topics are listed here. http://upaboston.org/2012/04/14/2012-conference-sessions/

Written, produced, and hosted by Julie Brown (Notes information developer) and me (Notes information architect), the podcast focuses on Notes tips and tricks - the little things that help you be more productive with Notes. Each podcast will have a theme - from "Preferences to know and love" to "Keeping your inbox tidy" to "Wrapping your brain around archiving". Episode 1 focuses on getting started right with Notes.

Podcasts will be published twice monthly on the 2nd and 4th Fridays. The podcast is available through the Notes Tips blog and iTunes.

ARIA Design Patterns help make your user interfaces easier for the blind person and the keyboard user to navigate. They specify what ARIA roles and attributes you should be using, as well as the keyboard behavior within the "widget." However, the W3C ARIA design patterns spec can be hard to follow. There are many related patterns, it's often hard to tell which one you should be using, and you have to drill down into multiple patterns to discern the differences. To help myself and others at IBM who try and match our designs to these patterns, I've created a road map (or what I fondly call a "Design Pattern Cheat Sheet"). I hope you find it useful.

At IBM, our web applications are required to meet WCAG 2.0 AA color contrast requirements, which are as follows:

Small text* must meet a 4.5 to 1 foreground to background color ratioLarge text** must meet a 3 to 1 foreground to background color ratioLink text must stand out from adjacent text by a 3 to 1 ratio (if it is only set apart by color).

* Less than 18 pt normal or 14 pt bold**Greater or equal to 18 pt normal or 14 pt bold

In other words, this is bad:And this is very bad, to demonstrate the point to even those with really good eyes

This is good:

As for links, this link doesn't have adequate contrast (2.5:1) from surrounding text. This link does (3:1). P.S. these are faux links so I could properly color the text.

The contrast ratio checkpoint specifically refers to text, but visual controls can have the same issue. You want users to be able to discover these controls, so follow the same principle (with the exception of a disabled control which users can't interact with, anyway).

Here is a real-world example of that. These controls (the "x" and double downward-pointing chevron images) are large text equivalent. But the first example is less than a 3:1 contrast ratio and could be a problem for some users:

The controls that follow have been adjusted to a 3:1 contrast ratio:

Subtle, yes, but as you can see, it makes a big difference.

NOTE: For icons with a non-transparent background, like this help icon , you should test the foreground color of the icon against the background color of the icon. The color of the background it is sitting on doesn't matter in this case. The user needs to be able to distinguish the question mark, not the background of the icon.

Why should we pay attention to this?

People with moderately low vision should not be required to use assistive technology to view our web applications. Most people's eyesight deteriorates as they age, so this checkpoint is very relevant to a large population of our users.

Tools and Techniques

The math to figure this out is ridiculous! Luckily you can use these tools to check your colors: