Posted by & filed under Terminology and Wording.

Base on the document of Terminology and Wording
PatternFly encourages users to adopt much more emotional descriptions to show the time and date in the application. In most cases when users created a blog or document, their activities like attached / updated / followed / commented / liked / unliked…, we can use the following ways to display time:



In some environments, your application may need to show a correct time information, like a meeting time or a event time… Here are some recommended examples to show the correct time.


More information about Date Formats, please check Terminology and Wording of PatternFly


Hi folks,

Please feel free to leave your comments and suggestions. Thank you~

Posted by & filed under Forms.

The PatternFly team is working on the conceptual design for multi column forms. However, this concept is slightly different from other patterns the team has worked on.

We are exploring if there is ever a good use case to use multi-column forms, and if so what are they? 

Forms are a valuable tool because they offer a variety of layouts that can be used to organize your content for users to complete in a meaningful manner.

However, in the case of multi column forms, it’s mostly best practice to avoid their use. The main problem is that using multiple columns within forms could cause the potential for users to interpret the fields inconsistently.  Below are 5 examples of ways multi column forms could be interpreted.


As you can see, multiple columns interrupt the vertical impulse to move down the form. Rather than forcing the users to visually reorient themselves, it’s best to keep them in a consistent  flow by sticking to a single column layout.

However, there are a couple exceptions that seem to be acceptable.



Example 1

The main exception for using multi-column forms that cause the least amount of confusion were for short fields as well as logically related fields.  The most common example are name and address fields (City, State, and Zip Code).



This type of content is standard and easy for users to follow. One suggestion for this format is to align the labels above the fields, rather than to the left. The thought was that this makes the grid stronger and thus, easier to map the fields visually.  Do you agree or disagree? This could be something we could explore for this pattern if we decide to move forward with it. In this case the labels are kept to the left to stay consistent with our general form design.

Another variation is instead of a standard two level format, use various columns. Keep in mind that this will works best for related short input fields.


Example 2

The second exception is when there are to different form choices.  User must choose to fill out one or the other.  In this case, when the forms fields are shown next to each other in a multi column format, there is little confusion as long as the distinction of the two form choices are clear.



There were several thoughts on this use case. First being that this would be considered two single column forms next to each other, rather than a multi column form. The second being that instead of this format, opt for a preselection for new or returning users.  This would then display a single form rather that two side by side.



Because this is the beginning stages of the development of this pattern, we would love to hear your thoughts and input on this topic.  Are there any other scenarios that are acceptable?  Do you agree with the conclusion and the comments received thus far?

Please comment below with your thoughts as they could help shape this pattern as it moves forward along the design process.

Posted by & filed under Web Components.

If you’ve been following the Patternfly mailing list or happened to stumble on our recent post on, “Are Web Components in the future for Patternfly?”,  you’ve probably noticed that we’re doing some thorough research on web components right now.

I’d like to take this opportunity to provide a few updates on our findings and share some context on our recent discussions around web components in Patternfly.

Are web components feasible?

Custom Elements, HTML Imports, Shadow DOM, and HTML Templates are the new specifications heavily influencing web components (you can read a great introduction here if you’re new to these topics), but it’s important to remember that these are mutually independent. Although many examples combine Custom Elements with Shadow DOM CSS techniques, they are not required to be used in conjunction (another trait which adds to their versatility). Custom Elements can stand alone and be styled just like other HTML.

Due to Shadow DOM’s currently minimal browser support, it would not be a stretch to consider a gradual adaptation to implementing new web component standards like the following:


As browser support improves, Shadow DOM can be adopted to improve our CSS encapsulation where necessary. It should also be noted that while HTML Imports may be the most common way to consume web components, Custom Elements can be defined and included as ES6 classes. This alleviates another web component standard and gives options with this specification as well.

Exploring Web Components with Patternfly

Building on our past breakaway sprint efforts with web components, we’ve extended our <pf-tabs> element and tested our approach with some popular new web frameworks gaining traction at Red Hat: ReactJS and Angular2. Utilizing components as “leaf nodes” within other framework components makes them essentially comparable to other DOM nodes used, only much more flexible.

The goal of this research was to integrate a custom element in these frameworks alongside our Patternfly implementations and explore any roadblocks or challenges discovered.

You can see our current work on the <pf-tabs> component here.


(pf-tabs component rendered individually)

A few things to note about this component:

  • The element has been tested in a React context and an Angular2 context. Any differences in element rendering behaviors are noted in the source of the component (to ensure proper behavior in both frameworks).
  • We’ve added some performance tests to analyze rendering speeds with several occurrences of tabs and nested tabs.
  • We’ve chosen to use “Vulcanize”, a build tool for inlining our element’s css and javascript into a single file. This makes the element easily consumed in one import and reduces network requests.
  • It is completely possible to use element attributes to give your element unique behaviors or styles in different contexts (e.g. the class attribute).
  • Shadow DOM initialization and styles have been commented out and appropriate constructs have been added in their place. It is easy enough to add them back if desired.

Notes on Frameworks ReactJS and Angular2

There are too many details to cover in this post, however I encourage you to explore the aforementioned demonstrations. If you run these demos, you will easily notice that our tabs component works as intended in both frameworks and the new frameworks provide adequate contexts to create a Patternfly application.


(Tabs component rendered in a Patternfly/React app)

I should add that our discussions on these frameworks have been fruitful (luckily, there is already an abundance of materials for each to aid in our research). Both frameworks provide exceptional solutions for common problems app developers face like data binding, observing state and inter-component communication, custom events, and optimal rendering. Particularly important, we haven’t found web components causing any barriers in this regard and observed the patterns implemented in these solutions translate quite nicely to web components.


We’ve prepared plenty more to share on this in future posts and will be fine-tuning our strategy in coming weeks. We’ll also be exploring other topics like performance, server rendering, and modular design. So stay tuned to our blog and mailing list all you Patternfliers!

Posted by & filed under Forms.


This blog is to investigate the web form design especially the conditional hidden fields, and give out the possible solutions.

Should we hide fields if user can’t be interacted with? Do we always just keep all fields there and gray them out? Or use progressive disclosure if there are more fields based on a given selection?

When we designing a web form, we should always keep the form easy and simple. We could hide the unnecessary fields in order let users focusing on the present job and show them out when needed.

The picture below is a comparison of the old Apple ID register page and the new one. The difference between the old one and new one is that they remove the mailing address input. Most of the users will register the ID only for downloading the applications or set up a new device. Moving the mailing address part to the buying page and  hiding it in the current page will make the workflow more smoothly.


Old Apple ID register page                                                                              New Apple ID register page                                                                                

apple id1                            appleid1


Back to the question, we could use the progressive disclosure if there are more fields based on a given selection.

We would not rather choose to show the fields that user can’t be interacted with.

In this case, user will spend unnecessary  time to identify what fields they can be interacted with and what they can’t.

We would rather not keep all fields there and gray them out.

The color of Patternfly unclickable field is very light. They can not be seen very clearly on the Linux and Microsoft devices (those devices do not have Retina screen).

Design Options

The Wireframe link is here

Design 1:

This is to define the single level conditional fields.


1.I change the input name from the left to the top in order to help user viewing the form more easier.

In web form design, it is better to use “F” sight line rather than “Z” sight line

屏幕快照 2016-08-10 下午5.48.01

屏幕快照 2016-08-10 下午4.43.16

2.The unchecked field will not be shown unless user clicks it. After clicking the checkbox, the text field will show. The design is to help user focusing only on the present workflow, to avoid him from losing the way. When clicking the first selection checkbox, the text field will all hide.


Design 2:

This is to define the multi level conditional fields.

1.Add a cutting line to distinguish the first level fields and subfields.

2.Unchecked fields will open only until user clicks it. When clicking the sub level checkbox, the text fields will show.



Design 3:

This is to define the conditional fields with dropdown menu.

1.Despite of the first selection fields, the other none selected dropdown menu will hide until user clicks it.

2.When clicking another checkbox, the previous none selected dropdown menu will hide.



Thoughts, comments, concerns? Feel free to comment on this post.

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