Page MenuHomePhabricator

MenuTagMultiselectWidget: Add ways to close the dropdown menu via the entire field and indicator
Closed, ResolvedPublic

Description

Motivation:
The indicator icon is a tempting "click target" for users, but at the same time is just a non-functional overlay element that displays state. This can lead to situations where a click on the indicator expands the menu, but a second click cannot collapse it.


Click on namespaces-field-widget or arrow doesn't close the field when opened.

What we want is a toggle behavior when clicking into the field.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 12 2018, 6:00 PM

@Mooeypoo is this something that fits into your plans as well?
We are running into the situation that we now have a dropdown that stays open (yay!), but that does not give many clues how you can get rid of it again.

Charlie_WMDE renamed this task from MenuTagMultiselectWidget: Add ways to interact with the menu via the indicator to MenuTagMultiselectWidget: Add ways to close the dropdown menu via the entire field and indicator.Feb 26 2018, 11:04 AM
Charlie_WMDE updated the task description. (Show Details)
gabriel-wmde updated the task description. (Show Details)Feb 27 2018, 9:56 AM

Hm, I'm not sure if this should be a global feature. I'm a bit concerned about the behavior of this when it relates to the input. The indicator is inside the input (which is, potentially, a separate issue?) and so clicking the input and having the input focused means you want the menu opened. I'm not sure if there's a good way to set the indicator itself as a closing button to begin with (because it's inside the input) but even if we could technically, I'm not entirely sure that's a good idea - it would be a super tiny click area that, if you miss, is really part of the input so we assume you still want the input focused - and hence, the menu to be open.

I'd like to discuss and flush it out a bit more. Pinging @Volker_E on this one, too, to see how this fits to OOUI design standards?

If we do go for it -- should it only be done to "inline input" or both inline/outline inputs? What happens in an inline-input widget if the tag/bubbles are covering almost the entire line? are they covering the indicator? what happens if we have two rows of tags? Is the indicator lowering towards the bottom or stays up on the first line?

I think we have an issue with the way the indicator operates right now is a bit confusing, we should sort these questions out and then see how to play with opening/closing the menu. We should also consider that clicking the entire tag area means focusing the widget -- this usually means opening the menu, and the focusing behavior happens with both inline and outline input when clicking the tag area. If we change the behavior of the indicator, that whole premise changes too.

In short, I'm not convinced this is expected behavior rather than a confusing one... I think we should discuss this more.

Volker_E added a comment.EditedMar 1 2018, 8:47 PM

I'd want to find a solution that satisfies all, this seems like an edge case though. Issues with/Needs of current experience:

  • Featuring an indicator to stronger represent that there's a menu (if I remember correctly, this was the reason for the indicator question, I can't find the corresponding task right now)
  • Having a way to trigger the menu aside of clicking outside of it when open?!

Our normal patterns are either you've got something “readable” like a dropdown and clicking the full area toggles the menu or you've got something “writable” like an input where focussing opens the menu and choosing or clicking outside closes it – no triggering interactive area.

You could think about a combination of a button additionally to the input element similar to the ComboBoxInputWidget, but with the button triggering and the input choose closing the menu.
In any case, this seems like a very specific UX pattern, that I don't see as a useful addition to the library's defaults.
The other option to consider is, if you really need the indicator as the users are opening the menu when focussing the input. I remember vaguely that this need arose from a user testing session, right?

Another point that I'd like to raise is, that we're nowhere changing the indicator direction. This is in alignment with most OS/browser default dropdown indicators. Also we don't change indicator direction when the dropdown opens to the top or the bottom. So representing a standard, unchanged way seems like a useful compromise.

If it helps, we did something a little different in RCFilters, where we use two changing icons to represent the menu being "openable":

Closed (indicating that it is a menu)

Opened (indicating it's a search)

We don't use an indicator, since it seems the difference in icons is enough to tell the user that clicking the textbox will open a menu (when closed) and that when it's opened it's search box. From then on, clicking outside the menu closes it.

That might solve the usability?

If we do go for it -- should it only be done to "inline input" or both inline/outline inputs? What happens in an inline-input widget if the tag/bubbles are covering almost the entire line? are they covering the indicator? what happens if we have two rows of tags? Is the indicator lowering towards the bottom or stays up on the first line?
I think we have an issue with the way the indicator operates right now is a bit confusing, we should sort these questions out and then see how to play with opening/closing the menu. We should also consider that clicking the entire tag area means focusing the widget -- this usually means opening the menu, and the focusing behavior happens with both inline and outline input when clicking the tag area. If we change the behavior of the indicator, that whole premise changes too.
In short, I'm not convinced this is expected behavior rather than a confusing one... I think we should discuss this more.

hi @Mooeypoo

when there are more tags it looks like this

I don't think the arrow being inline is a concern since it never interacts with the widgets. I would be happy to further discuss the behavior of the menu.
My concern is that when clicking the tag area when it is already in focus something should happen and I think that should be that the menu closes. This is something that the user expects from how other widgets behave and which is something our user tests showed. Currently nothing happens which is problematic.

For me, the bigger question is whether it's actually helpful for the user, though. If I'm inside the input, I need the menu to always appear; Clicking inside the widget (even outside the input) will focus the input -- if we then close the menu, do we want to unfocus the input, too? IF not, it sounds like a recipe for a confusing experience, as the cursor is inside the input but no menu appears.

Honestly, I'm not sure an indicator works in this widget at all; the menu is completely related behavior-wise to the cursor being inside the input, and the widget's focus is too. Even if we do do that, do we want to only attach the indicator behavior to it, or do we want the entire widget (anywhere that isn't a tag or the input) to act the same? If anything I think that might be a better user experience, which, again, means the indicator is basically useless as is.

I am worried of creating a situation where the user has a cursor in the input but no menu, while typing. Or, having the menu hide itself and force the user to click on the input precisely (and the input can be really small in the inline widget style) otherwise the menu and focus won't pop up.

If we have a click area that doesn't focus the input automatically, you may have a situation where your user is having trouble finding the place to click to start. And if you separate the input-being-in-focus from menu-is-opened then you might have cases of mismatch where the user types and the menu is either closed or suddenly opens out of nowhere. Technically, if we do choose to do this, we'll need to decouple and decide exactly where clicks count as "close the menu", and what cases mean "close the menu and blur the input" vs any other.

Finally, I am not 100% sure this is the right behavior as a general widget. If we do add this in, I'd add it as a config option. RCFilters will have to override it otherwise, and it seems like the API sandbox might have to too.

Mooeypoo added a comment.EditedMar 10 2018, 8:33 PM

By the way, if you're looking for what to do when the user clicks the widget outside the input, you can do what RCFilters does: If the click is on a tag, the menu opens and scrolls to the tag. If the click is outside a tag, the menu opens and scrolls to the top item.

Still, though, clicking the widget, anywhere, means the user wants to use it - so the input is focused automatically, and the menu, which is coupled to the input and acts as a filter to the item list in MenuMultiselectWidgets (especially if you disallow arbitrary values) must be opened too.

I'd want to find a solution that satisfies all, this seems like an edge case though. Issues with/Needs of current experience:

  • Featuring an indicator to stronger represent that there's a menu (if I remember correctly, this was the reason for the indicator question, I can't find the corresponding task right now)
  • Having a way to trigger the menu aside of clicking outside of it when open?!

Our normal patterns are either you've got something “readable” like a dropdown and clicking the full area toggles the menu or you've got something “writable” like an input where focussing opens the menu and choosing or clicking outside closes it – no triggering interactive area.

Can you explain to me why this decision was made? I can't think of a good reason to have a different behavior here than the dropdown widgets.

You could think about a combination of a button additionally to the input element similar to the ComboBoxInputWidget, but with the button triggering and the input choose closing the menu.
In any case, this seems like a very specific UX pattern, that I don't see as a useful addition to the library's defaults.
The other option to consider is, if you really need the indicator as the users are opening the menu when focussing the input. I remember vaguely that this need arose from a user testing session, right?

That's correct. We added the indicator because users weren't prompted to click into the field because it didn't look interactive to them.

Another point that I'd like to raise is, that we're nowhere changing the indicator direction. This is in alignment with most OS/browser default dropdown indicators. Also we don't change indicator direction when the dropdown opens to the top or the bottom. So representing a standard, unchanged way seems like a useful compromise.

That's a really good point. I must admit, this has not been on my radar so far. I think this is a pattern that we should follow in our extension as well.

Thanks @Mooeypoo for your input and elaborating on your points. I really appreciate you taking the time to do so. This is not as straight forward as I initially assumed for us, so I would like to discuss this issue with my colleagues on Monday and get back to you here.

Thanks @Mooeypoo for your input and elaborating on your points. I really appreciate you taking the time to do so. This is not as straight forward as I initially assumed for us, so I would like to discuss this issue with my colleagues on Monday and get back to you here.

No problems, I would love to find a way to make this widget the best it can be. You guys are the UX and design experts, I just pitch in with my personal view and experience as a user and as someone who dealt with a lot of edge cases with teh widget.

Y'all have a much better understanding of best practices and how users think, though, so while I lay out my opinions, I do defer to you and @Volker_E for the ultimate decision, of course :)

Can you explain to me why this decision was made? I can't think of a good reason to have a different behavior here than the dropdown widgets.

I initially was going to raise the same question but on the other direction (shouldn't we fix the dropdown widget! ;) but I think there's a bigger concept at hand that may actually summarize my concerns above: The dropdown widgets are mostly and almost always "only" some input that triggers a menu; knowing where to click in order to use it or focus it is obvious, because the box of the input is the widget. You either click in it or out of it, there's not a lot of confusion.

In contrast, MenuTagMultiselectWidget is a much larger widget in scope and in the way that it looks. The widget itself contains the input that gives you the menu and the tag area, and they are all related to one another as belonging "to the widget". So "clicking the widget" is more than "just" clicking the input like it is in dropdown widgets.

Does that make sense? I think this is where my concerns lie. The idea that you click a widget and it should be focused is obvious to me, the main question, really, is "what does it mean clicking the widget" when it comes to the big block of "stuff" that is the TagMultiselectWidget and its children. Clicking inside the box that surrounds the whole widget sounds like the reasonable thing to expect, for me, but the fact that inside that widget you have "stuff" that act differently (like clicking the tags themselves) make this question more complex, for sure.

Jan_Dittrich added a subscriber: Jan_Dittrich.EditedMar 15 2018, 11:17 AM

I see that points

  • "toggeling on click to ↓" leads to a very small target area.
  • "toggeling on click on input/whole bar" leads to a large area but confusion what a click does – setting the cursor or opening/closing

However, the need to explicitly close a large thing on your screen other than clicking somewhere else also makes sense and occurred in our test.

EDIT/COMMENT: I wonder if some of the confusion is due to the fact that "our" dropdown (or whatever it is called") stays open after selecting one of the items in the dropdown instead of closing after clicking, which seems to be the standard behavior (which might have been overwritten because namespace combinations are seen as common)
What is the solution applied in a mobile context? There, I think, the screenspace outside than the expanded multiselect-options-box is very small, and thus a way to close it is even more needed.

Hi @Mooeypoo

what I don't think I understand is, why you see a need for re-focusing the widget when it's already in focus. The only reason why an additional click into the space would make sense to me, is to close the drop-down which is an expected behavior for the user. If it's already in focus, there is no incentive to click it again. The fear of having the cursor active in an inactive field is not what I imagine would happen when clicking the widget but rather a copy of the behavior when the user clicks outside of the field. The focus is lost and there's no blinking cursor.

Also what we realised is that the reason that caused the need for closing the field "inline" is that it doen't close after selecting an item from the list unlike the original OOUI widget. We overrode this behavior because users where inconvenienced by it when selecting multiple namespaces and having to re-open the dropdown after every click. This is probably the primary way to close the drop down in the original widget which we are now lacking.

Although we still see a problem with the behavior for our users for now it's probably best to remove the indicator and keep the functionality the way it is.

I think I would close this ticket for now bearing in mind that @Volker_E and our UX-Team are in contact and working on figuring out how to best handle those types of situations in the future, or rather how to prevent them.

Thank you for all your help and input! It was really helpful to me in understanding where you come from and how to proceed for now :)

Charlie_WMDE closed this task as Resolved.Mar 15 2018, 2:31 PM