Design/Archive/Wikimedia Foundation Design/Patterns and components

This was developed mid-2012. See also Wikimedia Foundation Design/Agora Control Library

Guide Text and Help Hooks associated with Labels and input Fields

• The help hook will be an icon, which sites next to the associated field label
• It is an icon so it is universally applicable
• On hover Behavior: Invoke a standard Tooltip
• The visual design on this pattern is wip.

Flyouts

Flyouts (fundamentally different from tooltips) enable us to provide more information about an object without page transitions.

Add caption here

Edit Pages: Proposed Template Pattern

Templates that appear in an edit page will follow the patterns depicted in the mock in order to enable the following:

• Stay at a minimum Height and carry an icon so users can easily scan and recognize the message.
• Improve the page Hierarchy
• Prevent actions from going below the fold.

Edit Page Templates will follow this meta pattern

Guide Text pattern

Feedback messages

Feedback messages are messages provided by the system to the user as a response to different situations. Some announce problems that the user needs to pay attention to (alerts, warnimgs and error messages), and others represent positive feedback that provides the user with more info about events of interest for him (notifications and status messages).

Problems: Alerts, warnings and error messages

Interaction should be designed to make errors impossible. Nevertheless, the user may not be aware of the consequences of their actions or it is not possible to provide some functionality with the information the user provided.

This warning provides no direct way to add a category. The user needs to follow the "how?" link, read a long guide to learn how to solve the issue with little support from the system.

We recommend to:

• Avoid warnings if undo is possible. Since a warning breaks the action flow of the user, it is usually preferred to notify of the action and allow a way to undo it to the user. For example, after clicking a delete button it is preferred a message that says "Your post as been deleted. Undo." than a warning message saying "Are you sure you want to delete this post?" asking for confirmation.
• Provide a solution. Offer a direct way to solve the specific problem the system is complaining about when possible.
• Make it contextual. Place the information close to its related element.
• Allow to disable if it may be annoying. For repeated actions or messages that consume too much screen real state, a mechanism to hide it may help the user to avoid distractions.
• Depending on the periodicity of the disablement a different solution is recommended:
  • Just once. A close "X" indicates that the message disappears for the specific moment.
  • In a long time. A checkbox may be used to indicate that the user do not want this kind of messages to appear for a long time.
  • Forever. In addition to a checkbox it is recommended to indicate the user that this action can be reverted later and where.

Notifications and status messages

We recommend to:

• Avoid technical details. Inform users about events that are of interest for the user goals and express them in such terms.

Loading indicator

Design for a loading indicator

When operations are expected to take some time or elements are lazily loaded (e.g., using infinite scroll), a loading indicator help to communicate the status of the system.

Tooltips

A tooltip is a method of revealing additional information about something within the interface to the user without cluttering up the system or forcing the user to visit a new page.

We recommend:

• Create contrast with the content background. Use a background color for the tooltip that distinguishes it from the content background.
• Strongly indicate what the tooltip is connected to. The use of "weak" and shallow pointers is strongly discouraged as users with poor vision may have difficulty associating the tooltip with its affordance
• Keep revealed information succinct. Consider character budgets of around 200 characters, with a "learn more" link if more information is available
• Style included hyperlinks to appear as hyperlinks. Since the color of the text changes within tooltips, included hyperlinks must be explicitly called out. This is best done with a brighter color than the tooltip text, underlining, and bolding.

We do not recommend:

• Using tooltips which are only activated upon hover. Hover behaviors are fine and good but are not possible in the realm of touch devices.

Behaviors

Tooltips should be designed thinking for touch interfaces first and mouse interaction second. "Hover only" tooltips can be considered with progressive enhancement but should never be essential to the use of the software.

Tapping or clicking on the tooltip affordance should activate the tooltip until it is dismissed. Tooltips should have multiple ways to be dismissed (not all will be appropriate for any one tooltip):

• Including a "close" affordance within the tooltip (an "X" button)
• Clicking anywhere outside of the tooltip
• Clicking within the tooltip
• Automatic closing after a specified time

Lists: showing and manipulating data elements

Lists represent a sequence of data elements that can be manipulated in different ways. Depending on the size of the lists several organization and manipulation techniques may be applied such as allowing filtering, sorting and searching elements in a list.

Filtering

Filtering allows the user to access a subset of interest from the list according to a criteria. The criteria can be expressed either as a single option choice (exclusive filters) or as a multi-dimensional filter (where multiple values are available for each filtering criteria considered).

Exclusive filters

Article Feedback page showing data filtering and sorting. A standard HTML selector was used to compact the additional filters in this case.

For exclusive filters we recommend to:

• Show filters directly above data. By showing the different filters directly in the list header, users can discover them easily and better understand they are views on the data displayed.
  • Filters will be presented following the style of links (blue without underline).
  • If there are a high number of filters, some of them can be collapsed into a more filters drop-down menu.
  • A filter to show all elements is normally included and it is usually located either as the first or last filter from the list.
• Highlight the active filter. Highlighting the active filter is done by changing the color of the fragment of the separator used between the list header and the data.
  • Selected filter label will be presented as emphasized text but not as a link since it is no longer interactive.

Multi-dimensional filters

For filters that allow to adjust multiple dimensions at a time we recommend to:

• Make each dimension exclusive. Define categories where the user can select just one option for each and a default non-filtering option (all) is selected by default.

For example, a dimension such as "Filter by date" may be composed of "Any moment" (default option), "today", "this week", "this month".

Sorting

When adding sorting options we recommend to:

• A drop-down menu at the right. The common representation and location are a simple drop-down menu located at the right of the list header.
  • When only two options are provided it can be represented as a pair of toggle buttons o radio buttons.
• Name sort criteria in a way that expresses the direction. By expressing the ordering direction the label becomes self-descriptive. For example, it is better to use "Newest" and "Oldest" than having a "by date" criteria and a separate selection for the ordering direction ("Ascendent", "Descendant").

Searching

The Universal Language Selector provides a message that allows the user to check if he made a typo and be aware of alternative ways of looking for content.

When the number of elements is high, and they have properties the user use to identify them, search is a good option to reduce the complexity of the list.

When adding a search filtering to a list we recommend to:

• Make search flexible. Do not force the user to use a single format or property for the search. For example, the Universal Language Selector allows users to search for a language name using the language name in a different language or ISO codes.
• Do not force the user to filter in advance. If search is performed across different categories of content it is preferred not to make the user to indicate the category before the search is performed. It is preferred to perform the search for all the categories and provide filtering options in the result page to show only the results of a specific category.
• Anticipate the user with suggestions. By provide as-you-type suggestions to the user would make the search process more fluent.
• Leverage the no results found message. When no results are found inform the user of this, include the term he used for the search in the message (to increase the chance of detecting typos) and provide alternative instructions/suggestions/tips for the search.

List creation

Universal Language selector Mock Up illustrating the use of multiple selection.

The Upload Wizard shows a list of files where they can be added by dragging, and can be removed by acting on each element.

When creating a list of elements (such as files to be uploaded or the languages the user speaks), we recommend to:

• Make elements removable. By including an "X" icon, elements can be removed from the list.
• Include an add button.
• Optimize the workflow for repeated actions. If the user is building a list he will probably add more than one item. Any shortcuts that can be provided to repeat the action may make the process moe fluent. For example, the Universal Language Selector support for multiple language selection keeps the language list open so users can add new languages without opening the the selector again.

Menus

Section menus

A mobile version of Wikipedia showing a menu where the active section is highlighted with a decoration at the side.

The Universal Language Selector makes use of this approach to indicate the current section.

In order to represent different sections for some content.

We recommend to:

• Highlight the current section. The current section can use a color decoration rectangle at the initial extreme of the section label and a modified background color (see examples below).

Contextual menus

Context menu pattern described

Contextual menus are represented as drop-down menus associated to a content element they affect.

We recommend to:

• Group options.
• Use a check mark for multi-state elements.

Buttons/Actions

A button is a label and/or icon that represents an action the user can make. Buttons normally have a border and background that make them look pushable. Actions can be also represented by means of border-less buttons (when they are integrated in another element such as a list) and links (when the action is related to navigation and has no side-effects).

New Agora states

The new Agora design in September 2013 revised the semantics and appearance of buttons.

The four columns are for different kinds of actions

• other
• destructive, such as deleting a comment
• continue ("next", e.g. on a multi-step form like commons:Special:UploadWizard)
• completion (the final step on a form)

The top two rows show the notion of "secondary" actions, which appear as bold text with no button border. For example, a Cancel link next to [Submit changes] button. The second row shows these actions revealing their action semantics (red text for destructive, blue text for continue, etc.) on mouseover.

The next four rows with buttons that look like buttons show the different states of buttons:

• normal
• mouseover
• click
• disabled

The buttons in the last two columns are for the primary action on a page. This one action should always be distinguished from other actions available.

Note that this 35px tall design is for big buttons for a form or dialog. The button specs for the Flow project (File:Buttons Flyout.png) show 30px tall buttons that are more appropriate inline and with lots of text

The Flow button specs also add "less destructive" orange and yellow button colors, and a clicked state for a [Thanks] button. These will probably remain specific to Flow

Implementation

CSS class mw-ui-button gives a default "Other actions" button; add classes to this for other action kinds mw-ui-destructive, mw-ui-continue>continue, and mw-ui-primary (or "completion", TBD).

The Agora styles available as of October 2013 have a "mw-ui-primary" style (for the main Submit interaction, in blue in Vector) and a "mw-ui-constructive" style (for other actions, in green in Vector). mw-ui-primary maps to the new completion action (i.e. it becomes green); mw-ui-neutral becomes a no-op.

Currently, add mw-ui-text for the non-button secondary actions.

Disabled/Enabled state changes

Since users have often expressed confusion when actions become available, if a button is to change state from disabled to enabled during an interaction this must be made explicit with a bold change.

Dialogs

Flyout Dialogs

A flyout as seen in the Curation Toolbar

Flyout dialogs are control panels which are tightly coupled to their activation affordance. Flyout dialogs are similar to tooltips but are typically more robust in function.

Flyout dialogs should have the following behaviors:

• A clear pointer to the activation affordance
• A "close" control, which
  • cancels all activity within the flyout (returns it to default state)
  • closes the flyout

Clicking (or tapping) anywhere outside of the flyout should close the flyout.