Posted by & filed under Content Views.

Data lists have become a popular alternative to tables for displaying structured data as they provide more flexible presentation of information, media, and controls that can reduce the need for users to navigate between overview and detail views of information.  PatternFly currently supports this presentation as part of the List View pattern.  In looking at this page, you will see a variety of options for displaying textual and graphical information in the context of a row.

The expandable list view builds on that work by allowing users to expand any row in the list to reveal more details about an object.  This is useful when you want to give users direct access to more details about the object without requiring them to open the object in a separate view.  This pattern builds on the principle of progressive disclosure, although it differs in that the goal is less about hiding advanced functionality than it is about allowing the user to view details of an item in context.

The Proposal

The proposal offers up two options for list expansion.  The first is a simple case where all details are displayed within a single expandable panel.  The second option addresses a more complex use case where a data list row may have multiple expansion panels that hold the details associated with different items displayed in the row. Let’s start with the simple case.

Option 1: Simple Expansion

Here, the user is presented with a list of objects, in this case storage pools, and they want to view details related to the first item in the list.  The right caret placed at the start of the list entry communicates that this row can be expanded.



The user clicks anywhere in the row to reveal the details. The row content remain visible as the header of the expanded panel.



When the user wants to hide the details of this row, they will click Close.


Option 2: Multiple Expansion

Now let’s address the more complex case where you may want to expose multiple detailed views associated with the same some. This is illustrated here.
Option 2

Note that in this example, both OSDs and Alerts will reveal separate details views. To indicate this a progressive disclosure affordance, in this case the right caret, is inserted to the left of the field. A hover effect in added when mousing over the field to provide additional feedback indicating that this is an interactive element.

Single clicking on the element will reveal its details as shown below. The row element will remain highlighted and the direction of the caret will change to indicate that this element is currently expanded.


Option 2 open


Again, clicking close will collapse the expansion. The user may also close these details and expand a different element by clicking on that item in the header row.

Default Conditions

In all cases, all rows will be closed (collapsed) when the list view is initialized.  Filtering of sorting will have the effect of re-initializing the list and will close any row that is currently expanded.

Open Issues, Questions, and Further Work

In creating this proposal, there are a few questions that come to mind:

  • When a panel opens, how should this affect the space occupied by the list? Should the list grow vertically and other content be pushed down the page? Or should the height of the list be fixed and a scroll bar appear to let users scroll to items further down the list?
  • Would users ever want multiple rows expanded at once? Or should this behave more like a standard accordion where expansion of a new row closes any currently open details panel (i.e. only one row can be open at a time)?
  • Differentiating between expansion and drill-down navigation must be addressed.  Will it be clear when single clicking on a list entry results in list expansion vs. drill-down?

Our next step will be to finalize this design, but first we welcome your input and comments. Do you feel like this pattern will be useful? Are there other options or issues that need to be considered?

Posted by & filed under Data Visualization.

This blog addresses the initial design for the line chart pattern in PatternFly.  We are specifically interested in finding out expectations for interactions.

* How would you expect the user to interact with the line chart?
* How would you expect the info tip to behave?

Please leave comments with any questions or suggestions you may have!

The most common use case for line charts is to compare several data sets, or to show data over a period of time.

Multiple lines on the same chart allow the user to visualize relationships between varying data sets, such as correlated events, similarities or unexpected differences.  We recommend displaying no more than 6 lines on a single graph to avoid confusion.


Axis Labels & Tick Marks

When the use case is visualizing data over a period of time, the horizontal axis represents time values and the vertical axis represents values.  Axis labels are typically shown on both axis, and have associated major tick marks.  Minor tick marks are a useful tool for the user to be able to estimate values.

Grid Lines

Horizontal grid lines are recommended, since they help the user visualize the value.  Vertical grid lines are unnecessary when visualizing data over a period of time.


For recommendations on line colors, see the PatternFly Color Palette.  Points can optionally be shown to represent the data points on the line.

Info Tips

We suggest that an info tip be shown, including the time value associated with the data points along with each series name and data point


Some applications may allow the user to perform actions associated with a line.  In this case, rIght clicking on a line could bring up a contextual menu with associated actions.

Zooming in and out within the chart could be accomplished with a mouse or by changing a an associated time filter.  This topic will not be covered in the initial round of design.


PatternFly legends have already been discussed in both the Donut Chart and Bar Chart conceptual design and

Data Points

In the initial round of design, we are not covering these topics:

* Handling missing data points
* Handling outlier data points

Posted by & filed under Data Visualization.

PatternFly defines the use case for using the Donut Chart for utilization or progress. However, we also need to address the use case of showing the relationship of a set of values to a whole using the donut chart.

This blog post addresses the initial concepts and approaches for the Donut Chart – Relationship of a Set of Values to a Whole. Some of the outstanding questions I have about this pattern are related to where this documentation should live on the site. If you were looking for this type of donut chart, how would you expect to find it? Would you navigate to:

  1. A page called “Donut Chart” and expect to see all the use cases for a donut chart in one place.
  2. A page that addressed the specific use case of the relationship of a set of values to a whole. This may include other visualizations in addition to the donut chart.
  3. A page called “Donut Chart – Relationship of a Set of Values to a Whole” meaning each donut chart would have its own page.
  4. Other?

Please leave comments in the blog about how you would expect to navigate to this pattern as well as any other comments that you might have about the current direction.




  1. Donut Chart Fill:
    • 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.
    • Color: For recommendations on fill colors, see the Color Palette.
  2. Total value: The total value is shown in the middle of the donut chart.
  3. Label or Icon (optional): When the donut chart is a part of a dashboard tile, there is a label defining what the donut chart represents. The label may be shown in the inside or outside of the donut chart.
  4. Set of Values: It is recommended to show the set of values on the donut chart. This may be shown:
    • On the chart
    • In the legend
  5. Tooltip: We recommend that the name and value or percentage are displayed on hover.
  6. Legend: It is recommended to include a legend to define the colors on the chart. Optionally, you may opt to make the legend interactive meaning that you could toggle the visibility of the series in the chart. On the bar chart, there are a couple of locations for the legend:
    • Left aligned and centered underneath the chart.
    • Left aligned and to the right of the chart.

Posted by & filed under Navigation.

The problem:

You want to simplify navigation by not exposing secondary levels of navigation at all times

Last month I published a blog post discussing vertical navigation and how a multi-column approach can be used to expose up to two levels of navigation in a vertical format (see Vertical Navigation: Finding your Way). At that time I discussed some of the advantages that could be provided by implementing a persistent two column navigation system. There may be times, however, when exposing two levels of persistent navigation is neither desirable or necessary. This may be the case when you either don’t want to allocate the space for two persistent columns on your page or when you decide that secondary categories are not closely related and the likelihood of users wanting to quickly more between these categories in a single click is small.

The solution:

Implement secondary navigation as a non-persistent fly-out menu

A non-persistent, fly-out approach to secondary navigation is the proposed approach.  This is similar to the persistent navigation menu proposed in the earlier blog post, except that when the secondary menu is open, it simply overlays page content without requiring any shrinkage of the content area available to the application. The secondary menu will automatically dismiss when the user either selects a category or mouses-out of the region occupied by the menu.


Admin-Non-Persistent Secondary

Notice that unlike in the case of the persistent navigation, the secondary menu (1) need not occupy a full column from the top to bottom of the content area.  In fact, keeping the menu compact and making it only large enough to show the required number of menu items is preferred as it will best keep the users eye focused on the options available.  Also, centering the menu vertically with its parent item reduces the amount of required mouse travel and reduces the likelihood that users will accidentally dismiss the menu by leaving the menu when the make a quick rightward movement.

One of the key drawbacks of fly-out menus is that there is no way to use the menu to reflect the users current location in the site since the navigation item related to that page is hidden after the user selects it.  Because of this, when using non-persistent secondary navigation it is important to clearly label the page to provide the user with feedback regarding their current location.  In the illustration above, Events, the current page is clearly titled (2) and shown selected when the menu is open (3).  The Admin item in the primary navigation also appears as selected (4).

Here are some additional considerations that should be taken into account when implementing this pattern:

Mobile considerations

When the screen width will no longer accommodate the fly-out menu, an “off-canvas” approach will be used to keep two levels of navigation within one column by giving the appearance of a menu the slides left and right to expose either the primary or secondary set of menu choices.

Storage - Mobile nav

Posted by & filed under Content Views.

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.


A successful design for this pattern…


  • Enable users to perform actions on one or many objects.
  • Contain a list of all possible actions within the current context


  • Smoothly accommodate multiple window sizes
  • Scale to large numbers of actions without clutter
  • Allow for logical groups of actions


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

Conceptual Design + Description

simple actions 1

  1. 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.
  2. 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.

more actions menu

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!




More actions menu button – fa-ellipsis-v from Font Awesome.

Current angular implementation –


Posted by & filed under Data Visualization.


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.

Grouped Vertical

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.

Grouped Horizontal


The following components make up a bar chart

  1. 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
  2. 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.
  3. 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.
  4. 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.
  5. 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!

Posted by & filed under Content Views.


Overview & Usage

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

  1.  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. Table View - 2
  2. Data Toolbar Pattern:   includes a number of components that work in conjunction: simple filter and simple actions (table actions)
  3. 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.
  4. 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.
  5. 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.
  6. 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.Table
  7. 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
  8. 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.
  9. 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
  10. 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:

  1. Pagination
  2. Column customization
  3. Simple Sort
  4. 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

  1. The visual design will be created and examples in context will be provided.
  2. 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!



Reference Documents

Older wiki proposal for Table including jquery example:

Basic bootstrap current example:

Usability Testing results done on old proposal:

Current Simple Filter Design:

Current Simple Sort Design:

Current Simple Actions Design:

Blank Slate Design:

Posted by & filed under Navigation.


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.

Dashboard-select storage 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.

Storage -Volumes Figure 2: Secondary categories exposed in an additional vertical menu pane.

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.

Figure 3: Vertical navigation with primary navigation in collapsed or minimized state.

If one only wishes to collapse the secondary menu, they may do so by clicking the collapse button on the secondary menu pane as illustrated in the second wireframe below.

Admin-Full Width Figure 4: The secondary navigation menu can be hidden by toggling it closed.

What’s Next?

We will continue to elaborate on this design and evolve a full visual treatment of the concepts presented above.  Some of the questions left to be considered include:

  • How to include badges and indicators on menu items without introducing undue clutter.
  • When icons are useful and when they should be applied.
  • The integration of breadcrumbs and drill-down patterns for browsing hierarchical data sets.
  • How to handle secondary navigation when persistence is neither necessary or desirable.

Your input and feedback on any and all of these topics is much welcome!

Posted by & filed under Communication.

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.



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


  • 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:

  1. A notification with multiple actions.
  2. A notification that has title and details.
  3. 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

  1. The visual design will be created and examples in context will be provided.
  2. 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!