Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error messaging: prompt for feedback #276

Open
eyelidlessness opened this issue Jan 16, 2025 · 0 comments
Open

Error messaging: prompt for feedback #276

eyelidlessness opened this issue Jan 16, 2025 · 0 comments
Labels
design/architecture Error messaging Conveying error conditions to users

Comments

@eyelidlessness
Copy link
Member

As part of a broader overhaul around errors (categorization/modeling, reference in types e.g. as a Result type, documentation of potential errors associated with a particular flow, etc), we should think about ways to associate a specific error condition with a prompt for user feedback about that error.

Background detail

I'm opening this as a stub issue and can flesh it out further if it's unclear. It comes up now in the context of rolling back some overly ambitious changes in #273, introducing support for non-string selects.

That functionality exceeds the current XForms spec. We originally decided to merge it anyway, but reconsidered after realizing it could cause problems downstream (e.g. conflicts between multiple typed <select> values and database schemas derived from <bind type>). We have decided for now to roll back that behavior, and to produce an error for forms which define a non-string bind type for:

  • <select>
  • <select1>
  • (Pending) <odk:rank>

Discussing that decision, we talked about having the error messaging prompt for feedback, so we can get a better sense of user intent if the error does occur. My initial change will include language to welcome feedback, but stops short of including a link to provide feedback. I believe there should be more design around how we model something like that, and it intersects with other pending work around how we produce errors throughout the Web Forms project. I'm filing the issue now so I can link back to it in JSDoc for the corresponding stub error type.

(TODO: should we maybe try GitHub's "sub-issues" feature to organize issues on the broader topic of errors?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design/architecture Error messaging Conveying error conditions to users
Projects
Status: Todo
Development

No branches or pull requests

1 participant