Page MenuHomePhabricator

Bring VectorTabs overflow dropdown menus pattern in sync with other menu behavior (no flipping arrow, open on click…)
Closed, ResolvedPublic

Description

When selecting the more menu or language button in new Vector with JS disabled, the arrow flips.

We're never flipping arrows in menu triggering elements like for example dropdowns. See https://design.wikimedia.org/style-guide/components/dropdowns#states

Acceptance criteria

Following conversation between Jon, Volker and Alex:

  • The arrow should never flip
  • The dropdown menus should not reveal on hover. This is bad user experience. Only on click
  • Clicking outside the menus should close them
  • The above changes should apply to modern Vector only

QA

You will need to use an admin account, or shrink your screen resolution to test this.

  • When selecting the more menu on /classic Vector/ the arrow button should flip
  • When selecting the more menu on /modern Vector/ the arrow button shouldn't flip
  • When selecting the language menu with JS disabled on /modern Vector/ the arrow button shouldn't flip
  • When opening the more menu in /classic Vector/ clicking outside the menu should not close it
  • When hovering the more menu in /classic Vector/ it should display
  • When opening the more menu in /modern Vector/ clicking outside the menu should close it

Sign off steps

  • Create a new task from removing from legacy Vector.

QA Results - Beta

Event Timeline

Change 666758 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/Vector@master] Don't flip the dropdown arrow when open

https://gerrit.wikimedia.org/r/666758

How should the state of the dropdown be indicated instead?

How should the state of the dropdown be indicated instead?

To clarify: currently there are two different ways for the menu to be open:

  1. open via hover (in which case as soon as you move your mouse away the menu will close)
  2. open via click (in which case you can move the mouse away and the menu will stay open)

I assume these are the "states" that you are referring to in your question (please let me know if I'm misunderstanding). The question that comes to mind for me is: does the menu need these two different states, or would it be okay to just have one?

Here's the scenario I'm imagining:

You're trying to publish your edit. How do you access the "Publish" button from here?

As an extra twist, note that clicking the "More" button actually does not close the dropdown – not until you move your mouse away, because it's still opened via hover.

I think it's important for the "More" button to react somehow to being clicked. The arrow flipping was not much, but it was something. (It used to have a better animation, but it was removed.)

Here's the scenario I'm imagining:

You're trying to publish your edit. How do you access the "Publish" button from here?

You close the menu and then press publish, I assume. Are you suggesting that without the arrow flipping people are going to get confused about how to close the menu? If so I think that would suggest that the menu shouldn't have two "open" states — it should work like OOUI menus and only open when you click the button.

Yes.

Removing hover would be a usability regression too.

Why is the current dropdown "bad UI"?

Yes.

Removing hover would be a usability regression too.

Why is the current dropdown "bad UI"?

I assume that question is directed at @Jdlrobson (or perhaps @Volker_E, though it seems like maybe Jon was paraphrasing). I disagree that the flipping of the arrow helps people understand how to close the menu. I also disagree that removing hover would be a usability regression. The hover-to-open functionality is inconsistent with other menus on the site (and is generally non-standard). Having consistent menu behavior, in my opinion, is a bigger usability concern than maintaining these two ways of opening a menu. Anecdotally I've heard editors complain about menus that open on hover, saying it's unexpected and distracting.

@Jdlrobson @Volker_E and myself just chatted about this. Our thinking is:

  1. we should remove the arrow flipping (done)
  2. these menus should not open on hover
    • (Volker can defend/explain this decision from a UI standardization standpoint)
  3. clicking outside of the menu should close the menu
    • (Volker can defend/explain this decision from a UI standardization standpoint)
  4. these changes should be made in legacy vector and vector
    • (from a design perspective the logic is clear: it's a better menu experience and so we should have it everywhere. Jon can speak to this from a tech debt perspective)

However making these additional changes (items 2, 3, and 4) increases the scope, and could potentially lead to some disagreement from people who use (and want to continue using) legacy vector and are accustomed to the hover functionality. Therefore we think this work should be timeboxed. If it's not possible to do the additional work within the timebox, we should de-scope this task to only affect our new language button/menu (meaning all other menus would continue to have flipping arrows, and remain otherwise unchanged).

→ over to @ovasileva for input.

Jdlrobson updated the task description. (Show Details)
Volker_E renamed this task from Do not flip the arrow when dropdown menus are open to Bring VectorTabs overflow dropdown menus pattern in sync with other menu behavior (no flipping arrow, open on click…).Mar 4 2021, 6:49 AM

@Jdlrobson Looks and works great! One small comment for request – and I know we don't have this in checkbox hack behavior either – <esc> key should also close the menu. That'd be not a blocker, as current behaviour is worse, but recommended for accessibility.

@Jdlrobson @Volker_E and myself just chatted about this. Our thinking is:

  1. we should remove the arrow flipping (done)
  2. these menus should not open on hover
    • (Volker can defend/explain this decision from a UI standardization standpoint)
  3. clicking outside of the menu should close the menu
    • (Volker can defend/explain this decision from a UI standardization standpoint)
  4. these changes should be made in legacy vector and vector
    • (from a design perspective the logic is clear: it's a better menu experience and so we should have it everywhere. Jon can speak to this from a tech debt perspective)

However making these additional changes (items 2, 3, and 4) increases the scope, and could potentially lead to some disagreement from people who use (and want to continue using) legacy vector and are accustomed to the hover functionality. Therefore we think this work should be timeboxed. If it's not possible to do the additional work within the timebox, we should de-scope this task to only affect our new language button/menu (meaning all other menus would continue to have flipping arrows, and remain otherwise unchanged).

→ over to @ovasileva for input.

I think we should split this out immediately into the portion necessary for our new language button and the discussion on whether we should change the menus in a separate task, which I would say is out of scope for us right now and can go directly into triaged but future. I would be particularly weary of making any changes to legacy vector and believe this would require a wider consultation with the community. @alexhollender, @Volker_E, @Jdlrobson - does that sound okay?

Yes.

Removing hover would be a usability regression too.

Why is the current dropdown "bad UI"?

Because we don't have popup menus anywhere as standard elements triggered on hover. Not an OOUI dropdown or combobox widget, not the popup widget, not the language settings, not the Echo popups. The only other one is Contributions menu and that hasn't seen any Design input for years.
The VectorTabs overflow menu with the arrow indicator looks similar to a dropdown widget and should behave similar. Having a different interaction pattern is confusing for newcomers and triggering a menu of a trigger element indicated by the dropdown arrow with a click unifies the behavior with standard user/new users' assumption.
Also the current behaviour gets problematic as soon as other elements menus are shown on the page, as user has to return to “More” menu to hide it again.

I think we should split this out immediately into the portion necessary for our new language button and the discussion on whether we should change the menus in a separate task, which I would say is out of scope for us right now and can go directly into triaged but future. I would be particularly weary of making any changes to legacy vector and believe this would require a wider consultation with the community. @alexhollender, @Volker_E, @Jdlrobson - does that sound okay?

Discussed with @Volker_E - language button already has expected behavior so no additional task needed there

Change 666758 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [modern] Usability improvements to dropdown

https://gerrit.wikimedia.org/r/666758

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

You will need to use an admin account, or shrink your screen resolution to test this.

✅ AC1: When selecting the more menu on /classic Vector/ the arrow button should flip


✅ AC2: When selecting the more menu on /modern Vector/ the arrow button shouldn't flip

✅ AC3: When selecting the language menu with JS disabled on /modern Vector/ the arrow button shouldn't flip

✅ AC4: When opening the more menu in /classic Vector/ clicking outside the menu should not close it

✅ AC5: When hovering the more menu in /classic Vector/ it should display

✅ AC6: When opening the more menu in /modern Vector/ clicking outside the menu should close it

Edtadros added a subscriber: Edtadros.

Reassigning due to lack of permissions in prod.

Tested on production - looks good. Menu appears on hover for legacy and on-click for current vector. Resolving.