The Case for Expressive Input
September 11, 2020
Machine-like UI = unusable UI
Let’s say you’re designing a mobile app to control and monitor a hardware widget. As the testers and engineers on your team start digging into their work on the widget, they create a control panel to manipulate and test inputs for their purposes. All is fine and good.
However, in the end, the team decided that they had fulfilled the requirement in creating a user interface (perhaps even deeming it as minimally viable). Therefore, they might as well ship it with the product as the interface to be used by 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 go through the trouble of learning 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 in being too “machine-like”, without accounting for human needs, that is when technology fails in usability.
When standard HTML form controls form machine-like interfaces
Along those lines of usability, I believe there are times where the standard HTML5 form controls are too machine-like (or rather, too rigid or data-like) for specific use cases.
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” modes 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, objective, definitive.|
Generally, there is only one correct and precise answer per field.
|Opinionated, subjective, tentative |
The field will contain alternatives, hypotheses, and best guesses, derived from experience, research, and reasoning.
|Precision & Confidence||Quantitative, high precision.||Qualitative. Or when Quantitative, captures a degree of confidence.|
|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.
How the idea came about
I realized the need for Expressive Input 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 several learning modules. In each module, the entrepreneur provides 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 to pitch to investors.
Bridge for Billions also has requirements of collaborative content written by multiple authors, which adds another dimension and comes with its own set of explorations. That is an exploration for a future date.
Next Step: Explore “expressive” controls
Next, I’ll consider what a core set of “expressive” controls might look like and how they might behave, using the above table as guidelines.