[SDK] No standard error appearance for text fields and other controls

[Matthew Paul Thomas]

[Updated description]

The toolkit does not have a standard error appearance for text fields, other controls, or captions.

The error appearance should be used for fields that you have filled out incorrectly, other controls that have a disallowed state, and captions explaining the problem with individual controls.

Examples:

* If you choose a time in a restaurant reservation system, submit the request, and the server responds that that time is unavailable, the time picker should retain the previous value (so you can see what you chose) but should have the error appearance. A caption should appear below it explaining the problem: for example, “Sorry, 7:30pm is unavailable. Try earlier or later.".

* Similarly, the validity of a checkbox, radio button, switch, etc selection might be too complex or volatile to check on the client side of an app. If the server side responds that the selection isn't allowed, the control should adopt the standard error appearance, and a caption below if necessary.

* Changing the SIM PIN requires entering the current PIN. The phone can't check the correctness of the current PIN with every character you type, because trying an incorrect PIN three times or so will lock the SIM. Instead, it is checked only once you submit the dialog. *Then* if the current PIN turns out to be wrong, that field should get the standard error appearance (maybe a pale pink background, and/or a maroon border, and/or a brief flash), and an explanatory caption below it.

* All the captions mentioned above should have their own consistent error appearance. (Maybe maroon text.)

–––

Desired resolution:

An error state with examples of multiline captions will be added to the SDK UI work underway.

UX fix:
Error handling pattern can be found on in this document: https://docs.google.com/document/d/1rUsPorlYkeetQNYyFWn74mtOY2L4Us53Zx9XujRTPCM/edit

[Zsombor Egri (zsombi)]

TextField has the ability to highlight erroneous input. In order to have it working properly, a validator must be set.

[Zsombor Egri (zsombi)]

The other use cases enumerated should all be solved per application and not by the UI toolkit.

[Matthew Paul Thomas (mpt)]

Solving it per-application would be counterproductive in four ways. First, it would be inconsistent: apps would use slightly different colors and icons, different animations, and different sound effects to indicate input errors. Second, an app hard-coding an error color and/or error icon would risk clashing with a future iteration of the Ubuntu theme. Third, most app developers would not know or bother to provide audio feedback of errors for people who can't see. And fourth, even if an app developer did all of those things perfectly, it would be much more work for them than just setting an error class.

[Cris Dywan (kalikiana)]

It's easy to add an API á la erroneous: true but this will need some design and guidelines to be useful.

[Femma (femma)]

Error handling pattern: https://docs.google.com/document/d/1rUsPorlYkeetQNYyFWn74mtOY2L4Us53Zx9XujRTPCM/edit

[Matthew Paul Thomas (mpt)]

The current draft does not specify any standard error presentation, instead leaving it up to app developers to “Use additional visual indicators such as thicker border to indicate errors”. I think that’s a bad idea for the reasons I gave two years ago. But if that’s the final conclusion, this should be wontfixed rather than marked fixed.