Overview

There are many things the Forms Pattern does not specify today. During the discovery phase, we captured requirements (see list below) from various stakeholder projects. One of the top requirements was for a feature to “Hide/Expand Advanced Options” in the form.

With the collection of discovery work screenshots and some other popular option about “Hide/Expand Advanced Options”. I created four demos to do some Usability testing.
The test mockup link: https://invis.io/EY87CTCF9#/179595570_Demo1-1 (Please try the mockup and leave your comments in Invison demo freely.)

Demo1

Shows the “Advanced Options” button with a blue link color which helps the user to focus on it and know it can be click;The “arrow” icon indicates to the user that it can expand.
The arrow icon changes when with user clicks
The divider line appears on expand to divide the two different options

Demo 2

“+” indicated that there is more information;
Click the “+” icon to expand and the “-” icon to collapse

Demo 3

Use word “Show” and “Hide” to show Advanced Options

Demo 4

Similar with the demos before, put the advanced options button in the middle of the form.

Which demo feels better to do the “Hide/Expand Advanced Options” ?

If you have any other good suggestion, feel free to leave comments in the blog. Thank you~

Recently, the PatternFly team undertook a brief research study to help decide how to handle scrolling within modal dialogs that have more content than can fit within the current view or “above the fold.” In this post, you’ll read about what we were trying to learn, how we constructed the study, and our final conclusions.

What were we trying to learn?

When there is too much content in a modal dialog, how do you expect to find the additional information? Would you expect the buttons to always be visible and what scrolls is a small frame of content? Would you expect to scroll the entire modal dialog to see the buttons at the bottom? Bootstrap, which PatternFly is based on, uses the latter design by default. Before we recommended one style over another, we wanted to see if there was a user-based need to deviate from the Bootstrap default.

Ultimately, the question we wanted to answer was: “For modal dialogs, which scrolling style should we recommend (and document and build out) in PatternFly?”

How we recreated the issue at hand

To turn this study around quickly, we looked to the Red Hat body of design work to find inspiration that we could riff on. Study participants worked with a live-code prototype that was a derivation of a screen already developed for the Red Hat Cloud Infrastructure installation wizard, which saved us a bunch of time. During the sessions, participants were asked to select the nodes to use for a deployment (in this case, Red Hat OpenStack) and resolve any errors. Once the minimum number of nodes was selected and all errors were cleared up, the Deploy button became enabled and the user could proceed.

Two versions of the prototype were created: one where the entire modal scrolls and the other where the buttons remain in a fixed place and just the content scrolls. Because participants would see and work with both versions of the prototype, to reduce first-impression bias, moderators alternated which version participants saw first.

Version A: the entire modal scrolls

Version B: just a small frame of content scrolls

When a participant selects a node that has multiple interfaces, a message appears indicating that there is an additional step. This message appears below the selected node and shifts the remainder of the list down the page. We included this type of interaction to see if participants would react to some of the nodes “disappearing,” essentially forcing them to scroll, even if, to this point, they weren’t aware they needed to.

This selected node has multiple network interfaces, and one must be selected before proceeding

How the sessions were conducted

Participants were instructed to select a number of nodes for their deployment. Some of the nodes they needed to select showed the message reminding them to select a network interface as well and some nodes were lower on the modal dialog and out of view. To ensure that participants had to scroll at least a little bit, we raised the minimum number of nodes and instructed them to select some that were “below the fold.”

Session moderators were given a list of prompting questions and things to look out for as the participant worked through the task. Those included:

Did the participant have any reaction to a row disappearing below the fold when an error message appeared?

Was it obvious how to find the other nodes?

Did the participant have any problems with scrolling?

Does the participant correctly identify that the Deploy button becoming enabled as having completed everything they need to?

After the participants have worked with both versions, the moderators asked these questions:

How difficult or easy was it to complete this task? The rating scale ranged from 1 (very difficult) to 7 (very easy).

Which type of scrolling have you seen in the tools you use daily?

Which version was easier?

Which did you prefer?

Do they have any commentary/preference regarding the order of the Cancel and Deploy buttons? (We threw this in to see if we could gain any insight on the eternal discussion of whether the OK button should go on the left or the right of the Cancel button.)

What we found out

Overall, participants did not have problems using either version. Only 5% of participants had a reaction to a row disappearing below the fold in either version. No participants had errors finding other nodes, 5% of participants had an error while scrolling on the whole modal scroll (version A), and 5% of participants had an error identifying when the task was complete using either modal version.

Participants rated both modal versions as easy to use and nearly equally easy to use. The whole modal scroll (version A) was rated 5.8 on a 7-point ease of use scale whereas the sticky button modal scroll (version B) was rated 5.9. The low error rate and high and similar ease of use ratings show that it is very unlikely that users will encounter usability issues for either modal that would negatively impact their use of the widget.

When asked for their preference between the two modal versions, participants were split completely down the middle. Slightly more participants rated the whole modal scroll (version A) as easier to use, 45% versus 31%. The remaining participants rated both versions equally easy to use. Most participants did not recall which style modal they were more used to seeing, although of the participants who did, slightly more were familiar with the sticky button modal scroll (version B). There was no evidence of a first impression bias when participants stated which modal version they preferred or which was easier. Additionally, 90% of participants were unable to determine the difference between the two modal versions without prompting from the researcher.

These low error rates, nearly equal ratings, and lack of initial distinction upon seeing the two modal versions imply that participants did not have a strong preference for one modal over the other nor would one version introduce any usability concerns. Since our quantitative analysis didn’t indicate a clear modal version to recommend for PatternFly, we looked to the comments we collected during the testing. Participants tended to talk about the whole modal scroll (version A) more positively, specifically about the fact that more content was visible on the page at one time. Most participants liked the idea of having sticky buttons but some felt it made the content feel too cramped.

And the winner is…

This one is as close to a coin toss as you can get. The two modal versions tested in this study were nearly equal in all aspects. The whole modal scroll (version A) has a slight edge in the comments and poses no usability concerns. For these reasons, we recommend that PatternFly adopts the default Bootstrap default modal style, the whole modal scroll.

The scrolling method is only one factor when deciding how to handle this situation in your own design work. You should also consider the size of the devices that you expect your users to view the UI on and how much data will be shown within the modal. Have you run into this situation before? How did you handle it? Let us know your thoughts in the comments.

The Widgets page is one of the most visited on PatternFly.org. What do visitors expect to find in the Widgets page? Do they get what they need there? And what is a Widget, anyway? I spoke with five PatternFly users to get their thoughts on this topic, and also ran a survey (we got 12 responses). Thanks to everyone who participated in this effort!

The Data

Visitor opinions varied quite a bit on a number of topics. As a key example, exactly half the respondents believed that Widgets were the same thing as Components, whereas the other half did not agree. But why, exactly?

When I broke down the responses by discipline, I was able to see some patterns emerge. The following chart shows the same data, further broken down by discipline.

The way a person responded to the statement “Widgets are the same thing as Components” roughly corresponds with what they do in their job. The terms “Widget” and “Component” are clearly distinct concepts to a developer, but not so much to a designer.

Defining “Widget”

Let’s dig in a bit more to how people define Widgets. First, here is what interviewees said about widgets:

“I think of widgets as small things you can interact with. For example a dropdown [menu] is a widget that can be put into something larger, like a table pattern.”

“[A widget is] an independent bit of code that can be used anywhere in the UI in different sorts of layouts, in different sorts of patterns.”

“I see widgets as low-level, with no guidance as far as when you should use one widget versus another.”

This matches up pretty well to the survey results. Respondents tended to agree with the statement that “Widgets are the basic building blocks I can arrange on a screen.”

According to interaction Designers surveyed, Widgets are always small. However, developers mostly disagreed with this statement:

Developers tend to be more concerned with functionality over form. Technically speaking, the overall size is not integral to the Widget; it’s actually an easily changed parameter. You could even say it’s arbitrary. However, when it comes to visual design, every pixel matters. Changing the size of an element completely changes the visual balance. Thus, classifying elements by size would make more sense in the field of Visual Design, and I believe that Widgets are a used here as a convenient term to indicate small elements. And Widgets do tend to be small, in reality.

And finally, Interaction Designers fall in the middle between form and function. They see both sides, and need to consider both of these perspectives at different times.

How do Widgets relate to Patterns?

Now that we have a better picture of how people define Widgets, let’s look at how those same folks relate to Patterns. Here is a statement that really resonated with respondents: “Patterns are multiple widgets, used together.”

Interestingly, Components seem to have almost exactly the relationship to Patterns as Widgets do, according to respondents:

As only half of visitors agreed that Widgets and Components were the same thing, how does this result make sense? Widgets and Components do have a few key things in common: both are seen as tangible elements and both can be used as pieces of larger elements. So, regardless of what exactly Widgets and Components are, they do seem to relate to Patterns in the same way.

Defining “Pattern”

Let’s take a look at how people define the term “Pattern”.

Respondents said that patterns are:

“Industry-tested, customer-tested, UX-Designer-tested ways of doing things; kind of best-practices for using widgets.”

“How you should build applications that [work] towards [a] goal.”

“UX; How things look and how they should operate.”

These statements emphasize the guidance that patterns provide. So then the question becomes: are patterns purely guidance or are they also tangible elements that you can use directly in an application?

Designers mostly agreed that patterns could be used directly in an app, whereas developers were a bit more split on this (3 of the 5 developers disagreed with the statement). This is an interesting result, as Patterns in PatternFly do, in fact, provide example code. Where is this discrepancy coming from? I believe that these developers generally see Patterns with code as “Components.” In the following categorization exercise, you’ll see that developers do tend to categorize items as “Components” that designers tend to categorize as “Patterns”. What’s interesting here is that this implies that developers navigate the Pattern Library in PatternFly.org to find the things they know as “Components.”

Categorization Exercise

As a final task in the survey, I had respondents categorize a selection of elements into the categories of Pattern, Widget, Component, or Layout. Here’s how they categorized these items, broken down by respondents’ primary discipline.

As you can see in the charts, people generally tended to gravitate towards the term “Component” more than “Widget” — developers did this more so than designers. Developers also tended to use the term “Pattern” less than designers, as can be most clearly seen when looking at the categorization of “Dashboard Card” and “Table.”

Analysis: On Accommodating Developers and Designers

Design frameworks such as PatternFly exist at the intersection between the design and development disciplines. The terms and concepts we use in PatternFly are a mashup of terms and concepts from both disciplines. Occasionally, the subtle differences in the meaning of terms between these disciplines can cause confusion. The site design ultimately has to accommodate both perspectives and approaches, directing both designers and developers to the content they are looking for.

Developers tend to define the tangible elements used to build applications as “Components.” In other words, if an element is not abstract, there’s a better chance a developer will classify it as as a Component, rather than a Widget or Pattern. Components can be large or small, complex or relatively simple (anything above the level of basic HTML tags). To developers, the term “Widget” is more narrowly defined than “Component,” and is a less accurate term for the elements that we provide. Finally, developers understand UI Design Patterns at the level of guidance or best practices in UI design.

Designers, on the other hand, have no preference whether something is a Widget or a Component. Widgets are generally understood by designers to be the basic building blocks. To designers, the line between Patterns and Widgets is a matter of scope; Patterns tend to be composite elements, built out of multiple smaller elements. If you look at the sorting exercise, the elements that designers categorized as Patterns were Dashboard Cards, Tables, and Master-Detail, which are all composite elements.

In PatternFly, Patterns tend to get a greater focus than Widgets. To designers, the solutions provided in Patterns are of greater value than individual Widgets, because the choice of Widgets are already built in to the larger solution. Being able to simply choose a proven solution to a problem is a big win for a designer. Patterns are a tool to help make large design decisions quickly and with confidence.

Design Recommendations

We need to take another look at how we classify elements in PatternFly. As you may recall from the survey results, respondents overwhelmingly viewed “Bar Chart” and “Datepicker” as either Widgets or Components instead of Patterns. Currently, we mix basic and composite elements in the Pattern Library, which is causing some confusion. We need to be more consistent about how we classify elements as Widgets or Patterns. It’s clear from the survey results that these categorization issues affects both designers and developers. As a general rule, the more basic (non-composite) elements should probably be in the Widgets section.

Why would “Datepicker” and other Widget-like elements be in the Pattern section? What makes them different from the other non-composite elements that we classify as Widgets? The answer is that these elements all provide design guidance.

In PatternFly.org, we have no solution or page template to deal with Widgets that have design guidance (like “Datepicker”), so they end up in the Pattern section. Instead, we should use the same template for the content that we have in the Pattern section for Widgets. Overall, this will help everyone. Developers will be able to find and get code in the same way for any element. We can handle Widgets that have design guidance in a prescribed and consistent way. And finally, a universal template makes it easier to move elements around, without needing to modify the content format. If we decide that something should be re-categorized, it becomes trivial to do.Thoughts or feedback? Let us know in the comments!

The PatternFly team is excited to announce the new PatternFly site. We’ve done a lot of work including research, design, and development to enhance the site. Much of the effort has been focused on improving the information architecture as well as making adjustments to cater to our two main personas, designers and developers.

What’s New?

Improved information architecture and navigation: We’ve updated the navigation design and reorganized content based on user feedback to improve findability. We’ve also included a Pattern Overview gallery for easy browsing.

New pattern page design: The updated pattern page design caters to PatternFly’s two main personas, a designer and a developer. By organizing content into two separate tabs, users can focus on their area of interest.

More content: The new site now features code for the Angular flavor of PatternFly. We’ve also refined the Get Started page to improve onboarding.

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.

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.

Drill-Down

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.

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

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.

Mega-Menu

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.

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

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.

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 PatternFly.org 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.

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.

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.

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.

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.)

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: https://www.patternfly.org/patterns/list-view/

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.

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

Overview

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.)