The Unconstrained Text Box

Whether on paper or online, the unconstrained text box is the most common type of form input that you’ll find in the wild. Here are a few examples of unconstrained text boxes I just copied from a quick search, one each from paper, hybrid and digital forms:
Examples of Unconstrained Text Boxes
Examples of Unconstrained Text Boxes
In the humble opinion of the author, this should be the form designer’s last resort. This week we’re going to look at the use of text boxes as form fields, and why a little bit of thought and effort up front can greatly improve the quality of your collected data.

Want to get articles like this right to your inbox, every week?
Subscribe Here!

There are many choices you can make when designing a form - there are common form field designs and techniques that are purpose-built for the different types of data that you collect. Your choice could make the form easier or quicker to fill out properly, guide the types of data allowed, and ultimately improve the quality of the data collected.
Conversely if you use only one kind of input for every piece of information your form is collecting: a blank, unconstrained text box with a title; you have given up the most direct place that you as the form designer can control the quality of the data. This means that you will rely more on training users, manual reviews of filled forms, cleaning data sets, or issuing deviations and CAPAs to try to 'fix' data quality issues.
It's much better to collect good data quickly in the first place!

What is an
Unconstrained Text Box

An unconstrained text box is an input area where the user can fill in just about
anything they want
. On a paper form, it’s a plain box with some kind of title. On a digital form, it’s the default text input field provided by whatever framework is being used to build the form.
In either case there’s no local guide or control as to data format or content - it’s up to the filler to figure out what goes into that box based on the title, box size and any context or instruction that comes with the form.

There are

Although I call them ‘unconstrained’, it's worth noting that there are still some constraints to these text boxes. For example, on a paper form, you are practically limited to the size of the space given for that field (i.e. the size of the box and any space around it for marginalia). Depending on the size of the person’s handwriting this may or may not be enough for the information being asked for.
On a digital form there are limits to how much you can enter too (i.e. number of characters it will allow), however it rarely has anything to do with what’s visible nor what’s reasonable for the question being asked. Instead, it’ll be set to whatever default limit is given by the form building software. Other default limitations on a digital input text box might include whether multiple lines are allowed and how many, whether and what you can cut and paste, whether the input may be formatted, if language settings can be changed and whether right-to-left input is allowed.

Ok. So there are these unconstrained constraints...

In general these constraints are not controlling the input in ways that are intentional to the purpose of the form - they’re either implicit to the physical design of the form (how much space there is on a piece of paper?), or due to the limitations or default states of the underlying form technology (what are the defaults? what options do you have for constraining input?).
All these constraints, yet nothing to guide what you actually want from the data!
Why is this a problem in a production facility or laboratory? If I give you a form with an "Age" box on it, shouldn’t it be obvious to the operator which age goes in there? After all, if they’re competent and trained, we shouldn’t have to hold their hand through every form filling, right?

There is a cost to juggling context

Let’s take a look at all the things that the operator needs to keep in their heads to fill in that Age box.
. Which age is being talked about? Your age right now? A subject's age at some other point in time? The number of days since a cleaning solution was made?
. When I said ‘Age’ you probably automatically thought “years”, but depending on the context it might be days, weeks or months.
Precision and rounding rules
. Does the form want 10 years? 10 years and 3 months? or 10.25 years?
So three operators may fill it out in different ways (say, 20.25 years, 243 months and "twenty") and still be
technically correct
, however the data would be less usable without some manual intervention to put it into a consistent format.
You could get around this by training and instruction. However this is a lot of
for the operator to keep in mind while filling out the form, multiplied by all the fields and all the forms that they may be required to interact with.

Here you go on about front-loading effort again...

When you constrain an input to be exactly what is expected, you are front-loading a small amount of cognitive load, taking it off of the operator’s plate.
As long as you don’t make the new input more difficult to use
, these little efficiencies will add up.
On the other end, the more guarantees you can make on the consistency of a dataset, the easier it is to automate parts of the pipeline. As any data analyst or statistician can tell you, there’s often a large amount of data QC and cleanup that’s necessary from a manual data set before it can be properly analysed.

How can we constrain input?

As I mentioned, you have a whole toolbox of ways that you can constrain input on forms, including:
Purpose-built form inputs:
Numbers and Dates should go in fields designed to take those numbers and dates, for example with explicit spaces for number of digits or . That way there’s no question about how to fill in the form. Similarly, when you only have a few options, you should be using things like checkboxes, radio buttons, dropdowns and combo boxes. Don't forget to design for whether multiple options are allowed!;
Providing examples and guides
: Include units (e.g. "kg") or format keys ("mm-dd-yy") in a table header. In digital forms, you can use text-box placeholders or tooltips to show a correct example, units or a format key.
Form validation:
No, not that kind of validation. Digital forms can have additional logic that analyses input data and displays an error when it does not match the expected format. Often this check is done before a page of input is accepted by the system - though more use-friendly schemes are preferred that provide a tighter feedback loop, for example by indicating unexpected inputs as you type.
In general you can and should use a combination of these strategies, but prefer a tighter feedback loop as long as it doesn't get in the way of quick data input. Let them know the format
the user inputs data, highlight problems
they input the data, and finally if at all possible don't allow incorrect input to be submitted.
We'll cover all of these aspects in more detail in future posts.

So when c_an_ you just use an unconstrained text box?

Of course there are times when what you actually want is a bunch of free-form text. For example a description field or commentary to add detail to a process.
Often these are fields that aren't going to be aggregated and processed in an automated fashion. If they are, then you're probably missing an opportunity to constrain the data - and as we've discussed in previous posts constrained data is much more amenable to automation!
Finally, test your forms out with the people who will be using them. Is the form easy to use? Can they think of grey areas or a corner case where the correct answer might not be on the form? If so, maybe you're asking the wrong
in the first place.

There's much more we can write about good form design, testing and maybe even a case for validating forms. I'll cover these and more future posts.
Until then, thanks for reading!
– Brendan

Join Brendan's Beyond Compliance List

Weekly articles on designing, improving, and troubleshooting quality processes for regulated industry professionals from Operations Managers to QA Leaders.
We'll never share your email. Unsubscribe any time.
© 2022 Brendan Hyland. All rights reserved. See our
privacy policy
terms and conditions
Generated by
. About the
icons and images
used on this site.