Posted by & filed under Navigation.


We need a responsive design for tabs to handle overflow, which will include a responsive state for the two levels of tabs as well.


Current tabs implementation



Screen Shot 2016-08-18 at 12.03.00 PM

Screen Shot 2016-08-18 at 12.03.08 PM

However, When there are many tabs, it requires significant scrolling to find one of the tabs. Also, it’s not recommended in Material Design guidelines to present tags as a single column


Screen Shot 2016-08-18 at 12.04.01 PM


You can also view this Angular Material demo

2.Responsive Secondary Tabs

Current secondary  tabs
Screen Shot 2016-08-18 at 12.58.52 PM
Screen Shot 2016-08-18 at 1.00.06 PM

It might be better for mobile use cases to scroll horizontal versus displaying all the options. Here are some suggestions to address the problem. ->>

Screen Shot 2016-08-18 at 1.02.18 PM


Screen Shot 2016-08-18 at 1.03.16 PM


Responsive Demo
responsive secondary tabs


Demo is  based on AngularJS ->>

Posted by & filed under Forms.

The red asterisk ( * ) indicating required fields has been around our digital interfaces so long, it’s one of those things you take for granted, like the anachronistic floppy disk for “save”, or the magnifying glass for “search”. It’s easy to forget that somewhere along the line, it was a choice that someone made.

In recent years, people of the internet have been pondering over the use of our spiky little friend, the asterisk, in web forms. They have been asking the question: “do we actually need this thing?”

The alternative to indicating required fields is indicating optional fields. This is commonly indicated by explicitly writing out (optional) for every optional field. Like the asterisk, the (optional) marker has also been around forever as a pattern in web forms; it is similarly ubiquitous.

The arguments for marking only optional fields with (optional) are that:

  • Spelling out the text (optional) makes it more clear for users what they need (or don’t need) to do.
  • Marking required fields may actually subconsciously influence users to skip optional fields.
  • You don’t need a legend describing what (optional) means.
  • There’s less red, which makes for a subjectively calmer form experience.
  • Marking fields (optional) will be cleaner when most fields are required.
  • It forces the designer to consider: do I really need to provide so many extra options?

So, with that in mind, here’s the design proposal for Required Form Fields in PatternFly:


Our recommendation is to mark only optional fields, using the word “optional” (see Design A1 below for how this looks). If a majority of the fields are optional, then you may mark required fields instead (Design B1), but just be aware that if you use both approaches across different forms, it makes for inconsistency in your designs.

If all fields are required, this can be indicated implicitly by disabling the Primary (Submit) action until all fields are filled out (Design A2).

Conversely, if all fields are optional, you have the choice to remove the optional markers, and indicate the fact that the fields are optional implicitly by always enabling the Primary (Submit) action (Design A3).

Design Options

Design A1

Mark only optional fields. Use this approach by default.

Design A1

Design A2

When all fields are required, indicate this implicitly by disabling the Primary (submit) button.

Design B2

Design A3 (Edge Case)

When all fields are optional, you may drop the optional markers and indicate optionality implicitly by always enabling the Primary (submit) button.

Design A2

Design B1 (Alternative approach)

Mark required fields. You may use this approach when a majority of the form fields are optional.

Design B1


Thoughts, comments, concerns? You have the option to comment on this post.

Posted by & filed under UX Research.

As a user experience researcher supporting the PatternFly project, I’m currently researching and developing personas that represent the typical PatternFly user or contributor. Personas are fictional, often alliteratively named, representations of your users. They are based on similarities gleaned from quantitative and qualitative research on users’ habits, motivations, and work contexts.

While I will do more in-depth research by interviewing users in the very near future, I wanted to have an initial draft of the personas available to get a sense of whether actual users see themselves in the descriptions. Digging around in various sources of information about users and roles, I found enough insights to kick off an initial draft. The sources I started with include:

  • Existing personas: Reuse what we have already learned about similar user types.
  • Interview transcripts: A brief, pithy quote direct from the mouth of a user often encapsulates their intentions far better than 1000 words from the interviewer.
  • Mailing list archives: Who is writing to the PatternFly mailing list? What are they asking about or discussing?
  • LinkedIn: Seeing what similar users studied, how long they have been doing their role, what their career path has been like.
  • Job descriptions: What do employers think these types of users should be doing?

Looking through all this information from dozens of actual users shook out three, possibly four, similar roles: front-end developer, a back-end developer who needs to do front-end development, and a designer (which may need to be broken out into interaction designer and visual designer). Personas can include any kind of information, from what kind of laptop they use to what kind of pet they have, but they work best when you focus on areas that help you understand the problem you are solving for that type of user. For each PatternFly persona, I noted points in these categories: background/tools, goals (motivations), pain points, “a day in the life.”



Organization of the persona information


Once the first draft was solid, I ran it by a few teammates to make sure these were heading down the right path. Through these discussions, it became obvious that the idea of “open source contributor” was important to include, but isn’t so much a persona as much as it is a role that each of these personas takes on at various points. Each persona has times when they are consumers of PatternFly (reading content, downloading examples) and times when they are contributors (participating in the mailing list, writing patterns, submitting code), and their actions and motivations in each case would be very different. To date, searches for persona-like research done on open source contributors have proven less than fruitful.

And that, my friends, is where we are today. I invite you to peruse the draft and think on your own PatternFly experiences and those of people you have collaborated with. As you do, ponder these questions as well:

  • Are interaction designer and visual designer separate personas?
  • Are there any personas that are missing?  What about high-level roles like architects?
  • Can you recommend any good articles or research written about what it is like to be an open source contributor?

So, do you see yourself in these personas?  Let me know your thoughts in the comments.


Edited to add a link to the ODP version of the personas. If you use the file to write your own personas, let us know — we’d love to see what you create.

Posted by & filed under Controls, Forms.


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.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: (Please try the mockup and leave your comments in Invison demo freely.)


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~

Posted by & filed under UX Research.

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.

Screen Shot 2016-08-04 at 4.42.01 PM

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.


(Many thanks to my co-author and co-moderator Allie Jacobs. Big thanks also to Andrés Galante and Jeff Phillips for creating the excellent prototype, and to session notetakers Mary Clarke, Colleen Hart, and Matt Reid.)

Posted by & filed under What's New on

Aug 5, 2016

  • Pie Chart Overview and Design tab updated with documentation.
  • List View updated with live full page example.
  • Heat Map AngularJS updated to include example of hover on multiple blocks.

Aug 1, 2016

July 27, 2016

  • Documentation regarding “No Data Available” added to the Dashboard Card pattern.
  • About Modal pattern updated with specifications regarding modal location on a screen.
  • Community page updated with July’s meeting deck and recording.

Posted by & filed under UX Research.

The Widgets page is one of the most visited on 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.”


But, unless you’re a Visual Designer, you likely wouldn’t classify CSS elements as Widgets:


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

Posted by & filed under PatternFly, What's New on

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.
  • Visual enhancements: The site’s visual design stays true to the PatternFly look and feel, however you’ll find subtle visual enhancements throughout the site.

We hope you enjoy exploring the new site.
– The PatternFly Team