Page MenuHomePhabricator

Clarify & streamline user experience of TagMultiselectWidget variants
Closed, DuplicatePublic

Description

As of v0.21.0 TagMultiselectWidget has landed in OOjs UI.

Current variants/options have oriented on requirements of new RCFilters, existing CapsuleMultiselectWidget and it's usage in production like API:Sandbox.

Issues at point of filing:

  • Aligning padding, min-height and text input position of the widget(s) to all other widgets (last two missing ones)
  • Replacing remove indicator with normal remove icon and add breathing space https://gerrit.wikimedia.org/r/#/c/341494/
  • TagMultiselectWidget inputPosition:outline resembles TextInputWidget, although it's just a readonly container. Also not perfect connection to input. ⇒T163126
  • Is appearance of invalid tags clear? ⇒T183371
  • Define clear (visual) indication of draggable tags ⇒T183368
  • PopupTagMultiselectWidget a good idea from UX standpoint?
  • If tags are editable in single-line input, make it easily understandable for users ⇒T183372
  • TagMultiselectWidget (draggable) shouldn't inherit role=listbox of DraggableGroupElement ⇒T170267

Related Objects

Event Timeline

Restricted Application added a project: UI-Standardization. · View Herald TranscriptApr 13 2017, 10:50 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Volker_E updated the task description. (Show Details)Apr 13 2017, 10:53 PM

Some initial thoughts:

  • I don't think that tags should be editable. I don't think it makes much sense conceptually: if you added the category "sports" to an article by mistake instead of "food", it makes more sense to remove the former adding the later, instead of modifying the "sports" category to become "food". This helps to keep tags simple: one main action/selection and the remove action.
  • When the control is shown with both an input and a tag area, some adjustments can help to make the component look more connected. Adjusting the border radius on the touching corners and avoid the double borders (e.g., removing the bottom border of the tag area), and making the tag area slightly darker using Base90 (#F8F9FA)
CurrentProposed

Some initial thoughts:

  • I don't think that tags should be editable. I don't think it makes much sense conceptually: if you added the category "sports" to an article by mistake instead of "food", it makes more sense to remove the former adding the later, instead of modifying the "sports" category to become "food". This helps to keep tags simple: one main action/selection and the remove action.

I agree, I think editing tags is a weird UX. Adding to this, I think it also adds an unnecessary complication in terms of behavior.

  • If you have a menu, or predefined values, what happens when you click a tag? Is clicking a tag "selecting" the tag, or "editing" the tag? It's unclear.
  • The entire widget behaves as a sort of "select widget" (definitely a group widget) so clicking a tag makes sense if it is a selection (single or multi) but I think that mixing it to be sometimes a select and sometimes an edit can be super confusing.
  • And if we allow for editing - do we allow for editing even when there's also a selection behavior? How do we differentiate the two? Is, in that case, a click 'edit' or 'select'? Is a double-click edit? do we add an action "dotdotdot" menu to items with "edit/select" actions? etc.
  • Even if we allow editing, it gets tricky. Say I edit a tag from "foo" to "bar" - now, the widget rechecks whether "bar" is a legal value. If my widget is not "allowArbitrary" and has a set of allowed values, "bar" might not be a legal term, and so it won't be added. At this point, can I cancel the operation? If we take the editing experience into the input (inline or outline) then canceling, while possible, is really weird, and is basically the same as just adding the widget again. It's just confusing.

Honestly, I think tags are meant to be relatively small displays of data - small enough that having the user delete and re-add is a better experience than edit a tag. We could do something like "on selecting the tag, its text goes into the input" which would make the behavior something like "I click 'foo'" -> "My input shows 'foo'" -> "I edit the word 'foo' in the input to say 'food' and press Enter to re-add it" -> "I can now remove the tag 'foo', or not."

If we decide editing is essential, my personal preference is to make it a feature of the TagItemWidget itself (so you can edit "in place") but that would require an action menu to differentiate "select" action from "edit" action.

  • When the control is shown with both an input and a tag area, some adjustments can help to make the component look more connected. Adjusting the border radius on the touching corners and avoid the double borders (e.g., removing the bottom border of the tag area), and making the tag area slightly darker using Base90 (#F8F9FA)

Beyond the styling suggestions, I'd add that we might want to consider allowing other types of inputs. I've added the technical ability to set the input into any OO.ui.InputWidget so we could, for example, use an InputWidget that is also a LookupElement, etc. However, that creates a couple of interesting issues in itself.

For example, if the input is "inline", then the code (and behavior in general) expects a "simple" input (the code takes the raw this.$input and embeds only that part into the inline element list, to make the input somewhat invisible). I didn't force this choice in the code (you can, technically, choose both 'inputPosition:inline' and 'inputWidget: new OO.ui.SearchInputWidget() for example) but that would, at the moment, look terrible, and break. And since the inline input is constantly being resized (again, to allow for a sort of "hidden" input behavior, so we type as if the entire widget is writeable) then having that widget in that input makes no sense to begin with.

(By the way, the issue that NumberInputWidget is not an actual InputWidget means, in this case, that it cannot be used in the widget as-is, which is pretty bad. We should try to fix NumberInputWidget to be an actual InputWidget)

In any case, I think it's worth considering the actual different behavior we want between inline and outline inputs. Do we want drop-down-menu behavior to be only a feature of the outline input, or do we want to allow that to the inline input as well, like a type-ahead-suggestion feature? That would be more challenging technically, but maybe more consistent UX-wise.

Anyways, I think we should also consider these aspects. They came from CapsuleMultiselectWidget, but that doesn't necessarily mean we should keep them as they are in this new widget.

TheDJ added a subscriber: TheDJ.Apr 14 2017, 9:57 AM

Please also consider carefully how keyboard only, or screenreader users have to interact with these things. They possibly need to know any of the following:

  • The grouping/list that are the tags
  • Content or name of each tag.
  • Type of tag, in case of multiple colours, or logos etc
  • State of the tag: disabled, readonly etc..
  • How to remove one
  • How to add one
  • How to order them
  • How to navigate the autocomplete.
  • How to navigate tag specific menu
From the description:

Captured screens in the wild of (CapsuleMultiselectWidget) shortcomings:

That looks like a screenshot of ve.ui.WMCategoryWidget, not mw.widgets.CategorySelector.

Volker_E updated the task description. (Show Details)Apr 17 2017, 5:15 PM

@Prtksxna You're correct, just resembles how confusing the situation of similar and only different in little bits tag component widgets has become. Updated task description.

Volker_E updated the task description. (Show Details)Apr 21 2017, 4:49 PM
Volker_E triaged this task as Medium priority.Apr 21 2017, 7:25 PM
Volker_E updated the task description. (Show Details)

Merging this with parent task and file sub-tasks on specific issues.

Volker_E raised the priority of this task from Medium to Needs Triage.Mar 17 2018, 8:06 PM