In the PatternFly Roadmap we outlined our future plans for PatternFly and laid out the goals for the PatternFly 4 release:

Providing initial support for Angular 2 application development

Updating the libraries on which Angular-Patternfly is built

Making the dependence on jQuery optional when consuming Angular-PatternFly

Today, we are excited to announce our first PatternFly 4 alpha release, PatternFly 4.0.0-alpha.2 (we had to skip 4.0.0-alpha.1 due to some known issues). This blog provides some highlights of the release, please check the release notes for PatternFly and Angular-PatternFly for further details.

The PatternFly 4 changes are centered around the javascript implementations of our patterns. The patterns and their CSS implementations have not changed since PatternFly 3. There are no API changes to PatternFly Core, however you will want to refer to the migration guides for PatternFly and Angular PatternFly for details on migrating your applications to PatternFly 4.

Angular-PatternFly

Directive to component migration

The primary driver for the PatternFly 4 release is to enable Angular 2 development through the re-factor of our Angular 1.x directives into Angular 1.5+ components. These components can be used in a “downgraded” Angular 2 application. All directives have been converted to components, except the pfRemainingCharsCount, pfFocused, pfValidation, and pfFixedAccordion directives. We have provided a Angular 2 quickstart that can be used as a starting point for your own PatternFly Angular 2 applications.

Optional jQuery

With PatternFly 4, we’ve refactored our Angular modules to enable development of Angular-PatternFly applications without bringing in the jQuery dependency. To take advantage of this, include the patternfly-settings.js file from the PatternFly dependency, rather than patternfly.js. More details can be found in the associated Github Pull Request.

Table View Component

New common component work has landed in PatternFly 4 with the introduction of the Angular-PatternFly Table View component. The table view component leverages the angular-datables port of the datatables.net library we are using in PatternFly 4. It brings the highly requested table view pattern implementation to Angular. Check out the Angular-PatternFly docs for more details on using the table view in your Angular applications.

PatternFly Core

jQuery component split

We’ve refactored the monolithic patternfly.js file into a number of separate source files with this PatternFly 4 release. The goal was to better enable developers to locate functionality and contribute to PatternFly. The individual files are still packaged into a single file at build time, mimicking the PatternFly 3 distribution, as such there is no migration step required in this regard for your applications.

Ruby now optional for building PatternFly

Ruby is no longer required to build and contribute to the PatternFly project. Ruby was required due to our use of jekyll to provide code samples that are used in both the development of PatternFly components, as well as live examples on the patternfly.org site. Having to install ruby and the associated gems however presented a source of frustration and an impediment to contribution from our javascript developer community.

To overcome this hurdle, we’ve implemented a javascript tool to render our jekyll test pages using the liquid-node library. The full jekyll build is however still available for those who have ruby installed. See the README for instructions on toggling the javascript/ruby build for PatternFly.

Next Steps

We will follow up with additional PatternFly 4 alpha releases as we solidify our API and component changes. Once we are API stable and feature complete we will have a Beta release, followed by a final 4.0.0 release. We will continue with PatternFly 3 releases until PatternFly 4.0.0 is ready. After the 4.0.0 release, we do not plan to have anymore PatternFly 3 releases.

PatternFly 5

PatternFly 5 development has continued concurrent to the Patternfly 4 effort. We are planning a 5.0.0-alpha.1 release in the coming weeks. Stay tuned for blogs and announcements detailing what we’ve been up to with PatternFly 5.

Overview

The Column Visibility control enables users to define what columns are visible within a table. Column visibility helps users consume data by allowing the user to hide any data that doesn’t assist the user in completing his task. The control is represented as an icon button, that when clicked, displays a dropdown menu with multi-selection enabled where the user can select which columns are visible.

There are currently two variations of the table design:

the toolbar is detached from the table

the toolbar is attached to the table

The goal of this design is to define a position in the toolbar for the Column Visibility icon, so that the positioning is logical within the toolbar and consistent between the two table variations.

Design – Column Visibility component

The Column Visibility component consists of the following elements:

icon button

dropdown menu with multi-selection, listing each column that can display in the table

When the user clicks the icon button, then the dropdown menu with multi-selection displays. The multi-selection is implemented as a list of checkboxes with column names for labels. The columns are listed in the same order that they appear in the table.

Example 1: Column Visibility component

Collapsed state

Expanded state

Design – Toolbar with Column Visibility icon

Within the toolbar of variation 1, the first two groups of controls affect content display—filters affect what contents display, and sort affects how the contents are listed. Controlling what columns display is closely related to controlling how contents are sorted in that they both affect how contents are presented and organized. Therefore, the Sort and Column Visibility controls are included in the same toolbar group.

When Sort and Column Visibility are displayed in the toolbar, the Column Visibility selection does not affect the options that are available in the Sort Selector. This allows the user to sort by a column that is not visible in the table.

Example 2: Toolbar design of table design variation 1

In variation 2, where sort is controlled by clicking the column headers, the icon for controlling what columns display still displays in the same relative position in the toolbar. Except in this example, the icon is the only element it the toolbar group.

Example 3: Toolbar design of table design variation 2

For variation 1 of the table design, the user might also have the option to toggle how the data is presented, whether as a table, list or card view. Given that the column visibility icon is available for the table view, when the user switches to another view (list or card), then the column visibility icon will no longer display in the toolbar. The goal in removing the icon, as opposed to disabling it, is to avoid unnecessary clutter within the toolbar by not including anything that isn’t actionable.

Example 4: Comparison of toolbar design between table and card views.

The UXD team has been hard at work churning out PatternFly releases at a regular cadence, steadily increasing the number of design patterns and design pattern implementations. In recent releases we introduced a number of changes aimed at simplifying the consumption and contribution processes for both designers and developers.

There are a number of ways we want to improve and scale out PatternFly that can’t be addressed without introducing breaking changes to the project. As such, we’ve had a series of planning meetings to address those concerns and build out a roadmap for our community to plan around and coordinate their efforts.

The PatternFly roadmap consists of two major releases over the course of the next year. In PatternFly 4, the first of these major releases, we will provide an immediate solution for developers looking to take advantage of PatternFly in their Angular 2 applications. PatternFly 5 will follow with a more complete strategy for scaling out PatternFly by taking a modular approach in both our pattern designs and implementations.

PatternFly 4
Goals

The goals for PatternFly 4 are primarily focused on modernizing the Angular-PatternFly project, and consist of:

Providing initial support for Angular 2 application development

Updating the libraries on which Angular-Patternfly is built

Making the dependence on jQuery optional when consuming Angular-PatternFly

Angular-PatternFly

Angular-PatternFly 4 will consist of a refactor of all our Angular directives as Angular 1.5 components. This is a comparatively simple re-factor and enables Angular 2 applications to consume our existing pattern implementations. Look for additional blog posts detailing how to build such Angular 2 applications as we roll out our initial Angular 1.5 components. This migration has the follow-on effect that all downstream applications will have to upgrade to Angular 1.5 to stay current with PatternFly releases.

In addition to this directive -> component refactor, we will introduce a number of dependency upgrades into Angular-PatternFly with this major release. Most notably we will update our ui-bootstrap dependency to the latest release, an update a number of developers have been asking for.

The Angular-PatternFly jQuery dependency will be made optional in this 4.0 release. Several of our pattern implementations will continue to be built around jQuery, but if an application doesn’t use those patterns, then the jQuery dependency will not be required.

It should be noted that these updates will result in some directive API changes, implying minor code changes in downstream applications. It is for this reason that we are incrementing the major version to 4 with this release.

PatternFly “core”

The changes to our PatternFly “core” repository are less significant in the 4.0 release. They primarily involve breaking apart the “core” repo into one for CSS and one for the jQuery pattern implementations. Re-structuring the repositories in this manner puts the jQuery pattern implementations on an even level with the Angular-PatternFly implementations.

PatternFly consists of:

Design patterns

A CSS implementation of those design patterns

Alternate javascript implementations of the behaviours associated with the design patterns

Release Timeline

We will have an initial alpha release of the PatternFly and Angular-PatternFly projects in January. This first alpha is expected to be sufficiently complete to try it out in downstream applications. We will stabilize our APIs and implementations with follow-on alpha and beta releases, aiming to get to a final release a timely manner.

PatternFly 5

Goals

The scope of PatternFly 5 is much larger than the scope of PatternFly 4. With PatternFly 5, we are working to scale PatternFly in a number of areas:

Scaling adoption with a modular design system to increase the number of use cases we can support

The roadmap below covers how we’ve solved these challenges and are pushing PatternFly forward to power great user experiences through open source design.

Modular approach

In PatternFly 5, we are adopting a modular approach in both our CSS and Javascript implementations. This modular approach offers a number of advantages:

Easing the contribution process

Facilitating piecewise consumption of our patterns

Fostering a community of patterns around PatternFly

Atomic CSS

We are using the atomic design system by Brad Frost to implement our modular design system for PatternFly 5. Implementing our CSS in such a modular fashion involves a full rewrite, which provides a good opportunity to adopt Bootstrap 4. We’ve also developed a set of CSS guidelines based on BEM to ensure we develop performant and maintainable CSS.

Web components

The PatternFly 4 work to move to Angular 1.5 components offers a useful stop gap, enabling Angular 2 development, but does not offer a suitable long term strategy. Nor does it address the requests to support React and other web UI frameworks. To understand what it means for PatternFly to support a web framework, let’s review our current deliverables.

PatternFly 3 and 4 deliverables consist of:

A CSS implementation of our design patterns

Javascript implementations of pattern behaviours

The behaviors associated with patterns are implemented as both jQuery plugins as well as Angular 1 directives/components. We could support Angular 2 and React by developing both Angular 2 components and React components, effectively doubling the number of behavior implementations we develop and support for each pattern. However, this is an approach that does not scale.

Instead, we are looking to web components as the solution to scale out our PatternFly framework support. We are focusing on the Custom Element specification in particular, and the corresponding polyfill. We will consider incorporating the remaining web component specifications into our solution in the future, after they have had a chance to mature.

Browser support for custom elements (when incorporating the polyfill), provide support for relatively current browser releases, and provides support for IE as far back as IE 10. This is acceptable for new applications, and applications that adopt modern browser support statements. We recognize that there are applications in production that will have an ongoing requirement to support older browsers for some time. We are recommending applications with such requirements stay on PatternFly 4, and wait to move to PatternFly 5 until their browser requirements are aligned with what is supported by PatternFly 5.

Internationalization and accessibility

Support for internationalization and accessibility are increasingly requested features for PatternFly. However, retro-fitting those concerns into our existing framework has proven to be a difficult task. As such, we are baking solutions for these concerns into our web component development process to ensure the problem is solved from the get-go in PatternFly 5.

Design and style changes

Decision tree

As recommended by the guidelines of the Atomic design system, we are employing a decision tree to formalize the criteria that prospective patterns will be evaluated against before including them in PatternFly. A draft of our decision tree is included below. Refer to Andres Galante’s blog post for more details of how we plan to apply the decision tree.

Mobile support

While PatternFly is built around Bootstrap, and Bootstrap is responsive, not all of our patterns are themselves responsive. With PatternFly 5 we will revisit mobile-relevant patterns and make sure they are indeed responsive and progressively enhanced, both in their design and implementation.

Updated style guidelines

Additional style changes involve a move to the Overpass font, designing a new Typography system, and increasing the base type sizing. Read more about this in Kyle Baker’s blog post: Choosing the Best Font for Application Design.

Additionally we’ve had to revise the spacing of the entire library to accommodate the new modular design system and update the documentation and artifacts to reflect these new styling changes.

The PatternFly 5 “flywheel”

The redevelopment effort for PatternFly 5 can be summarized with the following diagram. We start by applying the decision tree to evaluate the pattern and consider breaking it down into common components. The pattern then undergoes design revisions, followed by new CSS and Javascript implementations. Testing of our implementations is a priority, along with the cross-cutting concerns of internationalisation and accessibility.

Look for an initial alpha release with our PatternFly-core CSS (including our new style updates) and a few initial web components in the coming months.

Future

While developing PatternFly 4 we will continue to do maintenance releases of PatternFly 3, and will continue with PatternFly 3 maintenance releases until the bulk of our community has had a chance to migrate to PatternFly 4. The migration of applications to PatternFly 4 is expected to be fairly straightforward.

Development of PatternFly 5 will take some time, with a potential delivery in late 2017/early 2018. During the development of PatternFly 5, we will continue to introduce support for new patterns and components in PatternFly 4. Once PatternFly 5 is released, we will continue to develop new patterns concurrently in both PatternFly 4 and PatternFly 5 until the web-component browser support story of our our downstream products allows us to consolidate our efforts on a single approach.

There are many opportunities to contribute to PatternFly as we push forward on this roadmap. Whether you’re a designer, or a developer, or even a writer, we encourage you to reach out to us and get involved in bringing this open source community project and help make it the project you need it to be!

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)

Option 2: Syntax hints below input field

Hints are always visible, reducing strain on short term memory and chance of user error

Layout can easily be used for responsive websites.

Cons:

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

Pros:

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

Cons:

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?

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.

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 patternfly.org 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 noshortsupply 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-designworkflows 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.

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!

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.