Page MenuHomePhabricator

Streamline & improve tag component TagMultiselectWidget (former CapsuleMultiselectWidget)
Open, NormalPublic

Description

Uses

UsersMultiselectWidgetAPISandboxCategorySelectorMWCategoryWidgetCategory listsActive filter area
ProjectMediaWiki-extensions-NewsletterMediaWiki-extensions-ApiSandboxUploadWizardVisualEditorContentTranslation (CX 2)Edit-Review-Improvements-RC-Page
OOUI WidgetMW UsersMultiselectWidget <- MenuTagMultiselectWidgetCapsuleMultiselectWidgetmwe-upwiz-categoriesDetailsWidget <- CapsuleMultiselectWidgetCapsuleMultiselectWidgetMenuTagMultiselectWidgetMenuTagMultiselectWidget
DetailsT131492T111791T41597T134740T149391
Screenshot
Add
Edit (not directly from the widget, need to open the dropdown T67518)
Remove (not directly from the widget, need to open the dropdown)
Remove all
Click for more (opens the category page)(opens a dropdown with options)
Re-order T108490
Separate input widget

Issues

  • The circled X to remove the tag is too prominent. The main purpose of the tag is to communicate its content, removing it should be a discoverable action but not the main focus of attention. Using a regular "x" would reduce the visual weight, making it less prominent and more consistent with other components. – See proposal in F5667703. Fixed in v0.19.5
  • The vertical space for the tags and the container make the components feel a bit cluttered by so many lines together with not much space around them.While keeping the components compact, they can benefit from some extra space. – Got increased to standard widget 32px height.
  • The overhauled tag component is so much bigger that, when part of an input field, it heightens the field to 40+px. All other input field/dropdown components (only exception SelectFieldWidget with drop area) are at 32px height. See M101 – Declined. TagMultiselectWidget offers a variety of ways to construct it's UI and we stay with the multitude of options right now.
  • The whole editing pattern is not clearly at stake now, but seems like a major pain: No in-place editing of tags, but changing order on clicking the tag. RCFilters once again has a different take there. – TagMultiselectWidget has improved the editing a lot.

Further issues filed as sub-tasks for now

Related Objects

StatusAssignedTask
OpenNone
OpenNone
DuplicateNone
ResolvedVolker_E
ResolvedVolker_E
ResolvedNone
ResolvedMooeypoo
ResolvedPrtksxna
ResolvedPrtksxna
ResolvedMooeypoo
ResolvedVolker_E
OpenNone
OpenNone
OpenNone
ResolvedMooeypoo
ResolvedVolker_E
OpenNone
ResolvedMooeypoo
ResolvedMooeypoo
OpenDaimona
ResolvedMooeypoo
OpenNone
OpenNone

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 17 2017, 10:24 AM

In the current implementation the tag gets editable by clicking the text and removed by clicking the cross. A pattern that makes sense from my standpoint in context of the input field (CapsuleMultiselectWidget).
We also change the cursor hovering the text to a text input cursor to make editability clearer.

The widgets follow the normal button states (link/hover) and I'm not sure about the highlight similar to a menu item highlight here.

In the current implementation the tag gets editable by clicking the text and removed by clicking the cross. A pattern that makes sense from my standpoint in context of the input field (CapsuleMultiselectWidget).
We also change the cursor hovering the text to a text input cursor to make editability clearer.

For inputs it make sense for tags to be editable, although this pattern is supported in many products by allowing only to remove a tag completely. However the current implementation makes changes too abrupt: tag disappears, gets reorderd (if it is not the last), and the text appears to be changed.

By introducing a selected state the transition can be easier to follow (clicking on a tag first makes it selected. In an additional step, clicking on it again, the tag turns into the internal text for you to change it), and it also would allow for more advanced interactions (e.g., rearranging tags, copying them, etc.) without breaking the tag into text.

The widgets follow the normal button states (link/hover) and I'm not sure about the highlight similar to a menu item highlight here.

What I illustrated with the "highlighted tag" example was intended to represent the state where you selected the tag (i.e., clicking on it), not when you hover over it. Hovering should be consistent with buttons as you suggest.

Volker_E renamed this task from Improve tag component to Improve tag component (“CapsuleMultiSelectWidget“).Feb 28 2017, 7:54 AM
Volker_E added a subscriber: Prtksxna.
Volker_E updated the task description. (Show Details)Feb 28 2017, 7:56 AM

@Pginer-WMF To #1 (circled x): Don't you think that on the small space it's a good indicator lowering the affordability to provide the circled close “x“? I've been thinking several times about the just having a normal close icon. The issue is more prominent in the current way of interaction pattern, where the tag element becomes editable after clicking on the label. The user has a choice between two interactions very close to each other, therefore the normal close icon didn't convince me in the current pattern without a bigger change connected to the label editing as well.

Prtksxna updated the task description. (Show Details)Feb 28 2017, 8:29 AM

@Pginer-WMF To #1 (circled x): Don't you think that on the small space it's a good indicator lowering the affordability to provide the circled close “x“? I've been thinking several times about the just having a normal close icon. The issue is more prominent in the current way of interaction pattern, where the tag element becomes editable after clicking on the label. The user has a choice between two interactions very close to each other, therefore the normal close icon didn't convince me in the current pattern without a bigger change connected to the label editing as well.

Part of the proposal is to give more space to the elements. In other contexts where we use the regular "X" users have to click on the regular "X" area too, an that does not seem problematic.

The proposed design for tags was tested in the context of Edit-Review-Improvements, where participants had to click both on the "X" and the label part of the tag, and they did so without we noticing any problem (recordings of those participants willing to share their experience are available form the report deck).

Also the consequences of accidentally removing a tag are not that terrible normally, since those are in a context where those can be added back. Even web browser tabs, where accidental closing has a bigger cost, normally just use a regular "x" by default and they emphasise it (or the surrounding active area) when the user hovers, as a confirmation.

Change 340289 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
CapsuleItemWidget: Add breathing space and use icon instead of indicator

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

@Pginer-WMF To #1 (circled x): Don't you think that on the small space it's a good indicator lowering the affordability to provide the circled close “x“? I've been thinking several times about the just having a normal close icon. The issue is more prominent in the current way of interaction pattern, where the tag element becomes editable after clicking on the label. The user has a choice between two interactions very close to each other, therefore the normal close icon didn't convince me in the current pattern without a bigger change connected to the label editing as well.

We could make things slightly easier for non-touch-screen users by highlighting the button on hover.

(gif should play automatically, click if it doesn't )

We could make things slightly easier for non-touch-screen users by highlighting the button on hover.


(gif should play automatically, click if it doesn't )

I'd be ok for it if we have any indication of there being an issue with this, but I'm not sure there is.

Also, a couple of comments on the specific execution:

  • If we support highlighting each part, changing the background color may be enough, the border seems too much.
  • The areas should give some room to the text for it not being in the very edge.
  • While editing the tag, I'm not sure we need to keep the option to remove the whole element. It can bring more confusion than help.

I'd be ok for it if we have any indication of there being an issue with this, but I'm not sure there is.

Absolutely. The patch that I submitted does not make this change, just sharing the idea.

If we support highlighting each part, changing the background color may be enough, the border seems too much.

You mean the left side border on the close button? That was my initial thought, but the contrast was too little.

The areas should give some room to the text for it not being in the very edge.

For sure, I was being lazy about changing CSS for the demo.

While editing the tag, I'm not sure we need to keep the option to remove the whole element. It can bring more confusion than help.

I am not sure what you mean. I also don't understand what the delete icon on the right of the tags is supposed to do (from the image in the description).

While editing the tag, I'm not sure we need to keep the option to remove the whole element. It can bring more confusion than help.

I am not sure what you mean. I also don't understand what the delete icon on the right of the tags is supposed to do (from the image in the description).

Maybe it was just my interpretation of the gif. I thought that clicking on the label made that part editable. But what I first identified as the text caret was probably a glitch of the border appearing. The text cursor and the label becoming surrounded by borders contributed to the confusion making it look like a text field.

Maybe it was just my interpretation of the gif. I thought that clicking on the label made that part editable. But what I first identified as the text caret was probably a glitch of the border appearing. The text cursor and the label becoming surrounded by borders contributed to the confusion making it look like a text field.

That is the gif looping at the most confusing moment possible. I am not clicking on anything.

@Pginer-WMF, could you also take a look at this from the perpective of mw.widgets.CategorySelector. Its requirements are listed on T147811: Unify mw.widgets.CategorySelector and ve.ui.MWCategoryWidget, and specifically in my comment.

Change 340289 merged by jenkins-bot:
[oojs/ui] CapsuleItemWidget: Add breathing space and use icon instead of indicator

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

Change 341494 had a related patch set uploaded (by prtksxna):
[oojs/ui] CapsuleItemWidget: Add breathing space and use icon instead of indicator

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

Prtksxna edited projects, added OOUI, Design; removed Patch-For-Review.Mar 13 2017, 9:30 AM
Prtksxna updated the task description. (Show Details)
Prtksxna added a subscriber: matmarex.

Adding the usage that I could find with details that seemed relevant. Feel free to update and correct.

Volker_E moved this task from Backlog to Next-up on the OOUI board.Mar 13 2017, 11:48 PM

What I take from the discussions so far:

  • Replace the close indicator with close icon to be less prominent (which makes sense as the tag label itself is the main information)
  • At the same time increase the close icon clickable area to at least 20x20px

The inner margin is set in https://gerrit.wikimedia.org/r/#/c/351174/ in alignment with all the other widgets. If we really wanna give the Tag*Widget more inner margin to the TagItems and in-between, we should have good arguments and contextual examples. From current perspective of the proposed patch, I think it fits very well in mixed element forms. Readability is given. As general library out-of-the box layout it seems right.
I'd recommend going special ways in applications like RCFilters if needed.

Prtksxna updated the task description. (Show Details)Jun 2 2017, 8:24 AM
Volker_E renamed this task from Improve tag component (“CapsuleMultiSelectWidget“) to Improve tag component (“TagMultiselectWidget”, former “CapsuleMultiselectWidget“).Jun 2 2017, 10:33 AM
Volker_E triaged this task as Normal priority.
Volker_E added a subscriber: Catrope.

Change 341494 merged by jenkins-bot:
[oojs/ui@master] WikimediaUI theme: Use icon instead of indicator in Tag-/CapsuleItemWidget

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

Volker_E moved this task from Unsorted to OOUI on the UI-Standardization board.Aug 15 2017, 9:46 PM
Volker_E updated the task description. (Show Details)Dec 19 2017, 9:33 PM
Volker_E updated the task description. (Show Details)Dec 20 2017, 2:03 AM
Volker_E updated the task description. (Show Details)Dec 20 2017, 3:01 AM
Volker_E updated the task description. (Show Details)Dec 20 2017, 3:33 AM
Volker_E renamed this task from Improve tag component (“TagMultiselectWidget”, former “CapsuleMultiselectWidget“) to Streamline & improve tag component TagMultiselectWidget (former CapsuleMultiselectWidget).Dec 20 2017, 2:29 PM
matmarex removed a subscriber: matmarex.Dec 27 2017, 5:12 AM