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 T158400#3036973, @Volker_E wrote:

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.

@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.

See also T119044: TagMultiselectWidget (earlier CapsuleMultiselectWidget): UX and functionality improvements and T159208: Tag-/CapsuleItemWidget: Use icon instead of indicator for the delete button

In T158400#3060347, @Volker_E wrote:

@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

In T158400#3060347, @Volker_E wrote:

@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 )

In T158400#3060534, @Prtksxna wrote:

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).

In T158400#3060623, @Prtksxna wrote:

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

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

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.

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