Simple actions is a pattern that houses actions for the objects in the current view (tile view, list view etc). These actions can apply to all of the objects in the view or a subset of them. Simple actions is often displayed as part of the Data Toolbar.

Requirements

A successful design for this pattern…

Shall:

Enable users to perform actions on one or many objects.

Contain a list of all possible actions within the current context

Will:

Smoothly accommodate multiple window sizes

Scale to large numbers of actions without clutter

Allow for logical groups of actions

Should:

Offer a mobile friendly configuration that does not rely on hovering to function correctly

Conceptual Design + Description

Primary Action buttons: These buttons contain the most frequently used and most important actions for the current view arranged with the most common actions on the left. When possible, at least one primary action should be visible at all times.

More actions: Less commonly used actions should be placed within this menu. As a window gets smaller, primary actions can be moved into the more actions menu in order to conserve space. The click/touch target for the more actions button must be at least as wide as the icon is tall, even though it might not be visible.

a. Actions in categories are listed individually if there are 15 or fewer items in the list.

b. If the more actions menu holds more than 15 items, categories of actions are collapsed and become flyout menus. The flyout should not require the user to click, and should appear when hovering over the category name.

c. On mobile devices, all actions are collapsed into the menu. Categories become accordions that expand and collapse when tapped.

What’s not covered in the current design

Rules pertaining to icon use

Rules about action names

Next Steps

After review, this pattern will be moving into the final design phase. High-fidelity visual assets and examples in context will be created, and the revised, polished design will be posted.

Voice your opinion! Comment on this post with thoughts, suggestions, or requirements that we may have overlooked. Any and all feedback is helpful to us as we refine the design in the next stage of the process. Thanks!

Bar charts are used to visualize quantitative data. Since bar charts differentiate by length, we recommend that in most cases they be used rather than donut or pie charts, which differentiate by angle and area.

Vertical Bar Chart
The most common use case for vertical charts is to show data changes over a period of time or for illustrating comparisons among items. In vertical charts, the x-axis represents category or time and the y-axis represents the value.

Grouped Vertical Charts

The most common use case for grouped charts is to show information about different sub-groups of main categories. The x-axis of grouped vertical charts represents sub-group or time and the y-axis represents the value.

Horizontal Bar Chart
Use a horizontal bar chart if time is not represented by an axis and if either of the following conditions exist:
A ranking in descending order is the relationship being conveyed
The labels for the categorical subdivisions don’t fit side by side
In horizontal bar charts, the x-axis represents the value and the y-axis represents the category.

Grouped Horizontal Charts

The most common use case for grouped charts is to show information about different sub-groups of main categories. The x-axis of grouped vertical charts represents the value and the y-axis represents the sub-group.

The following components make up a bar chart

Axis Labels:

For vertical charts:

Horizontal axis labels display the series names and are recommended, but can be omitted if necessary due to space constraints and responsiveness. If omitted a legend must be available.

Vertical axis labels display values

For horizontal charts:

Vertical axis labels display the series names and are recommended, but can be omitted if necessary due to space constraints and responsiveness. If omitted a legend must be available.

Horizontal axis labels display values

Axis Tick Marks (optional):

There can be both major and minor tick marks on the vertical axis of vertical charts. Tick marks are not needed on the horizontal axis of vertical charts since the horizontal axis of a vertical bar chart is not a quantitative scale line.

There can be both major and minor tick marks on the horizontal axis of horizontal bar charts. Tick marks are not needed on the vertical axis of horizontal charts since the vertical axis of a horizontal bar chart is not a quantitative scale line.

Grid Lines (optional):

Horizontal grid lines are suggested for vertical charts, but should not be used with horizontal bar charts.

Vertical grid lines are suggested for horizontal charts, but should not be used with vertical charts.

Bar

Interaction (optional):

If drill down behavior is supported, clicking on an item will navigate to the appropriate page.

If supporting, right clicking on an item will bring up a menu with associated actions.

Width: All bars should be the same width.

Fill: For recommendations on fill colors, see the Color Palette.

Height: Bar height in vertical charts is the dimension that represents its value.

Length: Bar height in horizontal charts is the dimension that represents its value.

Bar Spacing: Spacing between bars should be equal. In the case of grouped charts, increase the spacing between main categories.

Tooltip: We recommend that the name and value are displayed on hover.

Legend (optional):

Include a legend to indicate the series with the bar color.

We recommend placing the legend left aligned under the chart.

Interactive Legend (optional): Clicking on a series in the legend should toggle the visibility of the series in the chart.

What’s not covered in the current design

Dealing with missing data points

Stacked Bar Charts

Next Steps

The above is considered conceptual design, final visual design will be created and examples in context will be provided. This design pattern will be going through it’s final stage of the PatternFly process.

Have we missed any requirements? Please leave a comment below if you think we need to make any clarifications in the next iteration! Any feedback will be appreciated. Thank you!

A table organizes data into rows (of items) and columns (of item attributes). Tables make structured data easy to scan, compare, sort, and analyze. Tables can be embedded into other design patterns. Tables are familiar to users and often the correct choice for structured data, but be careful not to overuse tables. Here are some examples of when not to use a table:

The table pattern should NOT be used when:

Do users need to find patterns within a data set? Consider a line chart or a bar chart.

Are users going to browse the data set without knowing exactly what to look for? Consider using a Data List.

Conceptual Design + Description

Empty State: If no items exist in the table, display the empty state pattern. All features within the data toolbar will be disabled in this state.

Data Toolbar Pattern: includes a number of components that work in conjunction: simple filter and simple actions (table actions)

Sorting: Organize data by sorting one or more columns. All columns are sortable, simply click on the column header to sort via info found in that column.

Active column will be highlighted with a blue line above the column and blue text. The carat indicates the direction of the sort, in this case from ascending order alphabetically.

Select Row(s): Checkboxes allow the user to select multiple rows in order to perform bulk actions on those rows simultaneously.

Selecting row(s) activates the checkbox and highlights the row. This highlight is more prominent than the highlight for hovering over a row.

Hover State: When the user hovers over a row, that row will be lightly highlighted and outlined. This helps the user to isolate the row, especially when clicking on items in the row.

Inline Actions: Inline actions can be performed within a single row to manipulate the data. The most common 1-2 (max) actions are shown as a button with additional actions, if any, available via a dropdown menu. These actions should use words rather than icons for clarity.

Bulk Item Actions: Bulk item actions buttons are activated when row(s) are selected. Some actions are available as both a table action and a bulk item action. The number of rows selected is shown near the table action buttons

Filtering: User can see results of simple filters here. Results include the item and results count, list of active filters (with ability to remove individual filters), and button to clear all filters.

Select All Rows: Selecting the checkbox in the header row selects all rows on the page. The total number of rows selected is shown near the table action buttons

Row Highlight (Recommended but optional to turn off): If the table uses alternating row shading, the hover state should be distinguishable from the shading colors used.

What’s not covered in the current design:

Pagination

Column customization

Simple Sort

Ability to expand and collapse rows to give user the option to view more details on each item

Please let us know if we are missing any other features in this particular pattern.

Next steps

The visual design will be created and examples in context will be provided.

Additional stories have been added to the backlog for more features, such as pagination, expand/collapse rows, simple sort, customizable columns.

Feel free tell us what you like and what you think we could improve upon. Any and all feedback will be helpful with helping us to refine the design in the next iteration. Thank you!

Overview

P>You should use a vertical navigation pattern when your application requires global navigation (i.e. navigation that persists throughout the application) that will be displayed in a vertical format anchored to the left-hand edge of the viewport. While vertical navigation menus generally consume more pixels (i.e. more total area) than their horizontal counterparts, they have become more popular as desktop monitors move to wide-screen formats. Vertical navigation has several advantages:

They are more extensible than their horizontal counterparts as the number of menu items in not constrained by the viewport width.

Vertical menus more readily adapt for small screen sizes. While horizontal menus can also be made responsive, they usually require that they be transformed from horizontal to vertical below a certain screen resolution. Since vertical menus are already in this format, the transition from desktop to mobile is less disorienting.

Finally, vertical navigation supports common left to right flow where navigation categories are easily differentiated from other information that may exist in the header area of the application.

Despite these advantages, it has been shown through research that the left-hand edge of the screen is the most prominent visually (along with the top header). Using a large amount of this area for persistent area may steal pixels away from more important tasks, and therefore, strategies for hiding or collapsing vertical menus are an important consideration.

The Proposal

The basic format for a PatternFly page using vertical navigation is shown below. This page requires only a single level of navigation as Dashboard requires no local or sub-categories.

Figure 1: Primary categories fully exposed.

Notice that the selected state and hover states in the menu receive unique visual treatments. This will help ensure that the user always knows where they are and has sufficient visual affordance to call out active elements. Icons are included with the text labels to speed recognition. The visual design of these elements is still a work in progress.

When a page needs to expose a secondary level of options, an additional persistent column is opened to the right as shown below.

Here, a secondary set of categories is exposed in the subordinate menu. Selected and hover states are also important here to make behavior visible. The example shown here includes an additional hierarchical grouping of secondary menu items and added indicators to reflect the number and status of items in the exposed categories. These elements are entirely optional and may be used to reflect specific requirements driven by your information architecture and user cases. When including these added elements, one must always take care to consider the benefits of providing users with this feedback against the potential visual clutter it may create. In all cases of navigation design, providing users with a clear map of where they currently are and where they can move to should take precedence over other considerations.

Another design goal was to be sensitive to the user’s need to get navigation out of the way and focus on content. The current proposal provides for that is two ways. By clicking the menu icon in the upper left corner of the page header, it will be possible to toggle the state of the primary navigation by collapsing it into a thin strip of icons that cling to the left-hand edge of the viewport as shown below.

Previously, we blogged about the new generation of inline notification, which will be used in context. However, in reality there are cases that users should be notified when they are out of context. For example, when a large file is uploaded to the system successfully, the user should be notified wherever he/she is in the system. In those cases, pop-over notifications (toasters) should be used. Please check out the conceptual design below and help us refine the design.

Overview

Pop-over notifications or toasters are fly in or bubble message which pop onto the screen to notify the user of a system occurrence. The notification should be located at the top-right of the screen and there should be a message list that allows the user to view messages later. The notifications should have a consistent location in each application.

Pop-over notifications should always be transient and they should stay on the screen for at least 8 seconds, so that they won’t block the information behind it for too long and users will still have enough time to read the messages in the notifications. Ideally, the user can configure the notifications and decide what they want to see and how long they want them to stay. In addition, pop-over notifications should remain on the screen when the user is hovering on them.

Generally, there shouldn’t be more than one pop-over notification shown at the same time. If two notifications are triggered at the same time, they should be shown one by one, and each of them should stay on the screen long enough for the user to read.

Conceptual design

Description

Icon: Indicate the type of the notification. There are four types of available notifications: info, success, warning and error.

Message: Show a short message within the notification and make it clear what just happened or what the user needs to perform next. Do not include any unnecessary text because the user might not have the time to read it. Ideally, the message is no longer than one line.

Bold the important information, e.g. name of the object

Use the regular font weight for the rest of the message

Action (optional): Show the action on the right to allow the user to take an immediate action without having to navigate to a different page. Clicking on the action button should either help the user achieve the goal automatically or open up a modal window on the top of the current page. After the user clicks on the action, the notification will be dismissed right away. Directing the user to a different page is not recommended. Do not include more than one action. Do not use the label Cancel, Dismiss, or Close, use icon instead.

Close (optional): Allow the user to dismiss the pop-over notification by clicking on the Close icon. Do not show Close icon and action in the same notification.

What’s not covered in the current design:

A notification with multiple actions.

A notification that has title and details.

An expandable/collapsible mechanism that allow the user to get a little bit more details while looking at the notification.

Please let us know if any of these is needed in the application you are working on and if there is anything else we are missing in this pattern.

Next steps

The visual design will be created and examples in context will be provided.

Animation will be designed and demonstrated.

Feel free tell us what you like and what you think is improvable. Any feedback will be very helpful for us to refine the design in the next iteration. Thank you in advance!