Posted by & filed under UX Research.


When adding new features to PatternFly patterns and widgets healthy debate sometimes arises among the PatternFly team about the best way to design the features. Other times, the team might be in agreement about the best design approach but still wants external validation before the design gets implemented. When either of these situations arises, we try to make decisions based on data provided by users through empirical testing. Recently, questions arose around three issues: (1) the best way to communicate pagination behaviors for table, list, and card views, (2) the best way to visualize links in aggregate status cards, and (3) the best way to provide syntax hints for form fields. To answer these questions the team conducted some “cafeteria tests” with users. Cafeteria tests are short usability tests conducted in a high traffic area (like a cafeteria) that typically focus on a single question or a small number of questions and can be completed in a few minutes. Participants can be recruited beforehand or just grabbed on the spot when they wander by the testing location. The rest of this blog describes the three studies we conducted and the findings and recommendations for each.

Study 1 – Pagination Behavior

The goal of this study was to gauge participants’ understanding and usage of the pagination controls in PatternFly table, list, and card views. The controls include a column selector for selecting all items currently visible, a Select All button for selecting all items (including those not currently visible on the page), previous and next buttons, and a drop down for selecting the numbers of items to view per page.

 

Participants were shown a table view and asked the following questions:

  • How would you select the items on the current page?
  • How would you select all of the items in the table.
  • If a single item in the table were selected, what would you expect to see when you clicked to the next page – would the current selection persist?

Results showed that the meaning of the Column Selector control is unclear. Some participants thought it selected all items on the current page; others thought it selected all items in the table; and some (about 1 in 3) either didn’t notice the Column Selector or didn’t realize it was a control. (Interestingly, about 1/4 of participants also noted that they never noticed the Select All control in the upper right corner of the table.) When asked about selection persistence, there was no consensus among participants. About 2/3 correctly believed that selections persist when moving among pages, while the rest thought they would not.

Based on these findings we made the following recommendations:

  •  Add flyover help text to the Column Selector explaining its function.
  • Change the appearance of the “Selected: x of y” when paging to help users understand selection persistence.

Study 2 – Visualizing Links on Aggregate Status Cards

The goal of this study was to understand users’ preferences for the way links are visualized in PatternFly aggregate status cards. Three options were considered:

  1. Static – Link text is always blue and underlined; nothing changes on mouse over.
  2. Text change on hover – By default, link text text is black and icon color is determined by status (green, yellow, or red). On mouse over, text changes to blue and underlined.
  3. All change on hover – By default, link text text is black and icon color is determined by status (green, yellow, or red). On mouse over, text and icon change to blue and text is underlined.
  
Static Text Change on Hover All Change on Hover

 

 

Participants were shown three identical web pages that included aggregate status cards. The only difference among the pages was how the links on the cards were visualized. Participants were not told what the difference was. Participants were allowed to view each page for about a minute and were told they could move the mouse around the page but not click, because none of the links were active. After viewing all three pages participants were asked if they noticed any differences among the pages. Then the different link visualization conditions were pointed out and participants were asked which they preferred and why.

Results showed that participants had difficulty identifying the subtle differences among the pages. Only three of 16 participants were able to identify the differences among the three pages without being shown. In addition, 12 of 16 participants did not notice a difference between the “All change” and “Text change” conditions until it was pointed out. Regarding preference, slightly more than half of the users preferred the “All change” condition and about 3/4 preferred either the “All change” or “Text change” conditions. The three users who stated a preference for the “Static” condition all said it was the most obvious.

Based on these findings we recommended that the “All change” condition be implemented. That is, by default text should be black and icons colored according to the status they’re indicating. On mouse over, icons and text should change to blue, provided the icon is clickable.

Study 3 – Syntax Hints

The goal of this study was to validate a proposed design for the way syntax hints are displayed in PatternFly form fields. The proposed design is to display hints in a gray, italicized font inside the form field itself. The hints disappear when the user begins to type in the field. We wanted to know if users are OK with this method of displaying hints and whether them disappearing would impact performance. Participants were given a card with various pieces of information (credit card number, date, IP address, etc.) and asked to input the information into a website form using the formats shown by the syntax hints.

Results showed that users had little difficulty correctly entering the information from the cards into the form fields, with one exception. No users input the Outgoing Mail Server correctly. They all neglected to include the “smtp.” before the server name. Whether this is because they did not notice it before the syntax hint disappeared or is an artifact of the test, in that users did not understand mail server formatting and didn’t think the “smtp.” to be necessary, is not clear. Despite having little trouble using the form with the syntax hints displayed in the form fields, user comments indicated that displaying hints in this manner is not universally preferred. Half of the participants commented (unprompted) that they want hints to be visible at all times and suggested moving hints outside the fields. 

Based on these findings we recommended that PatternFly continue exploring options for the syntax hints design pattern.

Posted by & filed under Announcements.


The Red Hat UXD team would like to introduce the PatternFly Angular 2 and PatternFly React repos! Big thanks to Dana Gutride and Patrick Riley for kicking off the effort by creating the repos and introducing a list of initial issues. At this point, these issues are a list of questions regarding repo setup. We would like to invite you to take a look at the current issues, comment and/or add any additional issues that should be addressed.

PatternFly repo teams have been organized as way to help coordinate the community efforts surrounding each repo to ensure contributions are meeting PatternFly design and development standards. The repo team roles and associated member are as follows:

  • Angular 2
    • Maintainers (JS Dev): Dana Gutride and Dan Labrecque
    • CSS Experts: Adam Jolicoeur and Andres Galante
    • Interaction Designers: Adam Jolicoeur and SJ Cox
    • UXD Strategist: Cat Robson
  • React
    • Maintainer (JS Dev): Patrick Riley
    • CSS Expert: Jenn Giardino
    • Interaction Designers: Jenn Giardino and Matthew Stevens
    • UXD Strategist: Mary Clarke

We are excited to enable Angular 2 and React development for PatternFly and look forward to building out these repos with you.

Best,
The Red Hat UXD team

Posted by & filed under Web Components.


We’d like to take a chance to update the community on our Patternfly web components work. Progress continues on our web component prototype and you can now install an early alpha of our Alert, Tabs, Tooltip, and Utilization Bar Chart components with the npm module. We also have a new showcase site which provides documentation for getting started, component usage, and some demo applications for Angular1, Angular2, and React.

Framework Integrations

We’ve also started framework integration projects for Angular1, Angular2, and React. These modules can be consumed in cases where a framework integration helps in consuming the web component in a particular framework.

Angular 1 & Angular2 Integrations

One area framework integrations can help is in cases where you want to expose two way binding or custom events to a framework. In Angular1, we can “shim” this behavior. You can see an example of this here with our pf-tabs component shim.

Since Angular2 supports custom events by default, you’ll be able to consume web component custom events out of the box with Angular2. It is also generally discouraged to use two-way bindings in Angular2 (notes here). One place you will still find shims helpful though is when you are adding typings (for better Typescript support), or when you’d like to communicate to a component that content has changed. See our Tooltip component shim here for Angular2.

React Integrations

With React, the general pattern of “data in via attributes and properties, data out via events” applies very closely to our philosophy with web components and web component shims (so it’s a natural fit). There is a great post on these patterns here by Rob Dodson which explains this in more detail. Typically with React, our framework component shim is primarily responsible for three things:

  1. Defining a Class Component which internally renders our web component

  2. Mapping attributes and setting any type restrictions (prop types) which would be helpful to a React developer

  3. Handling nested DOM updates (where you are updating a binding inside the web component and triggering React’s componentDidUpdate method). In these cases we let the React shim notify the web component that its content has changed.

You can see this in action with our pf-tooltip jsfiddle.

Hopefully this clarifies some things about our framework integrations. I look for more framework integrations to make it in as our community grows!

Upcoming Plans

We have some ongoing work which should make its way into our patternfly-webcomponents project soon.

  • Adding v1 support for our custom elements. The web component polyfill was recently upgraded from the v0 specification to the v1 specification. This will change a few things like using “constructors” in our classes instead of the “createdCallback”, but should be a pretty minor upgrade for us. #28

  • New web component developments are underway for our Dropdown, Accordion, and Popover components. These will expose similar APIs to Bootstrap’s so they’ll fit right into your existing Bootstrap application. #24, #25, #26

  • New test pages. We’ll soon be incorporating test pages into our PR/development process with Travis so that you can review these at your leisure when reviewing a PR or you’d like to dive further into a web component example. #27

Getting involved

If you want to gain some experience working with Web Components, then check out our web component project on github, join our conversation on slack #webcomponents channel.  If you are eligible, we’d love to have you participate through our GSoC proposal.

We’d love your feedback on our progress so far and certainly appreciate any early alpha adopters. Please feel free to leave comments and questions in the Patternfly mailing list. We are always happy to hear how things are going on your end!

Posted by & filed under Monthly Report.


Highlights

Metrics

PatternFly Core Repo

  • Members (Forks): 167 (3.7% increase from January: 161)
  • Stars: 558 (3.3% increase from January: 540)
  • Total Pull Requests: 16 (5.9% decrease from January: 17)
  • Merged/Closed Requests: 16 (14.3% increase from January: 14)
  • Submitters: 12 (20.0% increase from January: 10)

PatternFly Angular Repo

  • Members (Forks): 65 (6.6% increase from January: 61)
  • Stars: 79 (2.6% increase from January: 77)
  • Total Pull Requests: 12 (7.7% decrease from January: 13)
  • Merged/Closed Requests: 12 (7.7% decrease from January: 13)
  • Submitters: 9 (80.0% increase from January: 5)

PatternFly Design Repo

  • Members (Forks): 43 (22.9% increase from January: 35)
  • Stars: 20 (81.8% increase from January: 11)
  • Total Pull Requests: 23 (62.3% decrease from January: 61)
  • Merged/Closed Requests: 19 (68.3% decrease from January: 60)
  • Submitters: 12 (7.7% decrease from January: 13)

Site

  • Total Sessions: 11,277 (11.5% increase from January: 10,115)
  • New Visitor Sessions: 4,858 (15.7% increase from January: 4,200)

PatternFly Blog

  • Total Blogs: 2 (0% increase from January: 2)
  • Total Sessions: 1,043 (11.0% increase from January: 939)

Community Meeting

  • Total Participants: 58 (114.8% increase from January: 27)

Communication

  • Mailing List Subscribers: 155 (6.9% increase from January: 145)
  • Twitter: 455 (2.0% increase from January: 446)
  • Facebook: 68 (9.7% increase from January: 62)
  • Google+: 54 (5.9% increase from January: 51)
  • IRC (#patternfly on freenode): 35 (2.8% decrease from January: 36)
  • Slack: 120 (11.1% increase from January: 108)

Posted by & filed under Monthly Report.


Highlights

Metrics

PatternFly Core Repo

  • Members (Forks): 161 (2.6% increase from December: 157)
  • Stars: 540 (3.6% increase from December: 520)
  • Total Pull Requests: 17 (240.0% increase from December: 5)
  • Merged/Closed Requests: 14 (180.0% increase from December: 5)
  • Submitters: 10 (400.0% increase from December: 2)

PatternFly Angular Repo

  • Members (Forks): 61 (5.2% increase from December: 58)
  • Stars: 77 (8.5% increase from December: 71)
  • Total Pull Requests: 13 (51.9% decrease from December: 27)
  • Merged/Closed Requests: 13 (51.9% decrease from December: 27)
  • Submitters: 5 (16.7% decrease from December: 6)

PatternFly Design Repo

  • Members (Forks): 35 (16.7% increase from December: 30)
  • Stars: 11 (10.0% increase from December: 10)
  • Total Pull Requests: 61 (205.0% increase from December: 20)
  • Merged/Closed Requests: 60 (233.3% increase from December: 18)
  • Submitters: 13 (18.18% increase from December: 11)

Site

  • Total Sessions: 10,115 (1.4% decrease from December: 10,259)
  • New Visitor Sessions: 4,200 (16.2% decrease from December: 5,010)

PatternFly Blog

  • Total Blogs: 2 (33.3% decrease from December: 3)
  • Total Sessions: 939 (2.5% increase from December: 916)

Community Meeting

  • Total Participants: 27 (3.6% decrease from December: 28)

Communication

  • Mailing List Subscribers: 145 (2.1% increase from December: 142)
  • Twitter: 446 (9.3% increase from December: 408)
  • Facebook: 62 (1.6% increase from December: 61)
  • Google+: 51 (0% increase from December: 51)
  • IRC (#patternfly on freenode): 36 (5.3% decrease from December: 38)
  • Slack: 108 (10.2% increase from December: 98)

Posted by & filed under Monthly Report.


Highlights

Metrics

PatternFly Core Repo

  • Members (Forks): 157 (4.0% increase from November: 151)
  • Stars: 520 (2.4% increase from November: 508)
  • Total Pull Requests: 5 (62.0.0% decrease from November: 13)
  • Merged/Closed Requests: 5 (62.0% decrease from November: 13)
  • Submitters: 2 (60.0% decrease from November: 5)

PatternFly Angular Repo

  • Members (Forks): 58 (3.6% increase from November: 56)
  • Stars: 71 (2.9% increase from November: 69)
  • Total Pull Requests: 27 (145.5% increase from November: 11)
  • Merged/Closed Requests: 27 (145.5% increase from November: 11)
  • Submitters: 6 (25.0% decrease from November: 8)

PatternFly Design Repo

  • Members (Forks): 30 (50.0% increase from November: 20)
  • Stars: 10 (25.0% increase from November: 8)
  • Total Pull Requests: 20 (50.0% decrease from November: 40)
  • Merged/Closed Requests: 18 (40.0% decrease from November: 30)
  • Submitters: 11 (10.0% increase from November: 10)

Site

  • Total Sessions: 10,259 (3.03% decrease from November: 10,580)
  • New Visitor Sessions: 5,010 (20.7% increase from November: 4,151)

PatternFly Blog

  • Total Blogs: 3 (200.0% increase from November: 1)
  • Total Sessions: 916 (17.1% increase from November: 782)

Community Meeting

  • Total Participants: 28 (0% increase from November: 28)

Communication

  • Mailing List Subscribers: 142 (1.4% increase from November: 140)
  • Twitter: 408 (8.2% increase from November: 377)
  • Facebook: 61 (10.91% increase from November: 55)
  • Google+: 51 (8.5% increase from November: 47)
  • IRC (#patternfly on freenode): 38 (7.3% decrease from November: 41)
  • Slack: 98 (30.7% increase from November: 75)

Posted by & filed under PatternFly.


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.

Migration

The migration steps associated with the above changes are being tracked in PatternFly migration guide and Angular-PatternFly migration guide wiki pages. These migration guides are works in progress, please suggest any additions as you migrate your own applications.

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.

Posted by & filed under Content Views, Table View.


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:

  1. the toolbar is detached from the table
  2. 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:

  1. icon button
  2. 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

Column Visibility Component, collapsed

Expanded state

Column Visibility Component, expanded


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

column visibility, table view 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

column visibility table view 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.

Toolbar for table view

column visibility table view toolbar

Toolbar for card view

column visibility card view toolbar

Posted by & filed under Announcements.


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:

  1. Design patterns
  2. A CSS implementation of those design patterns
  3. Alternate javascript implementations of the behaviours associated with the design patterns
slack-imgs

 

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
  • Scaling design contributions by pioneering a design workflow centered around github
  • Scaling developer contributions with a modular approach in both our CSS and javascript implementations
  • Scaling support for new javascript frameworks
  • Scaling supported devices with mobile considerations in our designs patterns and their corresponding CSS/JS implementations
  • Scaling target audiences with support for internationalisation and accessibility
  • Modernizing PatternFly with style changes around typography, font size, spacing and gradients

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:

  1. A CSS implementation of our design patterns
  2. 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.

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

g10618

Release Timeline

Work has already begun on PatternFly 5. The CSS rewrite is being done in a patternlab instance, check it out at http://www.PatternFly.org/patternfly-atomic/. Get involved with the CSS rewrite in the #css-army channel of the PatternFly slack.

Similarly, work has begun on the webcomponent effort, finalizing the details of our web component prototype. Check it out on github https://github.com/patternfly-webcomponents and get involved via the #webcomponents channel in our PatternFly slack.

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!