Design for List Data Type – Viewing & Editing List

[ppii775]

This is the first of a series of three new discussions for #978 Design for List data type. This discussion focuses on List data type viewing and editing. The next two discussions will dive into List data type setup and filtering/grouping respectively. The Figma prototype that I'm using might contain outdated styles and components beyond the scope of this discussion.

The Problem

Viewing data

1. The user is able to read and identify List values in tables
2. The user can expand an List value that is too long for the cell and see the full contents

Editing List cells

1. The user can add an item to a cell containing a List
2. The user should be able to see errors if adding an item fails for any reason. If the reason is because they've entered invalid data, they should see why the data is invalid.
3. The user can remove an item from a cell containing a List
4. The user should be able to see errors if removing an item fails for any reason.
5. The user can edit an individual List item
6. The user should be able to see errors if editing an item fails for any reason. If the reason is because they've entered invalid data, they should see why the data is invalid.

Possible Solutions

1. Help users identify List data type and the item type.

Solution A: Using column header data type symbols to inform users both the List data type and the item type. Even though this design follows our design language, it can be very confusing, especially for non-technical users who have not used List.

Solution B: A unique design language for List. Since List is quite different from the other data types we've been designing for (correct me if I'm wrong – are there other data types also like "a data type within a data type"?), a unique design language can be used to emphasize the difference and help users understand. However, the design below might be too wordy for a header.

Solution C: A hoverable modal to tell the entire story. This method can help users understand List data type, but they have to be able to discover the hoverable modal.

2. Expanding Lists.

Solution: Users can click "show all" (maybe double-click as well?) to select and expand the cell to see all List items. The visual language will change if a cell is selected to inform users that this List contains individual items with commas as delimiters. However, if the List is very long, I'm not sure pushing everything down is visually pleasing. Excel and Google Sheets both expand the cell in-place – would that be a better option?

3. Editing Lists.

Solution: Using visual cues to help users maintain the List data type format. Once a cell is selected and expanded, users can double-click (or single-click?) to select one item in the List to edit.

If users' input seems to be an entirely different data type, a warning message modal will pop up.

List data type is new to me and feel free to let me know your thought!

[ghislaineguerin]

Thanks, @ppii775. Looks good. Few comments/questions:

• I really like your idea of list/type icons or combining them more than spelling out the type. I wonder if we can optimize the icon combo for space somehow. Can you show how this would be represented when the user opens the column header menu?

• For expanding lists, I like the idea of having a show all button. We might run into some limitations when expanding the actual rows without making all of them the same height. Could we consider some solutions to expand the cell somehow without increasing the row height?

• Let's consider that a list could have tens of items for editing lists. How can we get to a display mode where finding and editing an item or multiple requires less effort from users? My concern is that the variable width and position of the items within the cell might make selection hard.

[ppii775]

Thanks! @ghislaineguerin
What you said makes a lot of sense and I was questioning the same things. I'll post more options to this thread this week.

[ppii775]

@ghislaineguerin @kgodey

• I really like your idea of list/type icons or combining them more than spelling out the type. I wonder if we can optimize the icon combo for space somehow. Can you show how this would be represented when the user opens the column header menu?

This is a great point! Maybe the item type within the list can just show up somehow in the expanded header menu. See below.

• For expanding lists, I like the idea of having a show all button. We might run into some limitations when expanding the actual rows without making all of them the same height. Could we consider some solutions to expand the cell somehow without increasing the row height?

I think a floating cell is better for this. When clicking "show all", the cell will be expanded and selected at the same type. Users can perform list actions immediately after this.

• Let's consider that a list could have tens of items for editing lists. How can we get to a display mode where finding and editing an item or multiple requires less effort from users? My concern is that the variable width and position of the items within the cell might make selection hard.

I don't have a great answer for this with the existing UI/UX. I imagine there are only two states of a cell – selected vs. unselected, and the selected mode should expand list. This way we don't have many varying widths. In terms of finding a list item, I think a search function would be the best.

[kgodey]

I'll defer to @ghislaineguerin on final design opinions, but some brief thoughts.

This is a great point! Maybe the item type within the list can just show up somehow in the expanded header menu. See below.

I like this.

I think a floating cell is better for this. When clicking "show all", the cell will be expanded and selected at the same type. Users can perform list actions immediately after this.

I like this too.

In terms of finding a list item, I think a search function would be the best.

Where would you envision the search function living?

[ppii775]

Where would you envision the search function living?

Probably needs to be a search function for all data in the table – at the top toolbar?

[kgodey]

I think table-wide search is probably out of scope for this issue.

For now, I don't think we need any special behavior for handling long lists – we can open a separate design issue if needed in the future. @ghislaineguerin what do you think?