We’re excited to announce a new beta release of PatternFly 4!
PatternFly 4 introduces updates to our visual language along with improvements to modularity, accessibility, and responsiveness. This beta milestone represents the hard work of our Red Hat UXD team combined with fantastic support and feedback from our product teams.
This release includes breaking changes that will potentially impact products that have adopted PatternFly 4. The reason for these changes include absorbing recent brand changes as well as refinements to the architecture. For specifics, you can check out the GitHub Milestones, React release Milestone and Core release Milestone.
In order to help resolve these breaking changes in products as quickly and easily as possible, we have provided information about what has changed as well as direction on how to resolve it in our Core release notes and our React release notes.
We’re excited to announce the beta release of PatternFly 4!
PatternFly 4 introduces updates to our visual language along with improvements to modularity, accessibility, and responsiveness. The beta milestone represents the hard work of our PatternFly team combined with fantastic support and feedback from our product teams.
With this beta, we delivered a prioritized set of HTML/CSS components and also took on a number of infrastructure issues to improve stability across the system.
Interested in getting your hands on the latest and greatest? Check out the PatternFly HTML/CSS workspace to get started. For everyone who has already started using an earlier alpha release of PatternFly 4, heads up: the npm package has changed for beta and you’ll need to change your package.json to point at @patternfly/patternfly.
If you’re kicking the tires on the beta release and have feedback or questions, head over to the PatternFly forum. We always welcome new ideas, so don’t be shy!
The team will continue to develop and deliver new components. Take advantage of GitHub to stay on top of everything we’re working on.
The PatternFly team is always looking for new ways to improve communication with the PatternFly community. A while back, we sent out a survey to get a better understanding of how you want to receive information and share feedback.
We got responses from 22 people, a mix of designers and developers, and discovered that 70% of participants liked the idea of a forum for all things PatternFly.
Why a forum?
It allows you to easily search for information.
It gives you access to old conversations.
It provides the ability to categorize information and organize conversations, making it easier to find what you’re looking for.
Well, you spoke and we delivered! Today, we’re happy to announce the PatternFly forum!
After lengthy discussion, the PatternFly team has chosen React as the JS implementation for PatternFly 4. We want to stress that we will continue to maintain our current PatternFly 3 Angular repos (angular-patternfly and patternfly-ng).
The JS framework question has gotten a lot of attention, so we wanted to talk a bit about how we made our decision and why we think it’s the best way forward for the project.
We chose React based on its popularity within the PatternFly community as well as the broader industry.
We elected to focus on one JS framework because this approach will enable our team to ensure quality design, development, and community support.
The React strategy was discussed at length and we took many factors into consideration. If you’re interested in understanding more of the history and reasoning behind our decision, read on!
We started the patternfly-ng and patternfly-react repos over a year ago in response to rising requests to provide PatternFly implementations for the newer JS frameworks.
At the time, we didn’t have any metrics to help us prioritize one framework over another, and so we made the best choice that we could and decided to add both. Since then, we have evaluated the activity and contributions around the various repos and observed that patternfly-react had become significantly more popular in recent months. We also took a look at observations from the broader industry and factored that research into our decision-making process.
Given all of this, we made the informed decision to take a more focused approach, enabling our team to improve PatternFly 4 and ensure quality design, development, and community support.
A big thanks to the PatternFly community for all of the engagement and interest we’ve been getting around PatternFly 4. Stay tuned for more updates.
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.