9

I’m designing a dropdown menu with options that users can name themselves — which means some labels could be quite long. Since this dropdown appears over a screen where it’s important not to obscure other key visual elements, I’ve set a maximum width for it.

However, if an option’s text exceeds that width, the expanded portion of the text will extend beyond the dropdown itself when opened.

Is this a good approach? How would you handle this scenario?

Improve this question
2
  • 1
    Does it really matter if the other visual elements are obscured when the dropdown is open? How long is "long"? A dozen words? Several lines? Commented Aug 12 at 8:58
  • 3
    I would not go with dropdown, but replace it with another custom element like "list with the options" where the whole text can be shown and navigated by scrolling. Implementation can be a list of radiobuttons with labels, those labels can be shortened and the whole text shown with the title trick, or not shortened on mobile. Commented Aug 12 at 18:18

4 Answers 4

Reset to default
14

Here's an example in HTML but you can adapt it to any UI framework. enter image description here

This is a standard HTML <select> list with <option>s, but only a short value is placed as the option, and you can specify a title attribute that presents a full description tooltip on hover. e.g.

 <select title="on the select">
    <option>Short visual text only</option>
    <option title="Full title goes here">Truncated really long text...</option>
    <option title="Angela is stuck in a tricky situation, she thinks Todd is cute, but Marley does this really weird thing where he only eats dessert first and its always ice cream. Who should she go out with? She asked Brenda but Brenda said that Angela should just follow her heart, which wasn't very helpful. In the long run, Angela is likely just goint to flip a coin.">Angela is stuck in a tricky situation...</option>
</select>
Improve this answer
3
  • 5
    Interesting solution (wouldn't have thought title worked in a select), but support on mobile devices is probably pretty bad, isn't it (sorry, too lazy to test myself). Commented Aug 12 at 8:49
  • 1
    @jcaron support on mobile devices for very long select options would likely mean using a framework that displays them as multiline blocks anyway - and even if not, I find it unlikely that a mobile design would have another thing to the right of the select that would be obscured by the long option^^ Commented Aug 12 at 11:54
  • 2
    This option solves better the problem. With the use of ellipsis you can give the context to the users that there is more text and you can show it with the tooltip. For users that use assistive technologies you can use aria-labeldly tags. I strongly recommend to move away from truncating the text in the middle or middle ellipsis because if you are using a screen reader the user is not gonna have context. Even if you try to read the sentences sounds quite odd. Commented Aug 12 at 18:40
5

without more context about what "other key visual elements" your users might want to see while that menu is open, I'll (have to 😉) make some assumptions that I base my suggestion on.

Truncating menu labels is problematic for several reasons. For users, it increases the cognitive load required for making a selection from the menu: They have to learn and remember the work-around for displaying the full labels. They also have to keep the meaning of truncated menu items in short-term memory to compare with the other menu options. Especially for users with neurodivergence that affect short-term memory (such as ADHD), this is very challenging and, thus, not very user-friendly.

Two menus with five menu items each. One menu has several items truncated in the center. In the other menu, all of its items appear without truncation.

This approach also increases developer effort, as they need to implement the truncation algorithm and the work-around interaction.

Hence, what I'd suggest to do instead is to limit the length of text that users can enter to configure the custom menu item labels.

That might be frustrating while defining the labels, but it avoids recurring frustration every time users access the menu. And if you define the allowed label length via user research, you can reasonably assume that that length will work for the majority of use cases.

Let us know what you end up with, and how it tests with your users. 👍

Improve this answer
3
  • Thanks for your answer, it was very informative. I have a problem that, as a first fidelity, I have to lower the effort for development. The list of names is coming from a predefined document from the user, so we wouldn’t be able to add a limit (think of it as a patient document with names of illnesses that the app will pull through as dropdown options still coming from the user but out of our control to limit). Also, translation might add to the length of the words, which is out of our hands. Commented Aug 12 at 0:10
  • Thanks for your thoughtful response and that extra information. In that case, can you do some user research to find out which parts of the labels important? That'd let you more easily decide if the truncation should happen at the center (as suggested by Luke) or at the end, and which method to use for showing the full label. Also, you could learn how much of the other information on the screen must actually be visible while the menu is open. Maybe you can use wider labels after all, depending on what your testers say. Good luck. And again, would love to see what you ended up with. 😎 Commented Aug 12 at 1:02
  • @SaraKarimi when defining the options, you could have a "short" and a "long" versions. The short version would be shown directly in the list. When you select one, the long version is shown. Commented Aug 12 at 8:51
1

You could consider the middle ellipsis option:

Start of a lo … nd of a long name

When the user hovers over the option, it could turn into the kind that animate scrolling left and right.

You would need an alternative representation for screen readers and mobile devices, though.

Improve this answer
2
  • 2
    Middle ellipsis is particularly relevant to content with common (long) prefixes, such as paths, where for example you might need the file extension to choose the right option. Commented Aug 13 at 13:34
  • @PabloH Indeed. The point recently came home when I discovered that OneDrive uses it on Android, and it made my documents folder unnavigable: my filenaming system goes yyyy-mm-dd Title of poem (yyyy-mm-dd), where the first date is that of writing and the latter is that of the most recent edit; I shot myself in the foot by burying the important info in the middle... Commented Aug 13 at 15:32
0

I would not go for a dropdown option in this instance, but implement a selectable list.

Here's a skeleton of implementation in html:

<form ...>
   <fieldset ...>
      <label><input type="radio" ... value="option1">Some long text for option 1</label>
      <label><input type="radio" ... value="option2">Some long text for option 2</label>
   </fieldset>
</form>
Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.