Core interface improvement

[fcoveram]

Problem

During the last couple of months, the current interface has carried multiple size and style inconsistencies among components that impact all areas of Openverse. This largely began with the redesign process where base elements were not fully defined and passed through various exploratory iterations, especially before the header redesign when I tested many ideas for the search result and single result layouts.

The design of these elements did not tap into the Tailwind composite approach, and styles were applied per Figma component instead of picking primitive utility values. This situation, at a large scale, created several space and size disparities in the interface that make Openverse looks broken. VButton is the best example of this mistreatment as the current Design Library carries a big variety of buttons.

Because of the range shown above, two buttons with the same padding but different label styles break down the horizontal grid and create an odd off-grid effect.

This problem can be pointed out in certain areas of the interface, but since this design and dev method is basal, it can increase and become unbearable in the long term.

Project and issues related

Project: #415

Issues:

• Add a "nested" group to button to support enable group- styling it in Tailwind #466
• Slightly related: Component: VHeading and VText #546

Proposal description

The problem described above is also caused by text style inconsistencies, but for the spacing aspect of this issue, I propose making two changes.

Auto width and fixed height

The component dimension is one of the main problems with the existing approach, so for that reason, it is crucial to address the change in terms of size, padding, and margin in primary elements.

To reach a consistent layout, I propose setting a fixed value for height and auto value for width in elements made of the VButton component. This size change will make popover items, CTAs, and single buttons more clean and consistent in every place no matter if it has an icon or not.

As the diagram points out, the issue is also caused by a text style consistency. But it is safer to tackle that issue separately.

We already started doing this with the new header where all interface components are set with this spacing rule. All current design elements that form the header have this spacing approach applied, so there is no need to update anything in the main nav but in old parts of the interface.

The components compatible with this update will consider min-widths values to ensure translations and not collapse with label lengths. i18n and a11y should not be compromised.

Specs and documentation

To set a solid point of reference, I also suggest replacing many of the Figma’s button components with a basic one that allows setting all the utility values we need. This new design component generates most VButton elements that nowadays live separately in the Design Library.

Since Figma does not define interface elements by adding style utilities, I created three components for the Filled, Border, and Transparent variants that work for all the buttons shown above in the image. The component does not mirror its code version, but the control shift is what would allow us to create and insert interface elements consistently.

I still envision cases where we will need to create buttons for specific contexts, but with this new spacing and documentation method, the process should be easy and keep visual consistency.

Once updating the Design Library with this new component, we can start revisiting each implementation and clean up the unnecessary styles.

Mockups

Figma file: Core interface improvement

As this ticket suggests a Design Library update, there are no mockups for pages. However, I documented the design and dev change in the following order:

1. Button specs: Size and spacing description of the VButton
2. Figma components: Design components involved in this update that will replace many of the existing ones in the Design Library.
3. Figma editor and outcomes: Main change in the Figma editor and examples of how design elements will look like.

---

Feedback

• What do you think of this idea?
• Am I missing a code aspect that is crucial for the implementation?
• Do you have concerns that have not been addressed here?

[openverse-bot]

Subscribe to Label Action

cc @WordPress/gutenberg-design, @WordPress/openverse

This issue or pull request has been labeled: "🖼️ aspect: design"

Thus the following users have been cc'd because of the following labels:

• WordPress/gutenberg-design: 🖼️ aspect: design
• WordPress/openverse: 🖼️ aspect: design

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[jasmussen]

Generally feels like a pretty solid approach to me.

OV doesn't have to perfectly align with gutenberg in terms of componentry, but since the visuals are already close, and the projects themselves are related, it might still be worth considering. In this case specifically, Gutenberg will be zeroing in on two button sizes, 32px height, and 40px height: WordPress/gutenberg#46734. 40px will also be used for all inputs, where it's tall and graceful. 48 becomes quite tall for inputs.

[fcoveram]

Thanks for the context @jasmussen.

Openverse sets most actions in 32px and 40px elements. 48px has been reserved for the header actions and CTAs in single result views. Since the header is the main nav component, search bar and actions had to stand out and ensure safe target areas, especially in small viewports. So Gutenberg and Openverse are very tied in that vein ✨ .

[fcoveram]

Answering the points shared by @obulat here and here in this ticket to steer the design discussion.

I think we can review each button case by case in the implementation PR, if necessary.

Based on the audit document you shared, I can list the components that are part of this updated and the components exclude from it. Since this change addresses a design documentation change in the Design Library, it makes sense to document this audit in the design file and have quick access to the source-of-truth components in Figma.

These components inherit the VButton specs, but can override some properties.

Great. Then in some cases we will need to override properties. The link that you shared (this one) to see the storybook test you started shows me a 404 error message. I don't know why that's happening.

After doing this I realized that we don't have the "pressed" (and pressed-hovered) states in the Figma file.

This is tricky because not all buttons have an active state. For example, "Switcher" is transparent in resting and has a gray border in hover, but in its active state, it has bg-dark-charcoal as background in resting but bg-dark-charcoal-90 in hover. This screenshot might explain it better.

Do you think there's still value in having the "Primary" and "Secondary" buttons? I think having the matrix of variants, sizes and 'icon-start'/'icon-end' is easier to manage because you can clearly see what the button is. And with Primary, you have to remember what size and color it is. And I don't think it's used in more that 1-2 places, or is it?

I agree with you because of the same reason.

---

Thanks to the audit documentation I started in the design file, I detected a few style inconsistencies in the Figma components that were already fixed. Here is the new version of the Figma components

The Figma components and a craft version of audit are in "iteration 2" page. If you agree with moving the audit to Figma, I will polish and clean up the design file.

[fcoveram]

Iteration 2 (i2)

A new version is done in the design file.

The final Figma components were created in the Design Library and already published to be used. Besides, the following spec sections were created/updated.

1. Button base: It documents the basic size and spacing values that work for all Buttons
2. Button styles: It documents the style characteristics of Filled, Border, and Transparent variants.
3. VButton audit: (as Button variants and Customized buttons sections) It lists the UI components that do and do not require a dev update. It also has UI components that will be updated in the future.

---

Let me know if you @obulat see any inconsistency, error, or lack of definition. Otherwise, I would appreciate your confirmation that the hands-off is correct.

[fcoveram]

I was reviewing the button update of #1049 and detected the following visual effect due to a design decision

Wide buttons

When I started testing paddings in buttons with left and right icon for all height variants, I faced two visual situations: wide and narrow buttons. The main cause of this is the 24px icon on the sides with a ghosty area rooted in the SVG viewport that adds extra pixels to the button component. The effect is subtle, but depending on the button context, the page can look great or uneven.

To correct this effect, we need to change some spacing values in Label, Icon left, and Icon right buttons to reduce the wide effect. Here are the tables in "Component specs" page updated with the new values.

The values in dark are the new ones we need to update, while the gray values are the already developed that don't need udate. This image is only for this comment's purpose and I will update the "Component specs" page once we agree about this change.

What do you think @obulat?

---

Leaving this comment in this ticket instead of #1049 as this one covers the design discussion.

[obulat]

@panchovm, I like this idea! I think it makes all the buttons more standardized. I've adjusted the paddings in #1003, you can view the updated snapshots there.

[fcoveram]

Leaving here a code reflection that impacts design and documentation and comes up to me after reviewing PR #1049

medium and small sizes have the same text style for the label, label bold. However, large variant has description bold style for the label. This decision was because large variant is mostly used as CTA in Single result views, today in a page and in the future in modals, and the only style change is shifting to full-width in smaller breakpoints, as shown in the following mockup.

But on the other hand, the "See results" action in the content settings drawer does not need this text style change. It lives next to another button component and having the same text style in the label reaches more consistency. I also envision similar cases in the future where the screen needs to highlight one action for the page's purpose where it's placed.

That being said, I think the best way to approach this situation is to have label bold style in the label of large variants by default and override the label style to be description bold when it's placed in the single result views. What do you think of this @obulat?

[zackkrida]

I believe the design work in the PR is fully implemented. Closing! Please re-open if I am wrong, @WordPress/openverse-frontend.