kasiazjc commented on PR #37298: URL: https://github.com/apache/superset/pull/37298#issuecomment-3877503337
Ok, so I did a bunch of digging in terms of UX best practises and patterns in other BI apps to figure out error patterns that we could use and I am going back to my previous idea of combined error (validation on field + banner in this specific case). A little backstory and context (and maybe a start on design guidelines) - in terms of an error types I think these three types make sense for us in general: ## Validation Error Only _When:_ Standard form validation, doesn't block entire workflow. SQL Lab examples: - Required field empty - Invalid input format - Character limit exceeded Why field-only: Error and fix are in the same place. ## Alert Banner Only _When:_ Not tied to a specific field, or system-level issue. SQL Lab examples: - Session expired - Network issues - Workspace permission denied - Query timeout - Result set too large Why banner-only: No field caused it, no field can fix it. ## Validation Error + Alert Banner _When:_ Field-specific issue blocks the workflow, user can resolve it. _Components:_ Validation error state on field + persistent banner above SQL editor with action link SQL Lab examples: - Database requires OAuth (our case) - Invalid/deleted schema selected - Catalog needs configuration Why both: Field shows what's wrong in context (which specific selection broke the flow), banner shows impact and how to fix. Persists when modal closes. --- @michael-s-molina I know you are not a fan of combining both, but this is also a pattern that other BI tools use (like Looker or PowerBI) - so showing the error both at the source (the field) and at the impact point (where work is blocked). For our database auth case, the key issue is the flow: user picks a database, sees the auth error in the modal, but might close it without authorizing. If the error only lives in that modal, it disappears. Then they try to run a query and get a confusing failure. With a banner above the SQL editor + field indicator, the error stays visible and they don't have to remember what went wrong or where to fix it. Visually it would look like this (also this would be a placement for the global banner in general) <img width="1748" height="1098" alt="image" src="https://github.com/user-attachments/assets/cd6d7ee6-dbbd-4587-88b7-36742a4b6c93"; /> This is also aligned with UX principles like: - Proximity principle - Errors appear where users can act on them (field validation), while also providing workflow context (banner) - Context at the right time - Field validation when modal is open, banner when user returns to their work area. Handles both interface states cleanly there is also a clear recovery path (where to click - what went wrong), users don't have to remember what exactly went wrong (so this reduces cognitive load). Wdyt? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
