Posted by & filed under Forms.


The PatternFly team is working to define recommendations for the placement and functionality of syntax hints as they are used in forms.

The focus for this user story

This user story includes discovery and exploration around recommendations for globally universal field inputs; such as character counts, types of characters allowed, urls, and email addresses, just to name a few. The team will also define guidelines on syntax hints usage: When are they needed? In what scenarios would they distract a user from completing their task?

What is out of scope?

We’ve seen a lot of interesting questions come up on the PatternFly email list around syntax hints. This is a complex topic with lots of variables and we will address some of these issues in a later user story, for example:

  • Local standards for syntax, including:
    • Phone numbers
    • Mailing address
    • IP address
    • Naming fields (first name/last name, surname, family name, etc)
  • When to explain how input data is used (help) vs. showing the user the format that data must be in (syntax)
  • When do we use data validation instead of syntax hints?

While we won’t address every issue related to syntax hints, the solution in this user story should consider other design patterns for forms already in use, such as Errors and Validation, Field Level Help, and Form Field Layouts.

Discovery Phase

During our discussions and research, we found a few design solutions to consider:

Option 1: Placeholder syntax hints




  • Uses limited vertical space, making the form easier to scan quickly
  • Limits the need for information recall because the syntax hint disappears only after the user starts typing, not when the field is clicked
  • Layout can easily be used for responsive websites. Placeholder syntax hints don’t require layout adjustments for mobile or tablet devices.


  • If used on all fields, the form could be visually overwhelming
  • Contrast will be a challenge. We will need to be consider how to balance hierarchy between the label, input field, and hint text
  • Length of syntax text will be limited to character count of form field
  • It will be difficult for users to confirm the correctness of their responses before submitting the form if syntax hints disappear after user input
  • Placeholder text is not broadly supported across assistive technologies and not displayed in older web browsers

Option 2: Syntax hints below input field



  • Allows fields to remain empty, drawing attention to empty fields and encouraging completion
  • Hints are always visible, reducing strain on short term memory and chance of user error
  • Layout can easily be used for responsive websites.


  • Increases vertical length of the form
  • If used on all fields, the form could be visually overwhelming – reducing completion rates and increasing user errors
  • Maintaining typographic hierarchy through font size and contrast could be challenging.

Option 3: Syntax hints in-line with form field



  • Additional vertical space needed in form layout is minimal
  • Length of hints is flexible, allowing for clear instructions that may be longer in length
  • Keeps user focus on empty form fields, encouraging completion


  • Translating this layout to mobile would require using responsive breakpoints, forcing the layout to change
  • Typographic contrast could be challenging. The hierarchy between label, input field, and hint text will need to be considered.
  • The horizontal layout will increase the time it takes users to scan the page because of additional eye movement

Next steps

Since we are in the early phase of exploring this topic, we’d love to hear your input. Do you have a preference for one of the three options above? What scenarios do you think we should use syntax hints?

Posted by & filed under PatternFly Design.

Think about a design system as a tamagotchi. To keep it alive once your turn it on, you need to take care of it: keep it clean, feed it and make it sleep, almost like a living creature.

That’s why supporting and maintaining a design system can be more challenging than initially creating it. A smart strategy, really good rules and a lot of love and patience is the only way to guarantee long-term success.

“A critical part of design system maintenance is ensuring that UI patterns stay up to date, embrace evolving design and development best practices, and continue to address the real needs of the organization.” – Brad Frost

To govern the Vanilla Design System, the Canonical web team developed a fascinating decision tree and PatternFly took a similar approach.

The PatternFly Decision Tree


The goal for PatternFly is to deliver a set of common and modular UI components. The goal of the PatternFly decision tree is to identify common components and that we have all the parts to build them.

To define what makes a component common, we chose to follow a simple general rule: if two or more projects using PatternFly are asking for the same component, then it’s considered common.

To determine whether or not a component is modular requires deconstructing the component into smaller blocks to understand the underlying structure of that component. That way we can ensure we are building reusable parts instead of reinventing the wheel every time we introduce a new pattern.

The three outcomes are for a pattern to be modified, added, or removed from the design system.

Practicing What We Preach

This process doesn’t only apply to new patterns. We are running our existing components through the decision tree.

“A design system needs ongoing maintenance, support, and tender loving care for it to truly thrive.” – Brad Frost

We will have be having regular assessments to make sure components stand the test of time and modify or remove them as needed.

Just like PatternFly, the decision tree is not set in stone. Both are living resources that will evolve as we care for them and give them love.

Posted by & filed under PatternFly Design.

As you may have noticed, there is a new repository on the Patternfly Github page called patternfly-design.

The purpose of the repo is to house the designs and documentation for Patternfly and to be the center of design contributions going forward. Patternfly-design will address a number of issues with the old design contribution model and open up several possibilities for the future of design with Patternfly.

Going to Github

Previously, our design contributions were created and stored on Google Drive, which worked well for writing and adding graphics, but had several limitations. Google Drive’s default document sharing settings made viewing and collaboration difficult and reduced discovery of new content. Additionally, a fluid folder structure meant that new documents could be easily misplaced.

The new system of storing files on Github means that all Patternfly design documents are publicly viewable by contributors. Anyone can view, suggest edits to, and comment on designs without needing to be given file permissions. Comments and updates are tracked and available as well as past versions of designs, so it will now be possible to look back through the history of a design and view the changes it has undergone as well as the discussions surrounding those changes. New design documentation written in markdown will enable us to streamline the process of updating because we can now automatically generate web pages whenever a pattern is added or changed without the need for manual entry. Finally, the new system encourages contributors to make use of the powerful version control features provided by Git.

There are numerous reasons to use git with design work. First of all, your work is backed up so you never have to worry about spending hours re-creating a file that got corrupted, deleted, or otherwise lost. Second, older versions of files are easily retrievable just in case you decide that you really preferred the work you had yesterday and have long since overwritten. Lastly, the ability to create multiple branches of your projects removes the need for folders full of files with names like “Design v4 copy copy.psd”.

Grasping Git

Because of all the benefits that Git brings, “Git for designers” guides are in no short supply on the internet now, and many of them do a good job of explaining the fundamental concepts behind version control systems. The guides tend not to prescribe workflow conventions, however, because every project using Git is organized in a different way and has different needs. In order to remove this final layer of haziness, we have put together some guides that outline the recommended patternfly-design workflows and repository conventions in a visual way that aligns well both with the way that many designers conceptualize things and with the highly structural nature of Git.


In addition to the graphical guides, the patternfly-design wiki contains a series of walkthroughs that provide step-by-step instructions for setting up your work environmentmaking a contribution, and working with multiple branches.

Hopefully all you Patternfliers will find these resources to be helpful and enlightening as we transition into this powerful new contribution process. Be sure to leave your thoughts in the comments, and your designs in the patternfly-design repo!

Posted by & filed under PatternFly Design.

Typography in Application Design

Great application design relies on very limited use of graphical elements, the designer relies primarily on type to display data and establish the information hierarchy. PatternFly was designed to present clear, unobstructed content is critical to enable users to complete their tasks. Choosing the correct typeface and defining the right styles is not only important for users doing their job but it also is the primary element for setting the tone of the application.

Switching to Overpass

The current PatternFly typographical system is set on Open Sans, which was in the PatternFly beginnings an open project well maintained by Google. Google has since moved on and so have we. We chose to switch to Overpass because is important that we utilize the resources which have developed through open source methodologies. Red Hat has developed ‘Overpass’ as the corporate web typeface based on ‘Interstate’ which has set the tone as the brand standard. Overpass has been tested throughout Red Hat web properties and has been proven as a great alternative. It is time to make the switch.

There are many considerations when choosing the correct font specifically for application design such as: language coverage, weight variety, character shape, hinting, etc. Overpass has recently been extended to include two new weights and hinted to work great on low resolution screens. This will make the application content more accessible and allow the designers to continue relying on type as the primary way to establish the information hierarchy in our applications.


Growing Pains

Moving to Overpass does have its challenges. The primary challenge is that it does not offer as much character coverage as Open Sans. To combat this we are mirroring the Red Hat web properties strategy of relying on a well tuned system font stack to display the correct characters for any language.

Making the transition

PatterFly is going through a period evolution. There is no better time to make this change then now. We are taking this opportunity to make changes to our designs which includes changing to Overpass as well as increasing the base sizing and spacing. This change is a substantial effort which we plan to roll out in the next major PatternFly release.


Posted by & filed under Content Views, Table View.

It’s time for PatternFly to revisit pagination within data views.  This includes tables, list, and card views. In the past, pagination was part of data tables but we recently wanted to start fresh with data tables and gradually add elements as we go. Pagination seems like a fairly simple and straightforward concept but with multiple pages, it could get messy if not done correctly. We looked at a variety of tables and reviewed how pagination behaves within them for this story


Before we move forward, let’s briefly discuss the persistent elements. Most elements/controls related to pagination would be found on the bottom of the table.  This includes:


  • See the number of items on a page and total number of pages
  • See how many pages of data there is.
  • View which page you are on (current location)
  • Modify how many pages are being displayed.
  • Skip to the next or previous page.
  • Skip multiple pages.
  • Navigate to the first/last page.


Selection info will be shown in the top right of the table. With this story we wanted to add the ability to select all items across multiple pages. Initially, if you select all on a page, it will select all items only on that page. Then it would prompt the user to select all items across the table. Below I came up with two options to address pagination selection across pages along with the pros and cons of each.




The first option above shows a new row appearing within the table under the row headers, in the form of a message. This message informs you of how many items are selected and gives you the ability to select all.  Once all are selected, you have the ability to clear selection from the within the same message.


As you page through the table, all items will remain selected, however the message will not be shown. View below:




Option 1 Pros:  the addition of the message row is obvious and will draw the user’s attention.
Option 1 Cons: Table height would have to adjust to accommodate new message row.  Also, does the placement of the message make sense under the row headers?  Furthermore, it’s redundant to show the number of items shown twice (upper right, and in message)


Option two addresses the cons of option 1.   Selection info will stay persistent in the top right, whether there are none or all items selected.  This way, the user always has the ability to select all or clear selection. They still have the ability to select all items within a single page as well as individual items.




Option 2 Pros: No need for creating a new message row and shifting the table down.  No redundant info. Persistent location and info shown.
Option 3 Cons:  Might not be obvious that you can select all items. Does is seem hidden?


Overall option 2 was preferred. People liked the less obtrusive and simple behavior of it. However there were a couple concerns that surfaced:


  • Language: Does this language make sense? I thought it was helpful to have the “Selected:” label so that way it could stay persistent and we could still show info when none are selected.
  • Selection info shares the row with Filters.  As filters are added, they will appear in the same row to the left (below filter field) and if enough filters are added, they can run int the selection info. Would we then create an additional row for filters or truncate the list of filters and just have a drop down to view all.
  • Move selection info to left so it aligns with selection checkboxes. This makes sense but since filters are of the left, this would require an additional row.  I’m not sure if that’s the best reason to create another row, especially since that would be the only info shown on the row (rest of row would be empty, and thus look unbalanced)


I’ve also quickly mocked up how pagination would appear within the card and list view.




Another thing to note is that filters will work across pages.  I talked with Dan, who has been working on implementing the new data tables, and he confirmed that this will not be a problem, the technology he is using supports this.


Would love to hear your thoughts on option 2, especially concerning that feedback/concerns that we have already received. Next step we will refine this design for the final stages.


Please comment below, thanks!


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.