Background
The chip input in the Add/Edit List modal is hard to use beyond a handful of values: values can't
be copied or edited in place and are hard to search, bulk pastes are hard to verify, and duplicates
are dropped silently. (Applies to experiments, feature flags, segment lists, and Global Exclude.)
Two proposals fix this. Both replace chips with a one-value-per-row list, add search for existing
values, support bulk paste with duplicate feedback, and improve CSV import/export. They differ on
one question:
Should a list's values be managed on a dedicated details page, or inside a larger Add/Edit List
modal?
Options
Option A — List Details page: #3255
A list is created with just its metadata (type, name, description), and Create lands on the list's
new details page. Values are added and managed only there: a searchable table with per-row edit
and delete, plus CSV import/export. Single-value changes apply immediately; bulk operations
confirm first. The list's name in the lists table links to this page; the edit action opens the
metadata modal.
Option B — Larger Add/Edit List modal: #3256
Everything stays in the current modal workflow. The modal grows to hold the searchable value rows
alongside Type/Name/Description, with inline row editing. All changes, metadata and values alike,
stay pending until Save, or are discarded with Cancel. The edit action in the lists table opens
this modal, as today.
Key differences
|
A (#3255) |
B (#3256) |
| Values are managed |
on the list's own details page |
inside the Add/Edit List modal |
| Create a list |
small metadata modal, then add values on the page |
one modal, values included |
| Open an existing list |
click its name |
edit action opens the modal |
| Changes |
apply immediately (bulk ops confirm) |
staged until Save/Cancel |
| Context |
navigates to a page, breadcrumb back |
stays on the current page |
Next steps
Read both issues — each has full mockups and flows. Comment here with your preference and any
concerns. Production data (list sizes, how often lists are edited after creation) would help if
available. Once decided, the other issue will be closed with a reference to this one.
Background
The chip input in the Add/Edit List modal is hard to use beyond a handful of values: values can't
be copied or edited in place and are hard to search, bulk pastes are hard to verify, and duplicates
are dropped silently. (Applies to experiments, feature flags, segment lists, and Global Exclude.)
Two proposals fix this. Both replace chips with a one-value-per-row list, add search for existing
values, support bulk paste with duplicate feedback, and improve CSV import/export. They differ on
one question:
Should a list's values be managed on a dedicated details page, or inside a larger Add/Edit List
modal?
Options
Option A — List Details page: #3255
A list is created with just its metadata (type, name, description), and Create lands on the list's
new details page. Values are added and managed only there: a searchable table with per-row edit
and delete, plus CSV import/export. Single-value changes apply immediately; bulk operations
confirm first. The list's name in the lists table links to this page; the edit action opens the
metadata modal.
Option B — Larger Add/Edit List modal: #3256
Everything stays in the current modal workflow. The modal grows to hold the searchable value rows
alongside Type/Name/Description, with inline row editing. All changes, metadata and values alike,
stay pending until Save, or are discarded with Cancel. The edit action in the lists table opens
this modal, as today.
Key differences
Next steps
Read both issues — each has full mockups and flows. Comment here with your preference and any
concerns. Production data (list sizes, how often lists are edited after creation) would help if
available. Once decided, the other issue will be closed with a reference to this one.