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

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: az error or npm error)
  • 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)

Most upvoted comments

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.

image

image

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/color one), but it does not quite work today, we probably use it incorrectly.