Overview

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.

Proposal

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.

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.

Considerations

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.

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.

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.

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.

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: https://www.patternfly.org/styles/terminology-and-wording/#action-labels

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.

Examples:
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: https://www.patternfly.org/widgets/#popover

Use when other object-selection options (tables, lists, etc.) are not suitable.

Use in areas where screen space is constrained.

Example

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

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.

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.

Overview

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

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.

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 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!

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!

Overview

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:
Name:Value

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:
stage:devstage:teststage:prod

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.

Wireframes

1) Creating a new Label.

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: https://twitter.github.io/typeahead.js/examples/

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.

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.

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!

Overview

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:

Landing page in card view:

Landing page in table view:

Details page:

Details page with tabs:

Description

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

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:

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

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 below

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.

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.

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?

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.

Lines

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

Interaction

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.

Legend

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

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:

A page called “Donut Chart” and expect to see all the use cases for a donut chart in one place.

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.

A page called “Donut Chart – Relationship of a Set of Values to a Whole” meaning each donut chart would have its own page.

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.

Example:

Description:

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.

Total value: The total value is shown in the middle of the donut chart.

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.

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

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

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:

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.

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:

The hover area should be made a bit larger than the menu itself to minimize the risk that users will accidentally dismiss it.

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.