Page MenuHomePhabricator

Buttons: limit text length with ellipsis when it exceeds the maximum
Open, Stalled, LowPublic

Description

Background goal

The way in which text truncation is handled by Codex buttons doesn't make them fully ready for all scenarios. Particularly those involving especially long translations in narrow screens. In said cases, Codex buttons (as their OOUI ancestors) will overflow their layout.

Screenshot 2023-06-01 at 16.26.01.png (290×852 px, 27 KB)

As decided in T359636: Define an approach to content overflow in Codex components, Button and Select will be a maximum of one text line and use ellipsis truncation in case the text exceeds. The Button's entire text will appear as a Tooltip when hovering the Button.

Considerations

  • This issue originally came from a OOUI task (T165870#8879237): It is not only a matter of removing the property white-space: nowrap; as it appears that, in order to bypass the no-wrap behavior of the OOUI button, we'd have to write separate style modules each time. (see T165870 and T165870#8891653 for further context). Is there any way to fix this also in OOUI in a centralized way?
  • In case we provide a wrapping property, then we should make sure to document the cases in which this prop would be useful, and to indicate that the primary recommendation is to keep buttons' text clear, concise and action-oriented.

Acceptance criteria (or Done)

  • Define the best approach for content overflow in Codex T359636

Design

  • Update the Button component using ellipsis truncation in the Codex Figma library
  • Include maximum limitations in the Button Guidelines

Code

  • Update the Button component in Codex using ellipsis truncation

Related Objects

Event Timeline

Manuel updated the task description. (Show Details)
Sarai-WMDE renamed this task from Make it more convenient to allow button wrapping in Codex to [Needs discussion] Define a text truncation approach for buttons that prevents overflow.Jun 1 2023, 3:12 PM
Sarai-WMDE updated the task description. (Show Details)
Sarai-WMDE updated the task description. (Show Details)

Thanks for creating this, @Manuel @Sarai-WMDE! DST will review and reply with next steps by 7 June.

Related to T310158 - we might want to merge these tasks if they serve the same goal.

Not an urgent fix, but still need to decide on priority.

CCiufo-WMF renamed this task from [Needs discussion] Define a text truncation approach for buttons that prevents overflow to Define a text truncation approach for buttons that prevents overflow.Jun 30 2023, 10:31 PM
CCiufo-WMF renamed this task from Define a text truncation approach for buttons that prevents overflow to Buttons: Define a text truncation approach for buttons that prevents overflow.
CCiufo-WMF updated the task description. (Show Details)
CCiufo-WMF changed the task status from Open to Stalled.Mar 8 2024, 3:38 PM
CCiufo-WMF moved this task from Design Upcoming to Backlog on the Design-System-Team board.
CCiufo-WMF subscribed.

Moving to the backlog until we resolve T359636.

As decided in T359636: Define an approach to content overflow in Codex components, Button and Select will be a maximum of one text line and use ellipsis truncation in case the text exceeds. The Button's entire text will appear as a Tooltip when hovering the Button.

Why was that decided for all contexts, and not just for contexts where there is no other possible solution? I’d like to remind that there are no tooltips on mobile, for example.

El T337865#9791057, @stjn escribió:

Why was that decided for all contexts, and not just for contexts where there is no other possible solution? I’d like to remind that there are no tooltips on mobile, for example.

@stjn as documented in T359636: Define an approach to content overflow in Codex components, wrapping will be used as the base solution for content overflow. However, an ellipse will be used to maintain consistency when component height is essential. This means, we will use ellipse truncation for Button, Select, and Chips in order to prevent inconsistencies in height when they are placed next to each other. Since the recommendation is to use as short text as possible in Buttons, and they have a max-width of 448px, the ellipse truncation in Button should be visible just in extreme cases (possible on small mobile devices). A tooltip will make the text visible in those remote cases, and we could use a native tooltip until T340456: Tooltip: Add Tooltip component to Codex is completed. On mobile, the tooltip could be displayed by pressing the Button

OK, that answers my question I think. Hopefully the use of ellipsis will be as minimal as possible.

CCiufo-WMF renamed this task from Buttons: Define a text truncation approach for buttons that prevents overflow to Buttons: limit text length with ellipsis when it exceeds the maximum.May 14 2024, 9:08 PM

Hi, I found this task while looking into T237244, where it was proposed to allow OOUI buttons to wrap by default. Currently they neither wrap nor apply ellipsis, breaking the layout of some pages on mobile and in some translations on desktop, and it's a fairly common CSS workaround to make them wrap to fix that problem. I wanted to find out why Codex buttons also neither wrap nor apply ellipsis, and I found this task.

It seems to me that wrapping them would be the better default solution to the problem, and I'd like to ask you to reconsider.

I've read T359636, and I agree with the principle that ellipsis can be used to "maintain consistency when component height is essential", but I'm not convinced that having a uniform height of buttons is actually essential. It seems more important to me to display the whole label, even if it stretches the interface a little bit. On mobile in particular there are no hover tooltips, so there isn't a good way to reveal the whole label, since I'm not sure how pressing the button to show its tooltip could work when buttons usually do other things when pressed (even if you made that work, I would find that very unintuitive).

(Applying ellipsis works much better for select dropdowns, since they can always be clicked/tapped to reveal the full label of the selected option.)

I also agree that it's good to "prevent disparities in the heights of element groups", but I don't think that just forcing a single height on all buttons is the best solution. When that's valuable, like in a button group, it can be implemented for that specific use case (and it can be done without applying ellipsis, instead increasing the height of all buttons to match the one that has wrapped text). In most cases, centering the buttons or other elements vertically is sufficient, and they don't really need to have the same height.

Thanks for the long comment @matmarex! Agreeing with most of it, what you've shared above was also my concern (before looking at the comment above) for the approach with Select. We would expand in the currently best scenario overlong labels only in tooltips. Which is a usability issue, that we should prevent.
I could even see dark UX patterns with ellipsis only even though not the best ones out there.

Altogether we should provide users on mobile and desktop a way to access the full Button and Select labels. And keep Product teams accountable for shorter, understandable labels in a multi-language environment.

Thank you @matmarex, I appreciate your valuable feedback. Apart from this proposal to use the ellipsis in Buttons and other form components such as Selects, we're currently using the ellipsis in certain components for consistency and to prevent UI imbalance:

Captura de pantalla 2024-06-06 a las 20.30.15.png (668×2 px, 95 KB)
InfoChips within small elements like Table's columns
Captura de pantalla 2024-06-06 a las 20.31.17.png (312×2 px, 50 KB)
Long text within Tabs

In these scenarios, the only way to show the entire label of these elements is by using a tooltip. As commented above, tooltips can also be used on touchable screens by pressing instead of hovering.

Anyway, if we decide to find a better solution for mobile Buttons, we should apply the same solution in these other components using ellipses, such as InfoChips or Tabs.

With selects it is a bit different since the user at least can click on select and get a full option text (hopefully? you don’t plan to truncate select options, right?). With buttons it is all or nothing. Agree with @matmarex on all of his points.

I've created this separate task T367106 to evaluate the use of ellipses in Buttons. We will work on it once T367101: Publish Tooltip component is completed.

With selects it is a bit different since the user at least can click on select and get a full option text (hopefully? you don’t plan to truncate select options, right?).

Yes that's correct. The options themselves (when the menu is open) would not be truncated with ellipses.

Now that the Codex Tooltip is available, we should work on T364928 to explore how using a Tooltip for truncation would actually behave. Then, we can decide whether we want to revisit the approach for buttons.