Wow, almost three years between posts… the life of a contract UX designer! :)
Providing users with a dynamic character count while they enter text into a
textarea form field can save them time and provide direct feedback on how much space they have left to make a comment. Think how frustrating Twitter would be if you couldn’t see how many characters you had in which to compose your Tweet.
input type="text" form fields should be sized to give the user visual clues as to how much they are expected to enter. Think postcode fields or Titles (Mrs, Mr etc.). The
maxlength attribute can then be used to enforce that limit. But with the
textarea element (like the one at the bottom of this page that takes reader’s comments) there’s a little more to consider. It should also be sized to provide those visual clues and since HTML5, the
maxlength attribute can also be used. However users are able to resize
textarea fields and unless there’s some clue as to how much text they can enter, they may waste time unnecessarily redrafting paragraphs.
On a recent project at the Ministry of Justice we had a number of
textarea fields. Because we were integrating with a legacy system, we had to respect the data limitations that system had imposed many years ago when data storage was more expensive, otherwise we risked crash errors when submitting forms.
An Axure prototype I built included one of these fields and we wanted to be sure our users understood the established GDS pattern.
There were some sensible rules applied to the visual treatment of the character count which I also wanted to reproduce in the prototype:
Before typing any characters, the character count is displayed as grey text with a count of 0.
When typing characters below the maximum count, the character count is displayed as grey text and shows the current character count including spaces and punctuation.
When typing characters within 20 characters of the maximum count, the character count text colour should change to red.
Typing characters over the maximum count, the character count text should remain red and become bold.
First, I started off with the very handy GDS Axure library created by my colleagues at HM Land Registry (thanks Joe!) – which saved me a lot of time on the essential interactions like field highlighting. (Let me know if you’d like a copy of that library. It’s a work-in-progress so I’m not sure how widely they want it shared).
Counting the number of characters entered
The easiest way I found to keep track of how much text the user entered was to use the onTextChange event on the text area widget itself. This event fires when text is added or removed to a textarea field – perfect!
I used the onTextChange event to increment or decrement a global variable counter I’ve called
varCharCount. Counting up is easy. But I also want to track if the user deletes some of what they’ve entered, otherwise the count is going to keep going up and up and up every time they make a text change (adding text or removing text are both changes after all).
I first messed around trying to determine if the user had pressed the delete key, but it turns out there are complications there, with different browsers, keyboards, remote keyboards etc. Delete, it turns out os a “special key” so tracking it isn’t straight-forward (read: doesn’t work). Thanks to the Axure support forum for that heads-up!
So in order to keep track of whether there is more text or less text, I need to keep track and compare the counter every time the onTextChange interaction fires. I do this by comparing the current number of characters in the widget (the “length of widget value”) with the counter. If the length of widget value is greater than varCharCount, the user must have just added a character. If the length of widget value is less than varCharCount, the user must have just deleted something.
So to recap, the text count should start grey. When we get within 20 characters of the limit, the text should turn red and if we exceed the limit that red text should now become bold. (For ease of testing, I’ve reduced the max count to 30. In real life it’s 100 or more characters depending on the context of use).
(Mis)Using Axure’s Selected and Disabled Interaction styles makes this very easy. All we have to do is define the Selected state to be red and the Disabled state to be bold red and then keep a count of the number of characters entered and change the state of the text when the specific numbers are reached.
As you’ll see, I’ve separated what could be one block of text into three separate widgets (numTotal, numCount and txtCharCount). This makes it much easier to update the only piece of text that changes dynamically – the character count (numTotal). The rest is static (apart from turning red and then bold). I tried just using two widgets, but I found when the static text became bold, it moved undesirably. So for the sake of a little more code overhead I have a more stable result.
Resetting the formatting
So we can easily set the format of text when we’re counting up, but the formatting should reset if the user realises they’ve gone over and deletes some of what they’ve written. (How we track the number of characters is covered below.) So with a quick tweak to the interaction above, the formatting should also reverse when deleting text.
Currently, I don’t know a way of tracking if the user uses a keyboard modifier like
Command when deleting. Pressing
Alt+Delete will delete the whole previous word and
Cmd+Delete will delete the whole line preceding the cursor. This will obviously mess with my counter as I have no idea how many characters were in that word or preceding line.
Let me know if you work out a way! Equally, if you’ve got any questions or something isn’t clear, please let me know and I’ll update.