Input table columns (select, text field, etc)

[jattasNI]

😯 Problem to Solve

This issue collects use cases for users to input or modify values in a table column.

Use cases

1. a column of nimble-selects to choose which version of software to install (see HLD for Software dialog in SLE Systems app)). In this case there are no requirements for applying the modified value to a server; values are collected to trigger an operation when the dialog is dismissed, not immediately modifying a value in a database. Note: in the legacy table this team hit issues with nimble-select rendering behind other table rows. We should ensure we have a solution for this in nimble-table.
2. a column of nimble-text-field or nimble-number-field to enter a value. This use case comes from one of the LiMo apps

💁 Proposed Solution

[tatwood2]

The Licensing NIC team would like to use this enhancement in our desktop Electron with Blazor application for LiMo when it is ready. Please keep us in the loop as we'd like to uptake it as soon as it is ready.

[atmgrifter00]

@tatwood2, could you provide some details on the way you intend to use editable table cells (i.e., what do you expect to happen when a user modifies a value in a cell, and are you interested in a dropdown, text field, both, or other)?

[tatwood2]

@atmgrifter00, right now we use a text field and add/remove buttons to create a collection of items to use in our API that we display in a table. Instead of having the section outlined in red in this screenshot, the better UI would be to be able to click into a cell and just start typing. Similar to Excel, we'd want the enter key to create a new blank entry for the user to start typing in. We are just interested in a text field.

However, our UI is likely "good enough" for a first pass so we could likely wait a bit for the improvement. Our ideal design is:

1. Add button adds a new, empty table row OR there's an empty row to start typing in and enter creates a new item or there is an add button in the table.
2. Text fields go away; just edit in the table itself.
3. Table rows are individually removable with an ❌ button.
   1. We can probably rename Remove all back to Clear if we no longer say "Remove" anywhere.

[epetersoni]

Is there a rough timeline for implementing this? It seems likely that we'll want editable text fields and dropdowns, although I've seen enough different UX explorations that I'm not certain where we'll land.

[jattasNI]

Is there a rough timeline for implementing this?

It's not part of our Q2 plan. Everything after that is fluid based on client feedback. The more input we get about your requirements and release dates, the better job we can do to prioritize it correctly!

[jattasNI]

@tatwood2 @epetersoni as we're planning our work for next cycle I wanted to check in on this request. There are a few different ideas in this thread and I want to hear which of them would be most useful to you and when you'd need them by.

1. a dropdown column (select?) which is always editable
2. a text field column which is always editable
3. a mode on some column types which lets the user put a cell / row / table into edit mode, make a change, then commit it
4. ability to interactively add / delete / reorder rows

Any votes about which of these is useful to your apps? Or more details about specific column types that matter?

For context, 1 and 2 are likely cheaper to implement while 3 and 4 would require some interaction design work which we could start now to enable delivery later in the year.

[tatwood2]

For Licensing, we are most interested in 2. We already have a workaround for 4 where we have an add row button and use the row context menu for a remove button.

2 allows us the greatest UX improvement so that is our top choice. If we had to wait for 4, I think we'd be okay with that but would need our PM to agree if it wasn't going to happen before start of 2024.

[epetersoni]

1 and #2 sound like a good place to start for our needs. It's looking like we won't start implementing anything until C4, so that's the earliest we might need those features. #4 is something we may want even further down the line. I think we're unlikely to want #3.

[jattasNI]

I updated the description with a new use case for a button column

[jattasNI]

I updated this issue to only cover a column of input fields and I split the button requests into #1582

[jattasNI]

I prototyped a select column in last week's innovation day:

• storybook link
• branch table-column-select

That demo hardcodes the list of options in the column element's template. I did some API brainstorming for how clients would provide the items, which I captured in the markdown spec in that branch.

If the set of items is the same for every row, clients might provide them as children of the column.

If the set of items is different for every row, we might copy the pattern we use for the table's action menu, where the element fires an event just before the menu opens so that the client can dynamically populate the options for that row. We would still need a way to use the table data to specify anything that's always visible: currently the selected item's display text and disabled state (but possibly also icons / groups in future).

In both cases I propose the client would be responsible for responding to a selected item changing by updating the data array (or not).