Page MenuHomePhabricator

FilterChip: Evaluate need for a selectable/editable/open state
Closed, DeclinedPublic

Description

Background

In T324223 the MVP FilterChip has been implemented.
We may need to implement in some moment an editable/open state for this FilterChip:

A specific recommendation to clearly indicate this case where the filter is being edited or “open” state is to separate to the “x” close action from the action to open it for editing. Quick sketch of what I mean:

image.png (1×2 px, 131 KB)

Secondly, ideally the menu that is opened should be visually attached/closer to the chip being edited.

@RHo I've created a new version for the selectable/editable/open chip, separating the chip from the remove button as you comment. The remove button could be within a white circle so we can visually separate the chip from the remove:

Chip_Op.3.png (240×3 px, 43 KB)

Known use cases

Captura de pantalla 2023-07-17 a las 12.00.59.png (1×2 px, 746 KB)
Selectable/Editable FilterChip in Recent changes.

User stories

  • As a user, I need to select or edit a FilterChip.

Design spec

Once a component spec sheet has been created in Figma, remove the note stating that the spec is missing and link to the spec below.

Component spec sheet

Open questions

Add here the questions to be answered in order to design and implement the component

Acceptance criteria (or Done)

Design

  • Evaluate need for this state via audit and review of existing use cases.
  • Pending need, design the Figma spec sheet and add it in this task
  • Update the component in the Figma library. This step will be done by a DST member.

Code

  • Implement the component in Codex

Event Timeline

RHo renamed this task from FilterChip: implement selectable/editable/open state to FilterChip: Evaluate need for a selectable/editable/open state.Jul 17 2023, 11:40 AM
RHo updated the task description. (Show Details)

Have we considered implementing an editable chip the same way OOUI did? In that version, if you click on a chip, the chip will disappear and its label will appear in the text input. Then you can change the text and re-add the chip. If there was any text in the input when you clicked on a chip, that text becomes a chip, to ensure it is not lost.

This would be much simpler from a UI standpoint. One downside is that, if the chip you clicked had an icon, we have no way of allowing you to restore that icon. But I'm not sure how much icons will be used with editable chips anyway (seems more useful for things like suggestions to me).

Have we considered implementing an editable chip the same way OOUI did? In that version, if you click on a chip, the chip will disappear and its label will appear in the text input. Then you can change the text and re-add the chip. If there was any text in the input when you clicked on a chip, that text becomes a chip, to ensure it is not lost.

This would be much simpler from a UI standpoint. One downside is that, if the chip you clicked had an icon, we have no way of allowing you to restore that icon. But I'm not sure how much icons will be used with editable chips anyway (seems more useful for things like suggestions to me).

I agree it is unclear if this state is needed at all, since the OOUI way was when the chip is inside of the input and it made sense it turned back into text when editable instead of having an open state. This task seems to stem from the implementation in Recent Changes only as far as I can tell, which is IMO a non-standard application:

If there are no other use-cases found, I think it would be worthwhile checking if the recommendation should instead be to change the RC chips behaviour, so that the chip doesn't open the unconnected filter menu, but is purely for easy removal of filters.

@RHo ah that's helpful context, thanks! I agree that, if this is specific to RCFilters, we should reconsider its design rather than implementing this for a single use case.

If there are no other use-cases found, I think it would be worthwhile checking if the recommendation should instead be to change the RC chips behaviour, so that the chip doesn't open the unconnected filter menu, but is purely for easy removal of filters.

I agree, if there are no other use cases for editable FilterChips I would lean towards redesigning this case instead displaying this unconnected menu.

Design-System-Team discussed this and determined it does not make sense to focus on this use case for FilterChips at the moment.