Have a clearer unselected state in Calcite List

[CodeBarker]

Description

We've had users share that the unselected state of the calcite list doesnt immediately communicate it is selectable. When one or more items is selected by default it is not as critical, However for lists where there is no default selection it just looks like empty space and users are confused

Acceptance Criteria

Current

Desired

Relevant Info

No response

Which Component

calcite list / calcite list item

Example Use Case

No response

Priority impact

p3 - want for upcoming milestone

Esri team

ArcGIS Map Viewer

[asangma]

I would adjust the design to not look disabled and instead have empty boxes when unselected.

I think it might also be good to apply standard patterns and use square for multi.

[macandcheese]

@asangma Agreed, either using the circle-empty + check-circle-f or square and square-check-f here would clear this up.

[asangma]

@macandcheese I could also see something like an appearance="minimal" or something that would mimic PickList's selection indicators but with an added hover state that shows the check or dot. I can add mockups if that's helpful.

[macandcheese]

We have selection-appearance property which accepts icon or border (https://codepen.io/mac_and_cheese/pen/BaOXxEv?editors=100) - if we need to add another distinct visual we could add an additional value there.

But I think having a default icon that is always present to represent "unselected" would be a good start. It could use a lighter fill to prevent the list from being too visually cluttered with those unselected items.

(May want to adjust the padding here so the selection icons are more equally spaced)

[asangma]

💯

[asangma]

And yeah...the spacing needs some love. :)

[asangma]

Suggested spacing between the selection icon and the text:
Use the same spacing that Button has between its content and icon...and maaaaybeee that spacing could be a little tighter (0.5rem for medium)? 😬

[hcampos-professional]

Another feedback we got, specifically with regards to the selection-appearance="border" was that the focus highlight and the border can cause confusion. When the focus outline is visible, it seems as though the list item is selected.

[Anastasiia-Boleiko]

Hi there👋
Also, some feedback regarding the List component😉.
In our case, we were also playing a bit with styling of the List to adjust it to our needs and realized, that the icon selection-appearance="icon" adds quite a large gap before the label, so we decided to proceed with a selection-appearance="border". But it would be really nice to have an additional "flag" that shows a selection. Just as an idea: add a background (on the screenshot it's a ui-brand with 0.1 opacity).

[RSantosGIS]

From my comment in Teams:

Hey Calcite, good morning. I was wondering, is there a way to get actions in slots for CalciteList to have the same hover behavior as block? Calcite Block only does hover styling on the action, and stops propogation to the parent (so the whole block isn't also hover-styled). List, however, appears to propagate the hover to the parent, which causes the whole list element to be hover highlighted except sibling actions it also creates an unattractive "border" around said sibling, like so (my mouse is hovering the ellipsis action, as indicated by the red dot):

[ashetland]

Figma designs available for updated selection iconography and tweaks to the border selection appearance to retain visibility when focused. Related designs for other components are included for reference. We plan to look more deeply at hover states as part of a future system-wide appearance effort.

[ethanbdev]

Hey all, with this issue the default hover pointer was changed for the list item - would it be possible to keep that and re-visit hover states? Maybe checking with folks?

We have discussed before we have a pattern of using the list item in the style of a button for a flow-like ux. I can try track down other discussions we have had on this

[driskull]

@ethanbdev for the hover to be present, the selctionMode should be set to something other than "none". Otherwise this could be done using CSS token variables.

[ethanbdev]

Related: #6123

[ethanbdev]

@ethanbdev for the hover to be present, the selctionMode should be set to something other than "none". Otherwise this could be done using CSS token variables.

Hey, I linked the issue with the original discussion on this, will that no longer be supported?

[driskull]

@geospatialem maybe we need to discuss this one.

Its odd for a list with no selection to have a hover and pointer.

Maybe we add another selectionAppearance for drill in or "none" or a separate drill in component altogether.

[macandcheese]

Another option here is Menu Items, here is an example from the documentation with Flow / Flow Item and Menu / Menu Item: https://codepen.io/mac_and_cheese/pen/qBvrQOz?editors=1000

[mpayson]

I think the challenge is our apps are using calcite-list like a list of buttons, not as a list of dependent selectable items or non-interactive elements. This pattern is relatively common in our apps right now, and it looks like is part of the Figma designs for this issue (selectionMode="none" has hover and pressed states)

If it's helpful, another area this pattern is used in web analysis is to show a list of input layers, where clicking on the layer should open a dialog to replace that layer, and clicking the slotted "x" should remove that layer from the list

Screenshot

[geospatialem]

Reopening to revert the installation above, and discuss alternatives for future implementation to ensure precious support mentioned in #6700 (comment) and #6700 (comment).

The revert will be part of an upcoming maintenance release targeted prior to R1. cc @ethanbdev @mpayson

[macandcheese]

@mpayson not sure if this changes the selectionMode need, but I do find it strange the List Item itself is triggering that Replace Layer action. It seems like something that could be invoked from an action within the List Item itself:

[github-actions]

Installed and assigned for verification.

[geospatialem]

The default hover pointer change has been reverted and is verified in 2.2.1-next.1 with https://codepen.io/geospatialem/pen/XWGaopO.

A new issue has been created to add a new selection mode in the future, while also supporting the pointer, via #8634.

Closing the above as verified.