The Case for Expressive Input
September 11, 2020
When the standard HTML5 form input controls are not suitable.
The case for the creation of "expressive" input controls.
Associated project: Expressive Input
Let's say you're designing a mobile app to control and monitor a hardware widget. As the testers and engineers on your team started digging into their work on the widget, for their own purposes, 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. Would the users find that engineering interface to be usable?
From my experience, the answer is No. 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 HTML5 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 HTML5 specification) are great for job applications, surveys, account registrations, and the like, there is the case for a family of controls that support a more "expressive" type of input. The table below explores how expressive input compares to the input done on a typical form:
|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. The author could revisit and revise the input at any time.
|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.
I've been thinking about what a core set of "expressive" controls might look like and how they might behave, using the above table as guidelines. I'll link to this post with updates on the project.