We want to keep the entire Flier community in the loop about our progress and give everyone an opportunity to get involved. To that end, we’re hosting live updates every two weeks and we encourage everyone to attend.
Each update is an hour. You’ll see demos from various members of the team, and get updates on progress we’re making in areas like visual design, CSS, JS, and interaction design.
Updates are every other Tuesday, and alternate between 9am and 11am to accommodate different time zones.
If you don’t already have an invitation on your calendar and you’d like one, let us know!
CAN’T MAKE IT?
If you’re not able to join the live update, you can find links to all of the replays on our YouTube channel.
Following every demo, we’ll send out a link to the replay along with a survey that you can use to provide feedback and help influence our work, so make sure you join our mailing list if you haven’t already.
In 2017, we posted a roadmap that provided an overview of our vision for the next major version of PatternFly. Since that post, we’ve made big strides towards delivering a more maintainable system that’s easier to use and consume.
As with any project, we’ve had to adapt and refine our strategy in some places, but we’re feeling positive about the shape the system is taking and we’re excited to update you on our progress. Are you ready? I’m ready.
Design systems need to enable both design and implementation to help teams create consistent (and awesome) user experiences. To build a system that better supports both designers and developers, we’re taking our cue from Brad Frost’s Atomic Design and focusing on modularity. That means working to develop self-contained components that can be arranged in any number of ways to build a variety of applications and interfaces.
Implementing CSS in this modular fashion involves a total rewrite, and after careful consideration, the team made the decision to decouple from Bootstrap to more easily maintain the code. Decoupling improves modularity, helps to simplify development and implementation, and gives us complete control over our code, which means we aren’t tied to the Bootstrap release cycles and our codebase can last longer. Overall, we feel like this is the right direction for PatternFly moving forward.
Building applications that work for everyone, regardless of ability, is just the right thing to do. We’re working to bake accessibility into the foundation of our design practice. Check out this blog to learn more about the work we’re doing in this area.
Right now, not all of our PatternFly patterns are responsive. Long story short, people use applications on mobile devices. A lot. We’re working to implement a standard approach to responsive components to address this issue.
We’ve been wearing the same outfit since 2012-ish and it’s time for a change. The visual design team has been doing amazing work to evolve the visual language, building something flexible enough to support a variety of personas and adaptable enough to suit multiple design patterns and front-end technologies.
The team is also planning to deliver a system of reusable assets in the form of a design kit to make it super simple for almost anyone to design beautiful and usable interfaces.
What about JS framework implementations?
We’re glad you asked. This is an area we’ve been talking about a lot. We’re currently investigating ways to bring the PF-React and PF-NG repos over to PatternFly-Next. It’s important to us that we don’t fragment those communities, and our hope is for those repos to be used as a way to simplify migration for teams once PatternFly-Next is ready. More to come in this area in the coming weeks.
We’re still in the early stages, and these things take time. You can stay on top of everything that’s happening, from issues to milestones, in our GitHub. We have our first three alphas planned with more to come soon, so please stay tuned!
The power of the web is in its universality.
Access by everyone regardless of disability is an essential aspect.
-Tim Berners-Lee, W3C Director and inventor of the World Wide Web
Good design isn’t good enough
Great user experiences don’t just happen; they’re designed, tested and refined with the user in mind. Designers aim to build products that are easy to use and understand. But when our designs neglect accessibility, we’ll always fall short.
Millions of people live with disabilities that affect their use of technology. The goal of software accessibility is to remove barriers and create inclusive product experiences that work for everyone, regardless of physical ability. So, how can we build accessibility into the foundation of our design practice?
Becoming inclusive by design
PatternFly provides Red Hat designers and developers with a set of consistent patterns and visual design elements that can be applied across products. With its guidelines, standards, and code, PatternFly makes it possible to scale usable and consistent design across the entire company.
While PatternFly does offer some accessible components today, the team is doubling down on efforts this year to help make Red Hat products more universally accessible. The first step? Understanding the needs and experiences of users.
Meeting Governor Morehead School
Governor Morehead School (GMS) in Raleigh, North Carolina serves the special needs of visually impaired students. In November of 2017, Red Hatters Jenn Giardino and Sara Chizari from PatternFly and Mark Caron from the customer portal team collaborated along with other Red Hat associates to host a workshop at Red Hat’s Raleigh site, where GMS students used assistive technologies like screen readers to interact with Red Hat products and PatternFly components. The results were illuminating.
“When we put our designs in front of people and observe them, … we learn what we can do to make the designs more usable,” said Jenn. ”Being able to put our UIs in front of these students and watch them interact, we figure out what information they’re trying to get out of the application, and what they’re using to navigate the page.”
It’s information we would never get without the help of the Governor Morehead School. And information that changes the way we think about building truly accessible products.
Challenging our assumptions
“I came in with this assumption that screen reader users would use the tab key on their keyboards to navigate a page.” said Jenn. “And so, if it’s keyboard accessible and everything has a text label, it’s going to be accessible to a screen reader user.”
While keyboard accessibility is still important, and having adequate text for purely visual elements is also crucial, this assumption about how a screen reader user accesses a web page didn’t match what the team observed.
“The screen reader is a layer on top of the application—it provides its own set of keys for interacting with page contents, and its own methods for navigating a page. A screen reader user might start by scanning a list of page headings to get an idea of the overall content of the page. If the user knows they need a link, they’ll pull up the list of page links,” she said. “So it puts huge emphasis on writing semantic HTML and having a solid information architecture. If the HTML elements we choose don’t align with the users’ expectations, we could be hiding huge sections of content from them. We’d never know that if we hadn’t had the opportunity to test it.”
Over 10 weeks, Jenn, Mark, and Sara will continue to work with the GMS students to test products and components for accessibility, gaining new and valuable insights from this student community. And the team is committed to expanding their research moving forward.
We built new login pages
We like to make a good first impression. The new login has an updated look and feel, responsive design, and supports a whole bunch of use cases like:
Login from a social media or third party account (like Google or GitHub)
Single sign-on (SSO)
Multi-factor login scenarios
The design document provides guidance on how to handle common errors that might occur during the login process. Check out all the new login pages on our website here: Login Page, Multi-Factor Login, Single Sign-On.
We revised the Filter pattern
The new and improved Filter pattern is more modular and flexible. The basic interaction model for filtering content from a toolbar remains unchanged, but the new pattern explains how you can use a variety of filter triggers to support different use cases. We also introduced two new filter trigger patterns:
We changed the hover color for rows in a List View from light gray to light blue. “But why?” you might ask. Two reasons:
Better consistency between hover styles for lists and tables
To avoid confusion between a hover state and an expanded state for lists that support row expansion
More consistency and less confusion? Double yes!
We improved the recommendations form validation
We updated the Errors and Validation pattern to clarify how and when we should validate the information users enter on forms. The updated recommendations cover how to handle the differences between client-side and server-side validation and when to disable submit buttons.
And so much more!
We made tons of incremental updates and small additions since last fall to improve the quality and consistency of the pattern library and generate new patterns.
We want to give a special shout out to all of the designers who contributed to the work we’ve featured here.
A hearty PatternFly thank you to Kyle Baker, Michael Coker, Jenny Haines, Colleen Hart, Leslie Hinson, Chris Shinn, Haley Wang, June Zhang, Melody Zhong, and Tao Zhu.
Our goal is to recognize all of the contributors who keep PatternFly moving forward. If there’s anyone we missed, please forgive us! And then let us know so we can make a big fuss about them in our next Wrap-Up.
The PatternFly design library is packed with reusable patterns that help designers and developers build consistent and usable product experiences. But it would be nothing without contributions from community members like you!
Like a hand without a glove, we have a growing list of common use cases that aren’t yet covered by a design pattern.
PatternFly relies on the contributions of designers and developers like you to grow and improve the content of our design pattern library. When you make a design contribution, you help improve product usability and consistency with reusable solutions for common use cases.
How can you help?
Check out the list of new design patterns we need help with right now. If you have related designs to contribute or an interest in getting involved, reach out to Matt Carrano at [email protected] or find him on the PatternFly Slack channel.
New pattern requests
File Upload pattern
Add a pattern that will enable a user to upload files in two ways:
We’d like to officially announce that support for Sass has been added as a core feature of PatternFly and is now available in the 3.31.0 release. Many in the community had already been using the PatternFly-Sass package and the concepts behind that repo have been brought into PatternFly core.
We are doing this because many products found that they preferred using Sass instead of LESS for their CSS preprocessor and the community provided PatternFly-Sass needed official support so it wouldn’t fall behind.
How will this impact you?
For Consumers of PatternFly:
If you are using PatternFly css in your website only, this shouldn’t impact you at all. If you are using the less partials instead of patternfly.less or patternfly-additions.less, the mixins file had to be broken into two separate files (mixins.less and bootstrap-mixin-overrides.less) so you’ll need to add a second reference to the bootstrap-mixin-overrides.less file.
Contributors to PatternFly:
Supporting Sass as part of our release means that each contributor to PatternFly core css needs to make sure they build the Sass and include it with their PR for review. The readme explains how to do this here: https://github.com/patternfly/patternfly/#less-to-sass-conversion. Any code reviewers should also ensure that any less changes are accompanied by corresponding Sass changes.
As always, we appreciate feedback on this and any other PatternFly features that have been provided and please either use the mailing list or our slack channel (http://slack.patternfly.org to join) to ask questions. To learn more about how to contribute to PatternFly or how to use it in your project, please see the readme at: https://github.com/patternfly/patternfly or view our website at http://www.patternfly.org.
One of the biggest challenges with web design is understanding typography. Font choice, weight, size, and spacing are all important things to consider when you are setting up type for your website or application.
If you aren’t familiar with the term vertical rhythm, simply put, it’s what keeps vertical spaces, between elements on a page, consistent with each other.
Having a hard time with type?
If you look at this article and you get warm fuzzy feelings from the type, but don’t understand why, vertical rhythm might be for you.
I am a core contributor to PatternFly, a design system for enterprise web applications. We are really excited about our next big CSS release and we’ve been working on a bunch of great new features for it.
One feature we are building out is vertical rhythm.
With PatternFly our goal is to offer a consistent design that is easy to implement. We want our users to feel confident that the overall style is well thought out and considers things they may not have an eye for.
Let’s talk about our PatternFly type
By default PatternFly makes the font choice of Overpass for you, we also consider things like line height, weight and size for paragraphs, lists, and a bunch of other type elements.
Often users will use heading tags based on the style they want, rather than the semantic meaning of the tag. In order to avoid this, we’ve stripped all the styles from the headings and offer classes to style them instead. So you can use that <h1> at the top of your page and apply the .h3 class to get the style you want.
This results in a scenario that is not ideal because our users have to apply classes to all headings for pages that are full of content.
That’s where vertical rhythm comes in.
Using our .pf-vertical-rhythm utility class you can apply it to a wrapper and any encompassing headings will get the weight, size and margin that we’ve defined.
Let’s take a look at some examples.
Below you will see and example of an pretty standard page full of content. I’m sure some of you look at this and don’t know where to start.
Now, let’s look at the same page with a class of .pf-vertical-rhythmapplied to its wrapper:
By adjusting a few styles, we now have a page that looks much better.
Vertical rhythm is not complicated, but it can easily be overlooked if you don’t have an eye for it. We wanted to offer something to our users who would rather rely on a set of predefined rules than come up with something on their own.
By implementing vertical rhythm through out the application you ensure a consistency that your users will be grateful for, wether they know it or not.
This is still a work in progress, we’d love to hear your feedback and suggestions.
Toggle filter addresses the problem of a user frequently accessing filters, repeatedly, and having to select them over and over again. It will allow a user to quickly toggle, an individual filter criteria on and off, and immediately see the results, without having to relocate the filter criteria, via the drop down. It also addresses users knowing or discovering the existing filters and learning what data will be returned when selecting a filter.
User of an application, repeatedly uses, common filtering criteria, and wants to be able to frequently vary the return results of the criteria, without having to open and close a filter and relocate the same filters over and over again.
The requirements stemming from the product that some users comp up with the requirement and send email to the [email protected].
Toggle filter can be used with or without other filter patterns, but the filters cannot be active at the same time.
An application will pre-define the toggle filters.
Toggle filtering will not offer the ability for an end user to define which individual filters are used.
There is a finite number of toggle filters.
Products already using this UI
Currently, customer portal is using similar UI as below:
Toggle filter is a component that enables a user to quickly access a common, singular filter criteria. It is displayed as a toggle button group. The application can use up to 4 quick filter criteria.
Toggle filter used Filter
The toggle filter can be used with or without Filter pattern, however, the filters cannot be active at the same time. When using together with the Filter, the results of the two filters are separate. Toggle filter results are not dependent on the Filter. When a user clicks the toggle filter, after getting a result from the Filter, the previous filtering criteria (pill) and criteria results will be cleared, and replaced by the new results, based on the toggle filter criteria.
1.Toggle filter attributes：The attributes are single select buttons. The toggle filters are not representative of multiple filtering criteria per button. Each toggle button is an “or” command. Only one button can be chosen at a time.The widget style is using the style of the current Patternfly Button Group. See Patternfly button group.
2.Toggle filter used with Filter pattern, toggle filter not in use: When using together with Filter, The filtering results are independent. The widget style will be the same as the current filter UI. Current filter pattern can be found here
3.Toggle filter used with Filter, toggle filter in use: When a user clicks the toggle filter after Filter activated, the previous filtering result will be clear and replaced by the new result.
4.Toggle filter used before Filter : When a user clicks the toggle filter after Filter pattern activated, the previous filtering result will be clear and replaced by the new result.
5. Toggle filter used Filter: In the case that user uses the Filter after having a result from the toggle filter, the filter result will be replaced by the Filter when the Filter is activated.
Please feel free to leave comments on Github: https://github.com/patternfly/patternfly-design/pull/362
List views have been used widely across products. After we did some research about the applications list view (Research could be found here) , we find out that we could update and create some new guidelines for PatternFly. Summarized as following:
1. New Content Layout Template
Currently we don’t have a content layout template for Pattenfly list view pattern. Following is a new layout template to clarify the content order of the list view pattern.
2. Alignment rule and Responsive Rule Improvement
Currently Patternfly have two different list view status:
1. Standard List View
2. Stacked List View ( list-view-pf-stacked)
We redesigned the alignment and responsive rule based on the two above situation:
1. Standard list view alignment – The default alignment for the list view row is vertical center aligned. When the screen size is less than 992px, the list view row will change to top aligned ( the same as stacked list view).
2. Stacked list view alignment – The list view row is top aligned in all screen sizes.
List View Row Change Based On the New Alignment Rule
The second and the third row will change form vertical aligned to top aligned.
3. New List View Row Template
“Date” and “Lable” are common element in application, so we try add some new template to PatternFly.
Please feel free to leave comments and suggestions.