Using dropdown in table header and table

[mindytom]

Hey DSYS!

I'm currently iterating on Event Stream's Create New Subscription page, specifically the table. An event type (taskrouter.reservation.accepted) can support n number of schema versions and I'm looking for ways to scale the current design to be more future proof.

Right now I'm exploring ways to:

1. Select x schema version per individual event type
   (i.e. Select version 1 for taskrouter.reservation.accepted)
2. Select x schema version and apply to all event types within the same table
   (i.e. Select version 14 for all taskrouter.reservation event types)

Feedback I'm looking for:

• Usage of the dropdown within the table header and table
• Accessibility concerns?
• Suggestions of using other components?

View concept in Whimsical

[kate-porter]

Hey @mindytom! Thanks for sharing this for feedback. Overall, I think what you have here makes a lot of sense. The only recommendation we would make would be to pull the "Apply schema version to all" select out of the Table header and place it right above the Table instead. This will allow you to give the Schema column a static text header, which will be important for screen reader users.

One question for ya: what happens to the "Apply schema version to all" select when the user has opted to select a different version for some of the event types?

[SiTaggart]

For the error state I was personally thinking that the inline errors for the two inputs would be fine, but if you wanted to inform the user about an error for information in the table, just popping an error toast would probably be the most effective way to do so.

Inline errors are good for single fields, so it works for the inputs. But when there is an error with that gigantic table, it's not really inline anymore. It's such a large piece of UI real estate there's nothing inline about it, it's basically a page error, and showing a toast in that situation might be the most obvious and eye catching way to do it. It's no dependent on scroll position, you can be anywhere in the page and still see a contextual error, you can give it a fair amount of detail to help explain to the user what they need to do next.

[mindytom]

This is what I'm proposing for the error states for this other page Create new sink. I decided not to show an error toast here since there won't be much of a scroll even when we have more sink type cards (~max. 2 rows) with pagination so didn't want to bombard the user with more red on the page if it wasn't needed. I'd like the error patterns to be consistent between the two pages.

From what I understand, these are the two different recommendations I'm reading:

1. Have inline error messages and error toast show for any input, table, and card errors.
2. Have inline error message only for inputs. Have error toasts for tables and cards.
   Am I capturing this right? @katieporter @SiTaggart. Is there a strong stance on either from DSYS?

If that's the case for Recommendation 1, Create new sink page can be a bit overwhelming with red if all inline errors and an error toast showing but this is an edge case. For Create new subscription page, having all inline errors and an error toast show can be helpful wherever the user is on the page.

Recommendation 2, it may seem inconsistent to a user to see inline error messages for some errors but error toasts for others.

[SiTaggart]

The suggestion of a toast only came up due to the sheer quantity of stuff on the page and scrolling depth. Having a little inline error above a very long list of tables might get very lost.

If that's not a concern and you're actually not going to be scrolling so much, then inline errors would be fine from my perspective.

[kate-porter]

Agreed!

[mindytom]

Thank you both for your thoughtful responses.

I'll have both the inline error messages as well as the error toast for the page with the inputs and table. As for the page with the inputs and cards I'll have only the inline error messages.