33 lines
1.5 KiB
Org Mode
33 lines
1.5 KiB
Org Mode
:PROPERTIES:
|
|
:ID: d6d1f003-5aaa-4a36-867c-02d43cdf2475
|
|
:END:
|
|
#+title: Input data properties
|
|
|
|
How could we describe data that we wish to [[id:9914d09e-99fe-46a6-95be-676c5b78ed90][validate]] and possibly [[id:2ba04972-f498-41c2-970e-a64c7f3f1c3b][sanitize]]
|
|
differently, and present different experiences to end users for providing that
|
|
data?
|
|
|
|
- What causes us to want to trim or prevent leading or trailing whitespace from
|
|
some inputs?
|
|
- What causes us to limit the characters a field accepts?
|
|
- What sort of data would we want to sanitize or otherwise alter /as/ we accept
|
|
it (e.g. accepting but also sanitizing HTML to be stored as trusted HTML)?
|
|
|
|
Is there a good language for describing these categories of data, can we better
|
|
understand what differentiates them, and use that knowledge to build more
|
|
consistent guidelines for UX and input handling?
|
|
|
|
* Trimmable
|
|
#+begin_notes
|
|
Taken from https://experience.sap.com/fiori-design-web/leading-trailing-blank-removal/
|
|
#+end_notes
|
|
** Use field trimming if:
|
|
- The leading or trailing white space is not needed for the business process.
|
|
- The input fields have uniquely identifying business objects.
|
|
- The input fields have a fixed field length.
|
|
** Do not use field trimming if:
|
|
- The use case explicitly requires leading/trailing white space. For example,
|
|
for formatted text such as chats, comments, descriptions, source code, or for
|
|
file names (according to the supported OS behavior).
|
|
- For text areas where users would expect leading white space as a formatting
|
|
tool.
|