Welcome to the first article in a 3-part series, “Enterprise flight series.” This series sheds some light on how to use PatternFly in enterprise products. Before diving into this article, be sure to check out the series introduction article.
Enjoy this charter flight to a brand new experience! Read on to learn about the power of redesigning an enterprise search page experience with PatternFly.
Designing for enterprise products can be daunting — there seem to be countless customer use cases to address, numerous stakeholders to consult with, and multiple teams working in tandem to successfully ship a product’s next release.
However, I’ve found that using an open source design system makes this much easier.
In my work designing for Red Hat’s OpenShift product, I often turn to PatternFly to help me build effective, efficient, and hopefully truly enjoyable experiences.
Background
Red Hat OpenShift is an enterprise-ready Kubernetes application platform that allows you to manage hybrid cloud and multicloud deployments. The Search page in OpenShift’s console UI in particular serves a number of important functions. It allows users to view any resource in the cluster, filter the resource list by name or label, and create an instance of that resource. The original experience addressed the following use cases:
- I want to see and manage resources that don’t have a first-class navigation item. Many custom resources do not show up in OpenShift’s navigation by default.
- I want to create resources that don’t have first-class navigation pages. Today, the primary way to create any resource is by going to its page in the navigation. As previously stated, some resources do not have a dedicated page already.
- I want to filter resources by labels and names simultaneously. Many of our list view pages today do not include the ability to search by label.
Here’s a preview of what that experience looked like:
The Search page allowed users to complete a number of important tasks that were not possible elsewhere in the console. Yet, we heard from customers that they’d like to do even more on this page: I want to be able to see multiple resource types. I want to be able to select several resources and delete them in one flow instead of deleting them individually.
So we took this feedback and started iterating.
Design goal
The goal of the new search page was to allow users to select, view, and take action on multiple resource types at a time. The use cases we wanted to address were:
- I want to see and manage multiple resource types at a time. For example, I want to see all my pods and services at the same time.
- I want to bulk select resources across resource types. For example, I want to select these 3 pods and these 2 services.
- I want to take bulk actions. For example, I want to add a label to those 3 pods and 2 services.
From these use cases, we came up with feature requirements for the new design:
- Add multi-resource selection.
- Add bulk selection.
- Add bulk actions.
- Combine the name and label filters.
Process
Once we had the requirements set, we took the effort into design. The Search page design effort was a huge collaboration between a few teams: OpenShift UX, OpenShift development, and PatternFly.
As the designer on the project, I worked directly in Sketch building the experience. I’d present to our developers and other stakeholders, and based on feedback, bring back to Sketch to update. This of course resulted in a number of iterations and constant communication. We used our regularly scheduled design meetings plus additional feedback calls, demos, and Slack messages.
Challenges
While all that teamwork enhanced our process, we still faced some challenges. But we realized that our creative solutions helped us build an even stronger user experience. Here are some roadblocks we encountered while trying to use PatternFly components out of the box.
Resource dropdown
One of the components that proved challenging was the resource dropdown. We wanted to treat the dropdown component as a filter. More specifically, we wanted it to be multi-select, and we wanted the selection to be shown in filter chips for easy removal. Here is what this looked like using the PatternFly component out of the box:
Why didn’t this design fit our case? Well, there were a couple things we needed to address:
- Chips: The chips were showing within the component itself. This means users could select a large number of resources, causing the component to grow far too much.
- Checks: The checks were on the right side of the dropdown. This makes it difficult for users to tell which resources are selected and which ones aren’t.
The best way to solve these design hiccups? Teamwork!
The PatternFly team came together to talk through the design. After some sharing sessions and discussions, we came up with solutions:
- Chips: Showing the filter chips outside of the component was the best way to display them in this case.
- Checks: Checks on the right side of the dropdown should be used for single-select only — checkboxes were the way to go for multi-select.
So, with a little customization, we built this dropdown:
Attribute-value filter
The attribute-value filter was challenging in a different way. We heard some concern from the development team that it could be confusing to users to filter by name and then change the component to then filter by label. Would users forget that the first filter was applied?
Again, after much discussion, we came to an agreement that with the filter chips, this shouldn’t be an issue. Users could easily see what filters were applied and clear them with one click using the filter chip bar.
These challenges were a couple of many, but hopefully they reflect a little on the huge amounts of collaboration that was required both with the PatternFly and development teams.
Outcome
So after all the meetings, iterations, challenges, and more, we shipped a slew of updates for an even better experience for users. These updates include empty states, filter changes, and more. Here’s what the experience looks like now for OpenShift 4.4:
Lessons learned
With any project, you hopefully walk away with both a huge feeling of accomplishment and a handful of lessons learned to share with the rest of your team. Here are the most important lessons we learned:
- Take an incremental approach. With large projects, always break up big changes into smaller, more manageable pieces. While the design was done in one go, development is much harder to do that way. This means defining the minimum viable product (MVP) for each release. Assuming that not every change will make it in the first round allows you to decide which pieces are most important to get in and in which order. Ultimately, you need to ask yourself: How can we deliver changes that will improve the experience and help us get to the final version without jarring our users?
- Do your research. Do your research into the components you plan on using. It’s easy to see a component and assume it will work for you. Instead, take the time to understand what use cases the component is meant to solve. Does it fit yours exactly? Can you customize it to fit your needs better? All this to say, sometimes components will work perfectly for your design right out of the box, but oftentimes it won’t. That’s when it became crucial for us to bring it to the PatternFly team.
- Communication is key. This holds true for every project, but it’s especially important when working on a large-scale project with a variety of stakeholders. Take advantage of Slack, feedback meetings, GIF-making, demos, and any other tools or spaces where you can collaborate with your stakeholders. This will keep everyone is on the same page and allow you to steadily progress through the project.
Hopefully this gave you some insight into how a combination of open source design and cross-team collaboration can help you build powerful experiences for the enterprise. Look out for the next articles in this series to discover other ways we use PatternFly to deliver effective, efficient, and enjoyable experiences.
We hope you enjoyed your flight! The next one is now boarding.
