Flight #2: Updating catalog components [Enterprise flight series]
Welcome to the second article in the “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 and part 1.
Read on to learn about how we created a new PatternFly 4 extension for catalog components and used it to bring an enterprise product (Red Hat OpenShift) more in line with the PatternFly 4 look and feel.
Background
One of the tools Red Hat OpenShift provides is a robust library of operators. These are applications that run on OpenShift and can make management and deployment easier.
Administrators and developers have different permissions in OpenShift. In the case of installing operators, administrators use a catalog called Operator Hub to install operators in OpenShift. These can then be viewed and used by developers in a separate catalog, the Developer Catalog. Developers also use a third catalog, the topology view, to initialize new projects.
Design goal
OpenShift was using a PatternFly 3 extension for many of the catalog components vital for these pages, such as filters and catalog tiles.
Our goal for this project was to transition OpenShift to using a new PatternFly 4 extension based on the old PatternFly 3 one. It wasn’t meant to be a total design overhaul, but one of our stretch goals was to incorporate some new PatternFly 4 styles. As PatternFly 4 has matured, OpenShift has slowly adopted many new React components and begun migrating to the new PatternFly 4 look and feel.
Process
We took a development-first approach on this project. The first step was creating a new extension for catalog view components and refactoring the old PatternFly 3 code to work with PatternFly 4. As a stretch goal, we decided to use an existing PatternFly 4 component, the card, to render the catalog tiles in the new extension. This would allow us to bring in some PatternFly 4 styles without (so we thought) a lot of overhead. Once we had each component developed, we sought feedback from our designers and made some tweaks to the designs in the extension, as well as in OpenShift after we pulled in the new extension.
Challenges
The biggest challenge we faced over the course of this project was from that stretch goal — basing the catalog tile on a PatternFly 4 card. The original PatternFly 3 catalog tile was a fixed width, fixed height rectangle. It truncated data based on character length using a fade effect.
Cards are pretty much the opposite — they’re responsive and flexible containers that don’t have many constraints. We first tried bringing over the truncation approach, but truncation didn’t play well with those responsive containers.
While the card itself varied so much in size, the all-important description never varied in length, leaving people to wonder where the extra information went.
Our final approach was to set a fixed width on the catalog tiles (similar to the original PatternFly 3 tiles), but to use a different method for truncation. OpenShift doesn’t use fades for truncation but instead relies on a CSS property called -webkit-line-clamp. This property lets you pick how many lines of text you want to show and then hides the rest. We decided to use this property for the tiles instead, with three lines for regular operator tiles and one for installed operators.
Outcome
We were able to make design tweaks in Operator Hub, the Developer Catalog, and topology view that brought them more in line with PatternFly 4. We were also able to drop the dependency for the old PatternFly 3 extension.
Lessons learned
While this project was originally pitched as being light on design, it eventually became clear that a more proactive approach to design would have saved us a lot of time.
- Start with design. Even if you’re not designing something from scratch, talking to designers about your use cases and requirements can solve problems before they start. As a developer, I know how to write code. Designers know how to build great experiences. Take advantage of their expertise before you start writing code, and you might not have to write as much!
- Communicate with stakeholders early and often. When we initially started this project, we weren’t even aware of the topology view’s catalog view, since a different team works on the developer’s view of the product. You’ll save yourself time by finding out who your stakeholders are and what your changes will affect.
- Don’t be afraid to iterate. We broke development on this project into small pieces — creating the extension and an initial round of components, making design tweaks to those components, and then doing a series of revisions to the catalog tile. We even brought them into the product in pieces so that we could evaluate their impact bit by bit. This really helped save us time.
Even small tweaks and projects can benefit from design expertise. Cross-team collaboration can save you time and lead to a better result. Don’t be afraid to talk to your design team upfront!
We hope you enjoyed your flight! The next one is now boarding.
