Nested tabs in a table #3559
-
Is there a solution to using nested tabs in tables? Here is a screenshot and video of nested tabs in a Tracking Plan table. In #851, I see you don't support disclosures or expandable/collapsible sections inside tables, and the tree grid has yet to be shipped. Are there recommended design patterns to handle this situation? |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 4 replies
-
Disclaimer: This is a very experimental bot using OpenAI's GPT-4. The answers may not be correct, a human will review the answer and update it if necessary. Sorry, I don't know how to help with that. Here are some similar discussions:
|
Beta Was this translation helpful? Give feedback.
-
One suggestion was to remove the tabs and add a column for the row if there is event versioning enabled. When a user changes the version in the column, the contents of that row change accordingly. Any thoughts/feedback on that design? |
Beta Was this translation helpful? Give feedback.
-
Possible dupe of: #3539 |
Beta Was this translation helpful? Give feedback.
-
Review from today's Office Hours: we talked about basing your solution on the most common use case. If it's typical for most rows to have multiple versions, and more than 2 versions each, it probably makes more sense for you to add a column for swapping versions on each row using a Select. The column would still be present on rows with only one version, that cell just wouldn't have a Select. On the other hand, if it's less common to have multiple versions on a row, you might not want to add the extra column for the edge case of needing to show multiple versions. In that case, a good option would be to just display both versions of the row in two separate rows, without any interaction. Just be sure to label the column appropriately (make it clear that it's "version 2" of the same object as the previous row). Keep us posted on which path you choose! |
Beta Was this translation helpful? Give feedback.
-
Below are 3 proposed solutions for this issue. Option 1 features a version label in the name cell. Option 2a features a select in the name cell. While only 2-3% of tracking plans have event versioning, some of these instances may feature up to 6 versions, which would make using a select preferable to using a series of table rows as shown in Option 1. Option 2b features a separate versioning column with a select. While adding another column takes up screen real estate and could increase cognitive load, the separate versioning column in Option 2b might require the lowest amount of design and engineering effort, so Option 2b is our preferred option. |
Beta Was this translation helpful? Give feedback.
Review from today's Office Hours: we talked about basing your solution on the most common use case. If it's typical for most rows to have multiple versions, and more than 2 versions each, it probably makes more sense for you to add a column for swapping versions on each row using a Select. The column would still be present on rows with only one version, that cell just wouldn't have a Select. On the other hand, if it's less common to have multiple versions on a row, you might not want to add the extra column for the edge case of needing to show multiple versions. In that case, a good option would be to just display both versions of the row in two separate rows, without any interaction. Jus…