azure-dev: UX Explorations: Common Error States
Background
One of the biggest key findings from our usability studies and experience audit is that the current experience does not allow for developers to easily self-correct issues they encounter. This is most frequently observed when users encounter an error or a warning message in the CLI. Often the error message will result in a failed user journey, ending the experience abruptly without the option to take action to resolve the error in context.
Specific error state examples
- https://github.com/Azure/azure-dev/issues/293
- https://github.com/Azure/azure-dev-pr/issues/1207 - this issue is now closed. Created for when we were using environment name for naming Azure resources.
- https://github.com/Azure/azure-dev/issues/191
- https://github.com/Azure/azure-dev/issues/305
- https://github.com/Azure/azure-dev-pr/issues/610
- https://github.com/Azure/azure-dev/issues/211
- https://github.com/Azure/azure-dev/issues/168
- https://github.com/Azure/azure-dev/issues/107
- https://github.com/Azure/azure-dev/issues/1371
- https://github.com/Azure/azure-dev/issues/1400
Hypothesis
We believe we can reduce the amount of end-user journeys that end in failure by providing more actionable and consistent error messages.
- Introduce a common and consistent visual pattern for all error messaging in the CLI (bonus: Warning & Success states)
- Update error messaging to be more human readable, precise, and include instructive advice
- Educate users on why the error occurred so that they can prevent future occurrences
- Wherever possible provide the ability for a user to take action on the error in context
Initial task list
- Explore treatment for errors outside the control of
azd(example:azerror ornpmerror) - Triage and re-produce error state examples listed above (puicchan)
- Discuss error messages captured - identify potential solutions
- Complete design pass at error messages ( @Austinauth )
- Complete design pass at “Design Language” (colors, success, error, warning, hint patterns)
- Feedback session to review error state designs and Design Language
- Update and finalize designs based on feedback provided
- Demo to devs for implementation (get pulse check from Wallace before we demo the designs)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 23 (6 by maintainers)
I think we can implement however best works for you and the eng team. I’ll leave it to you to coordinate!
@rajeshkamal5050
@savannahostrowski, we agreed to break these out 1 by 1 right? I think a lot of these have been addressed or can be addressed by the error state styling guidance.
That being said, I am happy to sit sync with Victor or anyone else working on these on a case by case basis if more guidance/discussion is needed. Especially on things like messaging and hint text.
@Austinauth perfect! Thank you for hearing me out.
For hyperlinks we could differentiate them in NO_COLOR mode by underlining the text. I have seen it done by other terminal commands.
Other than that, NO_COLOR support is just a question of including it in the design. The libraries that we use support NO_COLOR intrinsically (at least the
faith/colorone), but it does not quite work today, we probably use it incorrectly.