As development on our shiny new design system continues to push forward, we wanted to share a quick update about migration for existing users of PatternFly 3. Let’s dive in.
What’s the plan?
This is the question we get most frequently, and we’re still working to fully flesh out tooling and best practices. Here’s what we know:
PatternFly 4 component documentation will provide information about the PatternFly 3 component it replaces so you can easily map one design system to the other
We’ll provide examples of the PatternFly 3 HTML structure alongside the updated PatternFly 4 code so you see exactly what’s changed
PatternFly-React users will be provided with codemods (scripts) to migrate components from PatternFly 3 to 4
PatternFly 3 and PatternFly 4 will be able to work side-by-side so you can migrate at your own pace
How are we going to address inconsistencies between PatternFly 3 and 4 as different project teams start to adopt the new system?
The UXD and PatternFly teams are exploring avenues to address inconsistencies introduced to applications and the Red Hat portfolio. Investigations are ongoing and we’re making POC’s a priority. Stay tuned.
PatternFly 4 is generating a lot of excitement in the community. A more modular, accessible, and responsive design system will go a long way toward providing a better user experience. Anytime there is something new, that also generates a lot of confusion and uncertainty about the future. We wanted to share a bit more about how PatternFly 4 will impact existing users of PatternFly 3, and how we plan to address those concerns.
Why a full rewrite?
One question we’ve heard a lot is, “Why do you have to do a full rewrite?” The web community has been burned by forklift upgrades. The cost of rewriting a full web application using a new framework is usually daunting enough to prompt users to start looking at what else is out there. This is a normal reaction, but one that can completely decimate an existing community.
So why the full rewrite? PatternFly 3 is based on Bootstrap 3, and the Bootstrap team recently released Bootstrap 4. Since Bootstrap 3 is a float-based layout system and browser capabilities have evolved since it was released, it’s not a tenable long term solution. But migrating PatternFly to Bootstrap 4 would mean a full rewrite for our users, and we’d still be tied to another team’s release cycle with no guarantees that we’re not having this conversation again in a few years. Decoupling PatternFly from Bootstrap was the best decision we could make for our community.
What are we doing to support our community?
We will not abandon PatternFly 3. We are committed to PatternFly 3 long term. This may mean the new PatternFly 4 structure will also have a PatternFly 3 theme, enabling people to maintain a consistent application while they work to migrate. Whatever the solution, we will continue to support all of the people still using PatternFly 3.
We will provide a clear way to use PatternFly 4 alongside PatternFly 3. Using parts of PatternFly 4 should not destroy your application or force you to rewrite everything. Some applications are many years old now, and a full rewrite of things that are working just fine doesn’t make sense for many people. But we still want to make it possible for those teams to leverage and use new PatternFly 4 components. While this has proven technically possible, we also plan to investigate avenues for addressing the visual discrepancies that are introduced by mixing PatternFly 3 and PatternFly 4 to ensure the end user still has a good user experience.
We will provide a simpler migration path for users of the framework repos. One additional benefit we have with PatternFly is the framework repos (PatternFly-React, for instance). They provide a surface that allows us to migrate the HTML/CSS to the new structure with minimal impact to users. While the package the component is coming from will change (allowing PatternFly 3 and PatternFly 4 components to live side by side), the interface should remain consistent.
If you have questions, please contact us via the communication channels listed on our community page. We are also active in the patternfly4-core and patternfly4-react channels on slack. Finally – we are tracking work around migration via GitHub and tagging them accordingly.
Global Accessibility Awareness Day (GAAD) aims to build awareness around accessibility and inclusion for people with disabilities. The goal is to get everyone thinking and talking about how we can build inclusive digital experiences that work for everyone.
We’re so glad it’s GAAD! We thought it’d be the perfect day to update you on some of the progress we’ve been making to improve our own approach to accessibility.
We’ve continued to build on our GMS partnership over the last few months, and in April we hosted our first hands-on design workshop. We gave each student a felt board and several pieces of felt representing different types of web content like navigation, article, or comments. We asked the students to design a webpage, organizing the pieces of felt on their boards in a way that would make it simple for them to navigate on a laptop.
Once they’d had a chance to work as individuals and refine their designs, we asked them to present their boards to their group. All of the students had great insights to share. One student with no vision said that when she uses a website, she visualizes where the content might be rather than only thinking about it sequentially.
Another student with low vision compared the process of designing to a popular computer game, saying “I like to visualize the end product…web design can be compared to visualizing the end structure in Minecraft before starting a design.”
Listening to the students explain their choices helped us gain a better understanding of how they think about and access content on a webpage. These observations will inform our research moving forward.
Making contributions inclusive
Starting today, we’re asking that contributions to the current version of PatternFly meet new accessibility criteria before they can be added to the pattern library. The criteria may seem simple, but they make a big impact:
Recently, we released an alpha.1 of the next major version of PatternFly (learn more about PatternFly-Next in the Roadmap Update). With that alpha, we included the first version of the PatternFly accessibility guide, providing techniques and suggestions to help design, develop, and test UIs to ensure that everyone has a good user experience.
We’re committed to improving our approach to accessibility and learning more every day. As we build on our approaches, we hope we’re able to help PatternFly designers and developers build accessibility into components and products from the beginning of a project to support an inclusive and accessible user experience.
GAAD is about education, conversation, and sharing, so we’d love to hear about your own approach to and experience with accessibility in the comments below! And don’t forget to share this post to help us spread the GAAD word.
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 firstname.lastname@example.org 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.