Posted by & filed under Navigation.

Vertical navigation is increasingly the solution of choice for enterprise web applications.  It is more scaleable and adapts more easily to small viewport sizes (i.e. mobile).  It has also been shown that locating all levels of navigation on the left-hand side of the page outperforms hybrid approaches that combine top and left navigation menus. [1]  At the same time, some known drawbacks for vertical navigation systems include the consumption of valuable pixels that otherwise can contain page content and difficulty with interaction if fly-out menus are employed. [2]

For PatternFly, we require a vertical navigation solution that will support information hierarchies that go up to three levels deep.  Representing deep hierarchies and making options visible while using a minimal amount of screen real estate is a challenge.  Any recommended solution should provide clear guideposts that provide the user with visibility to where they currently are and where they can go within the navigation hierarchy.

A 2015 article published by the Nielsen Norman Group [3] makes the following recommendations to designers of web navigation systems:

  • Options should be made visible when possible – don’t hide navigation options on large screens.
  • Make sure there is sufficient visual contrast between menus and other screen content.
  • Always provide clear feedback about current location to let users know where they are at all times.
  • Make link labels easily scannable.
  • Make it easy to navigate locally within a section.

After an informal survey of existing examples of vertical navigation used across a variety of web sites and applications, I suggest that vertical navigation solutions can be grouped into several categories as follows.


Accordion Style or Stacked Navigation

Accordion style navigation supports the presence of multiple levels of navigation within a single menu.

Screen Shot 2016-04-20 at 3.45.12 PM


Key features of an accordion style solution are the ability to expand and collapse branches within the hierarchy to provide access to secondary items.  This approach works well for representing large hierarchies in a single menu, but does not work so well for representing hierarchies more than two levels deep.  It also is not very scannable as users must open each top level items to see items below.



In this approach, a single column is still maintained but rather than open sub-categories in a stacked design, lower levels replace the original menu and a breadcrumb placed at the top of the menu allows navigation back up the tree.  This is similar to the “hub-and-spoke” style navigation used on device based interfaces before the advent on touch screens.


Screen Shot 2016-04-20 at 3.38.16 PM


The drill-down approach is designed to keep users focused within a single area of the site enabling easy movement locally between pages within a single section.  The major disadvantage is that visibility to other parallel sections is lost, and moving across sections of the site requires the user to navigate back up the tree before drilling back down.



Fly-out menus are commonly used to access secondary and tertiary categories below a single top level menu by “flying-out” a sub-menu to the right that overlays the content area.




While fly-out menus provide a flexible solution to the mutli-level navigation problem and are easily extensible, they do not provide good visibility to options at the same level of navigation after a page has been selected since these menus do not persist.  This effect can be offset by good use of breadcrumbs to tell users where they currently reside in the page hierarchy.  Fly-out menus can also be difficult to interact with as they represent a small target for mouse travel (see Fitts’ Law).  Alternatives to fly-outs are Mega-Menus and Non-Persistent Columns that are described below.



The mega-menu opens as a panel that can accept rich content of any type.  Typically these menus are used a retail sites and enable grouping of large numbers of links.


Mega-menus provide good visibility to all options and can include links to content at multiple levels without the cascading effect of standard fly-outs.  Because content is intentionally pre-formatted within the panel, they are less flexible and dynamic when adding or removing content and cover large amounts of the page content area.


Non-Persistent Columns

Another approach is to distribute levels of navigation to one, two, or three fly-out columns that cascade to the right.


Screen Shot 2016-04-20 at 3.58.29 PM


This approach is similar to the standard fly-out menu except that the fly-out panel fills the height of the screen.  This may offset some of the mouse-travel problems associated with the fly-out menu while covering more screen area when the menu is open.


Persistent Columns

A final approach is to display multiple levels of navigation in persistent columns.  This is the technique used in the existing PatternFly Vertical Navigation Pattern.


Screen Shot 2016-04-22 at 1.59.44 PM


Here, the second-level navigation is always visible in a permanent column that cascades to the right.  This provides the user with great visibility to where they are within the information hierarchy and allows easy movement between local categories.  But this comes at a cost since the two-column approach uses a significant amount of screen real estate.  Because of this persistent columns are not really practical for navigating when the hierarchy contains more than two levels.


Comparison of Navigation Styles

The following table compares these different approaches by applying the four of the five criteria for effective navigation design identified in the Nielsen Norman Group article [3].  The requirement for providing good visual contrast was ignored based on the assumption that any of these approaches can succeed from that perspective by applying good visual design principles.


You can see that there is no perfect solution here.  Based on the criteria, a vertical navigation with persistent columns may provide the best overall usability, but it also consumes the most screen area (taking away from content) and is therefore constrained to practically showing no more than two levels of navigation.  Other options trade some degree of visibility to current location and options for minimizing the amount of screen width dedicated to navigation.  Also weighing the importance of navigating inside of a section (i.e., local navigation) against easy movement between sections will likely bear on a choice of navigation style.  For PatternFly, the right answer might include a small subset of styles/patterns or some hybrid pattern.


What’s Next

Our goal is to arrive at an approach to vertical navigation that can work across multiple enterprise applications.  This may include one or more new patterns and will be based on prototyping and testing of existing solution.  More to come on this.

What are your thoughts?  I am interested in hearing about how you have applied vertical navigation approaches within enterprise applications your have worked on.  What has worked well?  What has not?  And do you feel there are options that I haven’t explored or do you have ideas on combining patterns into a more optimal approach?  I’d love to hear from you.


[1] Navigation: Left is Best, by Bob Baily, April 1, 2006,

[2] The Case against Vertical Navigation, by Louis Lazaris, Smashing Magazine, Jan 11, 2010.

[3] Menu Design: Checklist of UX Guidelines to Help Users, Kathryn Whitenton, Nielsen Norman Group, Nov 29, 2015.

Posted by & filed under UX Research.

This March, PatternFly community leadership developed a survey to gather feedback and ideas on how to make our various methods of communication better suit the needs of current and prospective community members. In this post, we’ll share the results and our interpretations, as well as actions we’ve already taken based on the feedback received.

Who came to the party?

The survey was intended to solicit feedback and opinions regarding the monthly PatternFly community meeting and various other communications. Respondents were also asked to provide basic background information, such as their discipline of practice and current role.

Invitations were sent via multiple channels: the PatternFly mailing list, a Red Hat user experience design (UXD) team member distribution list, and the #patternfly IRC channel on Freenode. The survey was also introduced during the March community meeting. Because many invitees were members of multiple channels, it’s estimated that approximately 120 individual people were invited to respond. Of those, twelve community members responded to the survey. Admittedly, a 10% response rate is less than ideal, but the input that we gained has been valued nonetheless.


PatternFly serves both designers and developers and we want to make sure our communications are useful for both groups. Respondents mostly identified themselves as designers (interaction or visual). Developers were probably too busy cranking out code to participate in the survey, but we’d still love to hear from them in the comments!


A fairly even split between individual contributor and leadership roles prevailed with our respondents. Knowing this, we will make sure that we include messaging for both audiences — nuts-and-bolts how-to content and future-looking information for planning.

What’s the news?

At any given point in time, PatternFly has many concurrently running projects discussed on many different avenues. To help members home in on just what they’re interested in, we wanted to make sure that we generate “Goldilocks” content: not too much, not too little, not too frequent, not too seldom, not irrelevant…juuust right.


Note: Values for the mean (average) and median (the point where half of the responses fell above and half fell below) were derived by converting points on the scale of interest to numerical values (e.g., “Not at all Interested” = 1, “Slightly Interested = 2, and so forth) The mode (most frequent response) required no conversion.

Respondents showed that they are working in the present and thinking about their future. Information on final, coded designs was the hottest topic, but they also want to learn more about  in-progress designs. The survey also revealed that there is a lot of interest in learning about upcoming work. In future community meetings and other communications, we’ll continue sharing completed work, but also make a point to include our priorities and upcoming projects so that you can better plan your own work.

Starting with the most recent community meeting, the agenda has already had a makeover to support these findings. Agendas previously were organized by pattern and presenter, but going forward, topics will be organized into these categories so you can leave the call after you’ve heard what you want.  (But we’d love for you to stay the entire time!)

A new item on the agenda, beginning with the March community meeting, is providing time to discuss requirements that aren’t currently supported in PatternFly. This has already paid off; in general, there was a big improvement in dialog on this topic.

There was only a slight interest in site and social media metrics amongst respondents. For the core members, watching our proverbial baby grow into a full-fledged community project is a joyous event, so seeing site traffic spike after a conference is probably more fun for us than for the community at large. In the future, we won’t spend time on this topic in the meeting, except for the occasional point of particular interest. More detailed information will continue to be reported to the Red Hat UXD team.

Unsurprisingly, with the majority of respondents being designers, code reviews on the agenda wasn’t that popular. Reviewing code was never explicitly part of the community meeting, and the survey results suggest that was the right approach.

How’d you hear about us?

Fine-tuning the content of the meeting and communications is an important task. But, the most interesting and relevant content in the world is only useful if it can be easily found and consumed by the intended readers. To that end, we wanted to make sure we were in touch with community members’ preferences about where they obtain their PatternFly information.


These two questions seem very similar, but actually approach the query from different angles.  The former asks the respondent about the information source he or she uses the most, indicating that the selection is his or her preferred source. The latter question let respondents select multiple information sources, which lets us see whether and how much all our information sources are being used. The amalgam of these responses shows us that we should focus our reporting efforts on the web site and the mailing list. Not much love was shown for social media; sorry Twitter!


Contributors work hard and are eager for designers and developers to consume the fruits of their labors, so it’s great to see that respondents reported being satisfied with how they learn about the previous month’s work. But, there is always room for improvement, so if there is a way we can make this content even better, we would love to hear your thoughts in the comments.

When is a good time for you?

With community members from all corners of the globe, it’s gratifying to see that something as difficult as the meeting schedule generally meets respondents’ needs.


If you’d like to participate in PatternFly and can’t attend during that time slot (10 a.m. EST every 4 weeks starting with April 20, 2016), don’t despair!  All community meetings are recorded and posted to


While a third of the respondents indicated that they’re unlikely to watch the recorded video if they were unable to attend, half responded that there would be a 50% chance that they would. While we will make the recorded video available even if interest was very low, it’s good to hear that some people are probably catching up on what they missed.

Where do we go from here?

If you’ve been a regular attendee of the community meeting or are a long-term PatternFly community member, you’ll see changes being rolled in over the next couple of months. If you’re new to PatternFly, what a great time to join!  The content and messaging you encounter will be fresher and more on-point than ever.

If you missed the survey the first time around, we’d still love to hear from you. Let us know your thoughts in the comments below.

Many thanks to my co-contributors on this article – Leslie Hinson and Patrick Cox.

Posted by & filed under Communication.

This is a final blog post in an initial series about Labels. It is a follow-up to: “Let’s talk about Labels” posted on January 27, 2016, and “Let’s talk more about Labels” posted on February 29, 2016. The prior blog posts addressed topics around creating and applying user generated labels to managed resources. In this final post we’ll discuss how to remove or delete existing labels.

Note: This story does not attempt to address a label management center, where a user might take action on an inventory of labels. It is geared to use cases for managing user generated labels from resource views.


Creating a label recap, a user-generated label is:

  • A “Key:Value” pair (KVP.)
  • Created in the UI using a pair of text input fields.
  • Added to a stored list of labels, once created.
  • Used to support rich search and filter options.
    To read more about the Create action, see: “Let’s talk about Labels.”

Applying a label recap, a label is applied:

  • When a resource or alert is associated with a pre-existing label.
  • Using the same form input elements that are used in creating a label.
  • In a variety of screen contexts, including: Tables, lists, cards, and inline actions.
    To read more about the Apply action, see: “Let’s talk more about Labels

This pattern includes conceptual designs for the following actions:

  • Remove
    Remove the association between a label and the resource it had been applied to.
  • Delete
    Delete breaks the association between label and resource, and purges the label(s) from the master list of stored labels.

The Proposal

Remove a Label

Users may want to remove a label when they no longer need to identify a resource with a particular category or value. Removing a label breaks the association between a label and the resource that it had previously been applied to. It is the paired opposite action to “Apply.” Removing a label does not delete the label from a stored list of labels; it remains available to be applied to resources.

Labels may be removed as a singular or bulk action.

A) Single (inline)

B) Bulk (content view)

A) Removing a label from a single resource, as an inline action.

Applied labels for an individual resource might be presented in a list or iconic view. For more information about Applied Labels see: Let’s talk more about Labels

Example: Listed

Example of applied labels, listed (visual design TBD):
Applied, listed, Labels.

Example: Iconic view

1. Labels within a pop-over may also be removed inline.

Removing one Label:

  • Use the “x”  inline action to remove the applied label from the individual resource.
  • Provide a hover tip on the “x” to confirm that the action is to “Remove.”
  • For an individual label, the remove action will occur dynamically, without requiring the user to confirm the action.
  • Consider adding an inline or toast notification to confirm that the action was taken successfully. For more information about notifications see:

Removing all labels:

  • Provide a “Remove All” action-link, to allow the user to remove all labels (optional).
  • Provide a hover tip to confirm that the action is to “Remove All.”
  • Ask the user to confirm the action restating the selected resource(s) and the associated labels to be cleared.

B) Removing a label (or labels) from multiple resources, as a bulk action.

The assumption is that this action will be taken from a Content View screen, where multi select checkboxes are afforded. For more information about Content Views, see:

Identify and select the resources with the associated labels.
Locate the resources which have the Labels that need to be removed. The user may use Sort, Find or Filter actions in the Data toolbar to locate resources with the applied label. For more information about the Data Toolbar, in Content Views, see:

Select the action to “Remove.”
After selecting resources, the user may take the action to remove the label(s). All content views generally use the same interaction affordances for initiating actions: buttons or kabab dropdown menus. The affordances might be presented in the data toolbar, or inline within rows (table, list or card.)

  1. Theses actions are presented in the data toolbar, when multi-select checkboxes are offered. The data toolbar is placed above the list view. When combined with checkbox selection in a list, it supports multiple selection. For more information about the Data Toolbar, in Content Views, see:

Example: Data toolbar

An action button or kabob drop down menu item should be offered to allow the user to initiate the action. The action should be named “Remove Labels.” For additional terminology recommendations, see:

Example: Kabob menu

Screen Shot 2016-03-21 at 10.22.57 AM
Example: Button (“Remove”.)
Screen Shot 2016-03-21 at 11.17.48 AM

After the user makes the selection a Modal dialog is presented.


The dialog should list the resources and present labels that may be removed from the resources. If the user selects a label that has only been applied to a subset of a group of selected resources, the label will be removed from that subset.

Labels will be removed after the modal is submitted. The content view screen should update to reflect the change.

Consider adding an inline or toast notification to confirm that the action was taken successfully. For more information about notifications see:

Delete a Label

Note: The anticipated use case for deleting a label is a well-planned action take by an admin, or a user with appropriate permissions, as part of a management task. This use case will most likely require a section of the UI dedicated to label management, which is outside the scope of this story. The following is an interim, resource-centric alternative.

Deleting a label is destructive action. Labels that are deleted are purged from the stored list of labels. It is the paired opposite action to “Create.”

To delete a label a user may first identify the resources that use the label, then submit the delete action. The assumption is that this action will be taken from a Content View screen. For more information about Content Views, see:

Use search, find, or filter actions in the Data toolbar to locate resources with the applied label.


Once resources are selected, the user may take the action to delete labels. From the content view a “Delete” button or kabob drop down menu item should be offered to allow the user to initiate the “Delete” action. The action could be taken from the Data Toolbar or as an inline list action, depending on whether or not multi-select is supported.

Provide a “Delete” action using either the kebob or button actions.

Example: Kabob menu

Screen Shot 2016-03-21 at 10.22.57 AM

Example: Button (“Delete”.)
Screen Shot 2016-03-21 at 10.23.28 AM

Important: Delete is a destructive action, do use a red button for this action. For more information about buttons, see: The action should be named “Delete Labels.” For additional terminology recommendations, see:

After the user makes the selection a Modal dialog is presented.


The modal allows the user to select the labels and informs them that it is a destructive action. It should list the labels that can be selected, and the affected resources. Delete might apply to resources other than those initially selected. The ramifications of deleting a label could be disruptive to the overall system and users, therefore the user must be presented with a warning message. After confirming the action, the labels will get unassigned from the resource(s) and purged from the system. The content view screens should update to reflect the change.

Open Issues

  • The “Delete”, and to some degree “Create”, actions were identified as actions that might be taken by a user who would be defining a labeling taxonomy (administrator.) These actions would most likely be taken from a label inventory view, rather than a resource view. Label inventory views are out of scope, as the current stories were initially defined based on product requirements with resource-centric views. These use cases were also relatively agnostic of user permission settings.

What’s not covered in the current design but will be considered in future sprints

  • Management of an inventory of labels.
  • Nesting Labels.
  • RBAC & Labels.
  • INIT & Labels.
  • Filtering resources by Labels.
  • Search for and by Labels.
  • System generated Labels.

Posted by & filed under Data Visualization.


A “Single Area Chart” is used to provide metrics for a single data set. While similar to a line chart, in both form and function, it offers an area fill for visual emphasis. The area fill below the line also functions to indicate cumulative data.

  • The most common use case for area charts is to show trending over a continuous scale (usually time.)
  • Use this instead of a line chart when you need to provide more visual emphasis than a simple line chart would offer. For more information about line charts, see:

The Proposal

Note: The Area chart design and implementation is already available in PatternFly. The intent of this blog post is to discuss and present usage guidelines for the existing design. See:


Area Chart

1) Chart Title

  • Provide a title that describes the chart.

2) Data Line

  • A solid line is used at the top of the area chart to show a total value.
  • Use straight lines (linear interpolation), if it’s important to display more precise data values.

3) Interactive Data Points

  • Specific data points may be represented by dots on the line portion of the area chart.
  • To help the user see which point they are hovering over, the dot expands and a vertical line is displayed.
  • Present a tooltip providing associated values for that specific data point.

4) Data Area Fill

5) Chart Lines

  • Axis lines:
      • The “x” axis is commonly used for time values, and the “y” axis is used for metric values.
      • Use consistent spacing for the axis line label intervals and tick marks.
      • Tick marks are optional.   
  • Grid lines:
      • Horizontal grid lines (Recommended): The lines help users associate a point in the chart with a value on the axis.
      • Vertical Grid lines (Optional): While helpful, in some contexts they might create visual noise.

Legend (Optional) * For an example, see:

  • A legend associates the data set with a color mapping.
  • The legend may be used to provide detailed information about the data set.
  • Position the legend below, or to the right of the chart.

Open Issues

  • Line smoothing: Is the line interpolation configurable?

What’s not covered in the current design but will be considered in future sprints:

  • Multi-line area chart (“Area Chart”)
  • Stacked area charts.
  • Representing breaks in data within the chart.
  • Customization for line interpolation.

Posted by & filed under Communication.


Time specific content (such as events, tasks, alerts) require a delivery system that is actionable, independent, accessible and immediately available that does not expressly interfere with primary content and functionality.




Initial Logged In Screen

An Event/Task Drawer that is accessible via a notification icon in the header nav on the right side. Toast notifications (parameters set by individual applications) also alerts the user to new events. Interaction with the toast notification would launch the drawer. Investigation into an appropriate icon for the header nav would be prudent. Certain applications may have an abundant number of notifications, where as a icon with new event number may be inefficient

Header nav icon and toast notification.

Header nav icon and toast notification.

Expanded Event/Task Tray

Interaction with task/event drawer tabs open up their prospective rows (accordian) with only one tab open at any given time maximizing space for content. The ability for the user to control the amount of content in any tab with a Load More (infinite scroll) pattern reduces the need to define any specific time frame for the tabs content. Other solutions I encountered, gave specific time ranges for the rows displayed (e.g. “last 12 hours”, “last 24 hours”). That said, if a user were to login after that time range they may miss out on pertinent events.

New events should appear bolded where as old event would not be.

Mark All Read functionality is available for use cases in which the events are redundant to the user or easily dismissible.

Through the kebab pattern each row has a slide out action menu to allow for quick/easy individualized actions.

Event/Task Tray Row Interaction and Destination

Clicking on any particular row (2)  will push the drawer our further with the rows content/details overtaking the initial drawer nav.This solution is self contained, saves on space and negates the need to go to a new page or section within the application. A back button in the header area will return the tray to its previous state.

The header also has a title area so the user can correlate this new content area with the row that was clicked on.

The content area would vary upon independent needs of the application.



Event/Task Tray Tab Interaction and Destination

Clicking on any Tab chevron (3) will, again, slide the drawer out with content being replaced with a more detailed list of the events in the initial tray. This is accompanied by an area to house search functionality and an additional row that can house filtering options.

The same kabob row action is available, as well as a back button returning the drawer to it’s previous state.


Screen Shot 2016-03-10 at 9.25.28 AM



  • Slide Out/Content Replace pattern may be used as a tertiary nav solution for Patternfly. Duplicating this type of interaction would show consistancy.
  • Content areas/search/toast notifications would be personalized per it’s use/application.

Posted by & filed under Data Visualization.

This blog addresses the initial design for zooming in and out of a time series chart.  The horizontal axis of a time series chart represents a timeline.  The user may be able to change the timeframe of the chart by:

1. selecting an existing time period

2. entering a custom  time period

3. zooming in/out based on current filter options

4. zooming interactively with an optional navigation chart

Interactively zooming with the main chart will not be covered with this round of design.


The Proposal

1. Selecting an existing time period


From a PatternFly perspective, we already have a pattern associated with setting the time frame filter on a dashboard card.  The proposal is to remain consistent with this design, thus placing a time frame filter drop down (A) on the top right side of the chart.  The items in the list should be ordered from the smallest to largest time frame.

When multiple charts exist on the same page, a single time frame filter component would be displayed and will affect all associated charts.

At this point, we are not suggesting a list of time periods to be included, since the time periods will differ based on the data being displayed.

2. Entering a custom time period


Optionally allow the user to enter a custom time period (B) in the time frame filter component.

The user should be able to set a custom time period.  In this case, the proposal is to have a “Custom” button following the time frame filter drop down.  Upon selecting the custom button, the user should be prompted to select a time frame by selecting a start and end date with the date picker.  This custom value will be added to the drop down as the first item and selected.

3. Zooming in/out based on time frame

Optionally including zoom in/out buttons ( C ) in the time frame filter component.  

These buttons are included to allow the user to quickly change the time filter with a single click.  The zoom in (+) button will change the selection in the drop down (A) to be the previous item in the list.  When the first item in the list is selected, the (+) button should be disabled.

The zoom out (-) button will change the selection in the drop down (A) to be the next item in the list.  When the last item in the list is selected, the (-) button should be disabled.

4. Zooming interactively with an optional navigation chart

Optionally provide the ability to interactively zoom with the chart via a smaller navigation chart below the main chart.  There are many useful interactions with the smaller navigation chart:

Drag it left / right to scroll through the data on the main chart

Click and drag the left and right edges to increase / decrease the amount of data shown

Click off it to get rid of it, and so show the full data set in the main chart

Click off it and drag to create a new box

Any zooming interactions with the chart will cause a custom time period to be added to the drop down list in the time frame filter component.

When multiple charts exist on the same page, a single optional navigation chart is displayed under the bottom chart and will affect all associated charts.

See a live example of the D3 brush functionality here.

Screen Shot 2016-02-29 at 10.39.53 PM
Your Feedback

We are specifically interested in finding out your thoughts on the proposals we have mentioned above.  Please leave comments in the blog about how you would expect to zoom into a time series chart as well as any other comments that you might have about the current direction.

Posted by & filed under Communication.

This blog post is a follow-up to: “Let’s talk about Labels” posted on January 27, 2016. In that post we discussed the topic of creating a user generated label, for a managed resource. In this post we’ll discuss how to apply a new or existing label.

Creating a label recap, a label is:

  • A “Key:Value” pair (KVP.)
  • Created in the UI using a pair of text input fields.
  • Added to a stored list of labels, once created.
  • Used to support rich search and filter options.

Selecting a label to apply

The same form inputs used to create a new label are used to select an existing label. Existing labels are presented within a drop-down list. Type-ahead functionality shows the list of existing values. A label may be created and applied as a single action, or as discrete actions.


1. The user can filter a list of existing labels, using type-ahead, to make a label selection.

Application use cases might warrant creating and applying a label as a single action. In this case, the user could select a preexisting label or enter a new one in the input field.

Selecting an object

To apply a label users must associate a label with an object (such as a resource or an alert.) To do this, they need to first select an object, objects, or an object set, by:

  • A. Selecting objects from a list of objects, in a content view.
  • B. Isolating an object, or object set, through navigation, filtering, or searching.

A. Selecting an object, then applying the label.

Objects selected from a content view (Table, List, or Card view) list, generally use buttons or kabob drop down menus to initiate an action. After the user makes the selection a Modal dialog is presented which allows the user to apply a pre-existing label, or create and apply a new one. The action is named “Apply” if the action is to apply an existing or new label. For additional terminology recommendations, see:



The label actions may be included in a table, similar to any other viable action. For general information about tables, see:

1.  Offer the label action either through a button, or an action within the kabob drop menu , when checkboxes are presented in the table. Otherwise use the row action button or kabob.


Labels actions may be presented as a list view action. For general information about lists see:


(1) Use the data toolbar actions button or kabob drop menu, when checkboxes are presented.


(1) If no checkbox selection is offered,  use the row action button or kabob.


Design in progress, see:

Labels actions may be offered in a card view using similar affordances as those used in List and Table.


(1) Use the data toolbar actions button or kabob drop menu, when checkboxes are offered.
(2) If no checkbox selection is offered,  use the inline action buttons or kabob provided on the card.

Submitting the Apply action

From a Table, List or Card view, when the user selects the label action a modal dialog will be presented. The dialog includes the label selection input fields. Selected labels are applied when saved.

  • A modal dialog is spawned from the corresponding action button, or menu, selections.
  • Input fields allow users to select Label values to enter or select KVP’s.
  • Labels that already exist will be filtered by the characters that the user enters in the input box.
  • If the application allows, the user may also enter new label values where none exist.
  • For details about form input behavior, see: “Let’s talk about Labels”


For general information about the PatternFly modal, see:

B. Navigating to an object, then applying a label.

To apply a label, rather than explicitly selecting an object it is also possible to isolate a particular object or object set. When a user navigates or filters to an object they have implicitly selected that object.  Actions applied from these detailed views will be applied to that particular object or object set.

Inline form fields

Label fields may be presented as inline form elements, within a larger form. Inline form fields could also be used for editable content views, such as a Details screen.

In a form that uses page-level, form submit buttons.


In screens where dynamic, inline actions are used. For example, a editable Details screen where you might want to offer some inline form elements.


Inline action-link

An inline “action-link” can be used for “ad-hoc” label creation. It consists of an icon and linked text. When the user clicks on the action-link a pop-over menu will be presented. To learn more about pop-overs, see:

  • Use when other object-selection options (tables, lists, etc.) are not suitable.
  • Use in areas where screen space is constrained.


Inline action link, presented in a Dashboard Card. Clicking the link launches a pop-over dialog with form inputs.

Dashboard Card –

The Applied Label

Once a label has been applied it should be represented in the UI in the same screen context, so the user has confirmation that the action was taken. Depending on the context it could be presented as a list of applied labels, or as an iconic shortcut representation. Present applied labels as a list when horizontal screen space supports it.

Listed Examples

If space is constrained use an expand collapse panel to hide/show up to three rows of labels. Provide a text link to engage the expand/collapse action. If possible, specify the number of remaining labels that are hidden from view.

If there’s more than three rows of labels, use a jump link to move the user to the bottom of the screen where the full list of labels can be presented. Presenting the full list at the bottom of the screen allows screen content to be prominent.

* Note: Visual design pending.

Screen Shot 2016-02-29 at 11.00.03 AM

Iconic Shortcut Example

  • When space is extremely constrained, an icon may be used to indicate that labels have been applied.
  • List the applied labels, vertically, in a pop-over.


Open Issues

  • Using the Label form fields: Could the user skip the key field and use only the value to identify an existing label?
  • The card view design is not available yet, this post includes an example of a pending design.

Posted by & filed under Cards.


Card View displays content in a graphical way that is not possible with a Table or List View. The characteristics of this view can be used to tuck actions out of the way until they are needed, or to place emphasis on actions that are crucial to the correct use of the product.

The Proposal

This design follows the convention set by the toolbar actions pattern and breaks actions into two categories depending on importance and frequency of use.

Actions front and center

actions on a card 1

  1. If a card has one or two actions that are important to the utility of the object. They may be placed as buttons on the card itself.
  2. Optionally, a single action may be emphasized as the primary action. If showing action buttons does not leave enough space on the card for other information, consider transferring nonessential actions into a drop-down menu.

Actions in a drop-down

actions on a card 2

  1. Actions that are not used frequently are placed in the kebab (vertical ellipse) menu. This menu can be found on the top right corner of the card and becomes visible on hover. Any actions that can be performed by dragging and dropping the card, or through a similar interaction method, should also be duplicated as items in this menu.  Very large numbers of actions should be placed in the Actions section of the Toolbar rather than on the card.

Open issue

  • Is there a reason for buttons to contain a group or category of actions rather than just a single action?

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!


Posted by & filed under Communication.

This blog post explores introductory concepts and investigations around the use of Labels in managed systems. It focuses principally on the topic of label creation. One of the goals of this blog post is to surface additional requirements and areas of concern. Known “Open Issues” are listed at the end of the document. Please leave comments with any questions or suggestions that you might have, thank you!


A label is user-defined text that is associated with a managed resource. Labels support richer search and filter options. They are not intended to be unique identifiers, like resource ID’s. Many resources can, and often do, have the same labels applied to them.

Labels enable users to identify and associate resources according to their own model, rather than that of the organization or the semantics of a system. In non-hierarchical systems, labels are a particularly useful tool. They allow users to make associations among resources where explicit object associations might not exist.

  • Use case example:
    A user needs to label resources, that are located in different physical locations, in order to manage maintenance work across these locations. The user creates or selects labels and applies them to the resources. They can then filter by label to the specific servers that they need to manage.

Conceptual Design

The label is a text string, formatted as a key-value pair (KVP). It is presented in the UI as a “key name” preceding a colon separator, followed by a “value” text string after the colon. The use of a colon as a delimiter should be configurable, by the software, to support other technologies.

  • Example:

There is no requirement to represent a hierarchy or an ordered pairing. The text string could be seemingly arbitrary.

  • Example:
    Fish:Dog = Valid entry

Although whether the text is assigned to a “key name” or a “value” does matter.

  • Example:
    “Dog:Fish” is not equivalent to “Fish:Dog”

Labels that share the same key name may implicitly or explicitly form an association. Using a consistent set of key names makes it easier to identify and manage resources. The onus is on the user to create a consistent set of labels to best support their work-flow and resource types.

  • Examples:


Label Syntax Requirements

  • Each label must include a key-value pair delimited by “:”.
  • Labels are case sensitive.
  • Spaces are allowed.
  • Must begin and end with an alphanumeric character.
  • Special characters may be used, provided they are not used at the beginning or end of the label values.

Label Interactions

This initial pattern addresses the action of “Create.” It is intended to be one of a set of actions that will be covered in future patterns, which include:

  • Create/Delete
    Creating a label means adding the label to a stored list of labels. Delete would purge the label from the stored list of labels.
  • Apply/ Remove
    Applying a label means associating that label with a given resource. Removing a label entails removing the association with a resource, but does not purge the label from the stored list of available labels.

Create: Labels are created by entering the KVP text strings into form input boxes. One input box is used for each member of the pair. A read-only colon separates the two input boxes. Every effort should be made to ensure that these input boxes align on the same horizontal line.


1) Creating a new Label.
New Mockup 1


2) Using an existing key name and  creating a new value.

Previously created labels appear in a drop-down selection list, within the “create” labels form fields. A drop-down list is presented when a user types-in values which match an existing label. This “type-ahead” functionality is similar to:


New Mockup 1 copy 4


3) Supporting the creation of multiple labels
Users may create more than one label at a time, by clicking a “+” icon button to the right of the form fields. Clicking this button will add a new pair of empty inputs. Alternatively users may clear a label before submitting by clicking the “x” icon button to the right of the form fields.
New Mockup 1 copy


Submitting the form creates the label. Placement and terminology for the form submit buttons depends on the context in which the labels form elements are placed. The “Create” inputs could be used in a variety of contexts: Modal Dialogs, Wizards, Pop-up dialog, within another form and etc. Presentation details will be expanded when work around the other Labels actions, particularly “Apply,” commences.

In the interim, if the create-label action is a stand-alone form then the recommendation is to use generic Cancel/Save button labels wherever possible. If it is necessary to use a specific action label, refer to “Terminology and Wording for Action Labels” for more details:

Questions/Open Issues

  • Question: Our rationale for using the term Label rather than Tag is due to the semantics of a name:value pairing. Does this resonate with others?
  • Open Issue:  Is the label “Value” a required field, or just the “Key Name? Different technologies/products seems to enforce different requirements.
  • Open Issue:  Should it be possible to “Create” a label without having to “Apply” it to a resource?
  • Open Issue:  If Delete purges the label throughout –  in a multi-user application, how do I know if others are using the label so that I don’t get a purge/cascade effect?
  • Open Issue: Additional syntax requirements:
    • * Maximum number of labels?
    • * Maximum key length—127 Unicode characters in UTF-8?
    • * Maximum value length—255 Unicode characters in UTF-8?
    • * Any reserved keys that can’t be used.
    • * Are labels specific to a user or a global-wide per resource?
  • Open Issue: Where does one go to manage all the labels (see the full list)?

Posted by & filed under Navigation.

This blog post addresses the initial concepts and approaches for the drill-down, from the list, card and table view. Please leave comments with any questions or suggestions you may have!



Drill down is used to help the user navigate from a landing page to a details page. A typical landing page may have data that is shown in different content views, such as list view, card view, and table view. Therefore, each content view should support the drill down so that the user can navigate to the details page of the selected item from any view.


Conceptual Design

Landing page in list view:

list view



Landing page in card view:

tile view



Landing page in table view:

table view 2



Details page:

detail page with page title



Details page with tabs:

detail page




  • List view item: Clicking on a row in the list view will direct the user to the details page of the selected item.
  • Card view item: Clicking on a card in the card view will direct the user to the details page of the selected item.
  • Table view item: Clicking on a row in the table view will direct the user to the details page of the selected item.
  • Details page: Provide the detailed information about the selected item.
    • Breadcrumb: Provide context and inform users of their current location. Breadcrumbs are also a means for users to navigate back to the landing page.
    • Page title: The page title provides further reinforcement to the user about which item was selected.
    • Tabs (optional): The details page may have tabs, if the details can’t be fit into one page. To better save the vertical screen real estate, we recommend removing the page title when tabs are used at the top of the screen.


Open questions:

  1. Would you prefer using the standard breadcrumb shown in the conceptual design, or using a visually more prominent breadcrumb? Please see the alternative design of breadcrumb below. Note that this is just an exploration. The design and usage guidelines of breadcrumb is not within the scope of the Drill Down pattern and it will not be presented in the final design.

Details page with more prominent breadcrumb:

detail page with tabs 2



The user can also access the details of another item easily, without having to go back to the landing page:

detail page with tabs 2 and dropdown

  1. Would you prefer having a View button on list view item or card view item? Also, how do you like the idea of making the item name clickable? (see examples belowlist item variations