The Case for Expressive Input
September 11, 2020
This article discusses when standard HTML form controls do not fit the use case, and makes the case for the creation of "Expressive" input controls.
Associated project: Expressive Input
Suppose you're on a product team making an electronic widget accompanied with a mobile app to control it. Let's say that, as the testers and engineers on your team started digging into their work, they created a control panel to manipulate and test inputs. All fine and good. However, in the end, the team decided that, since the engineering interface checked the box as being "an interface", they might as well ship it with the product as the interface for the end users. What would users think of that engineering interface?
I know from experience that only the most dedicated of users would actually learn how to use the interface. The rest of the users would hate it, fear it, or an unsightly combination of both. Why is that?
When technology persists on being too "machine-like", without accounting for human needs, that is often when technology fails from the perspective of usability.
Along those lines, I believe there are times where the standard HTML 5 form controls are too machine-like (or rather, too rigid or data-like) for certain use cases.
I realized this while designing the collaborative platform for Bridge for Billions in 2015. Bridge for Billions offers an educational platform where entrepreneurs develop their business plans with the guidance of mentors, over the course of several learning modules. In each module, the entrepreneur provide answers to learning prompts, and mentors provide feedback. Along the way, entrepreneurs are encouraged to revise their answers and have discussions with their mentors. Toward the end of the program, the entrepreneur's input would culminate into a business plan that they could then pitch to investors.
While traditional form controls (the standard ones found in the HTML 5 specification) are great for job applications, surveys, registrations, and the like, there is the case for a family of controls that support a more "Expressive" type of input:
|Aspect||Traditional Form Input||Expressive Input|
|Input Content||Factual, quantitative, objective.|
Generally there is only one correct and precise answer per field.
|Opinionated, qualitative, subjective. |
The text will be contain hypotheses and best guesses, derived from research and reasoning.
|Time Spent on Input||Minimize the time and thought given to the form, as long as it’s accurate.||Prioritize quality over time savings.|
|Revisions||Submit and forget|
Contents change occasionally, if at all, perhaps in response to form validation errors.
The author will likely have all the answers that the form asks for up front.
The author may not have all the answers when inputting, needing to discover them along the way.
|Path of Input||Linear|
Zip through and be done.
Ideas come randomly and at various times
|Effect on the Author||Transactional|
It’s just a form to fill, to get on with life.
No effect on person is expected
It’s a canvas or work authored by the user.
Attitudes and thoughts are free to evolve as insights emerge.
|Authorship||Single authorship, with no need for discussion.||Written and influenced by multiple authors and reviewers, often requiring discussion.|
To that end, I've been thinking about the interaction design behind "Expressive" controls, using the above table as guidelines.