You know what always makes me feel a little nervous? Submitting text for processing.
Take this little example, for instance:
$ for file in *.txt; do mv $file "$file.old"; done;
If I’m typing that at a command line, my expectations that I’ve typed it exactly right the first time are pretty low. In fact, just now I had to try a couple times before I got everything right for that example (I forgot the “do” the first time, and then I had “for $file”). So just before I hit enter I always have a feeling of hope mixed with fear: I hope that I got it right, but I’m prepared to see a disappointing error message and have to try editing my input again before submitting.
Here’s another example:
Phone number:
Is that going to work when I submit the form? Maybe, but I’ve also had plenty of times when a form gave me an error message because I didn’t format the phone number right. So I’m not completely confident that my input is going to be accepted, even though it’s just a phone number.
Fortunately there’s a well known solution to this kind of problem: WYSIWYG. In a WYSIWYG interface, What You See Is What You Get. In other words, the input interface shows you what the output is going to be. So when you hit print in Word, you’re not crossing your fingers that your printout is going to have the right words in italics. You know those words are going to be italicized because Word is displaying them in italics right on your screen. WYSIWYG gives the user assurance that their input has been understood.
Unfortunately, web forms are usually not WYSIWYG. You’re typing into an input box and hoping that you’re not going to get any error messages after you hit submit. This is an unpleasant experience. A lot of web apps could be improved if the input provided feedback as you typed. Today, programmers might try to do some of this by showing error messages next to the input box in real time, or by making a custom UI control. But to me the ideal thing would be to have a nice text input box where I can use native keyboard shortcuts, copy and paste, and tab around, while still being able to have a visual indication that my input is (or isn’t) being understood.
So to make that possible I just started a new mini-project, which I’m calling Rich Text Input.
The goal of Rich Text Input is to provide an enhanced text input box that uses HTML formatting to give feedback about how the user’s input is going to be interpreted. It’s not a rich text editor – the output is still plain text, and behind the scenes the user’s input is still going to a regular <input> element. The purpose of the rich text formatting is to give the user feedback, and give them confidence that their input is going to be understood as intended.
Here are some possible uses:
- syntax highlighting code snippets
- validating credit card numbers, phone numbers, and zip codes
- styling email addresses and tags
If you wrote some code to round-trip the input to the server (like search engine auto-suggest inputs do today), you could do some even more interesting things:
- a tag list in which the color of the tags represents how “hot” they are
- a search engine input where special operators like site:fettig.net are highlighted in a different color
The current code is not at all ready for production. But it demonstrates the concept, and I hope to have it ready for production projects soon. So check it out and let me know what you think of the idea. The project page is here, and the code is on GitHub.