Page MenuHomePhabricator

Menu: Evaluate improvements to scrolling UX
Open, Needs TriagePublic

Description

Background

When the Menu displayed from any trigger element (e.g., Select, Combobox, MenuButton) contains a scroll, there are some aspects to consider for improving its experience:

  1. Since the scrollbar appears when start scrolling, it may not be immediately clear that the menu is scrollable.
    Grabaciondepantalla2024-06-25alas17.29.36-ezgif.com-video-to-gif-converter (1).gif (476×600 px, 356 KB)
  2. The current behavior keeps the scroll position when the Menu is closed and reopened.
    CleanShot 2024-06-25 at 15.02.01.gif (693×800 px, 959 KB)

User stories

  • As a user, I need a clear indication that a Menu is scrollable so I can see that there are additional hidden options available.
  • As a user, I need the Menu to always open starting from the first available option.

Possible solutions

Indicate that the menu is scrollable
  • Op.1: We could display half of the last menu item. This visual cue would indicate that there are more items to scroll through.
    image (12).png (946×920 px, 43 KB)
  • Op.2: Ensure that the scrollbar is always visible inside a menu if there is overflow.
  • Op.3: Include a subtle opacity gradient to blur things at the top/bottom edge (similar to the solution in the Tabs with scroll)
Scroll behavior when the Menu is closed and reopen
  • Solution: The scroll position should reset each time the Menu is closed.

Design spec

Once a component spec sheet has been created in Figma, remove the note stating that the spec is missing and link to the spec below.

Component spec sheet

Guidelines

Once the component Guidelines have been created, remove the note and link to the Guidelines.

Component Guidelines

Open questions

Add here the questions to be answered in order to design and implement the component

Acceptance criteria (or Done)

Design

  • Explore possible solutions to make clearer the scroll within the Menu
  • Evaluate these proposals with the DST and decide on the best approach
  • Design the Figma spec sheet and add it in this task (if needed)
  • Update the component in the Figma library. This step will be done by a DST member. (if needed)
  • Update the component's Guidelines (if needed)

Code

  • Update the component in Codex (if needed)

Event Timeline

For "Indicate that the menu is scrollable", I do think Option 3 aligns with the recently created guidelines for content overflow, which specifically mention:

Fade effects can be used as visual indicators of scroll within a group of elements

Specific to the indication of scroll part:

  1. The OOUI menu's scrolling UX is the same - there is no visual indication of scroll unless the browser you're using adds it.
  2. Scrollbar UI is browser-specific. For instance, in Firefox, the scrollbar displays briefly then disappears if you don't scroll.

All that to say: let's consider carefully before making a change whether a change is really necessary.

CCiufo-WMF renamed this task from Menu: improve scrolling to Menu: Evaluate improvements to scrolling UX.Jun 25 2024, 3:51 PM

All that to say: let's consider carefully before making a change whether a change is really necessary.

I'm in agreement with this. Menu behavior is already pretty complicated (this is the one place in Codex where we decided to outsource some work to a 3rd-party library because of all the edge cases that can come up with floating/positioning elements in this way).

I think that any proposed solution should be weighed against its cost to implement (both the initial work and the added maintenance overhead due to increased complexity), and if the cost/benefit ratio is not convincing then we should hold off from doing this.

I agree we should focus this task on exploring some possible solutions to make clearer the scroll within the Menu and then decide on the best approach in case we finally decide to update the component. So I've updated the acceptance criteria accordingly.