There are no small changes
“We want to limit the length of a review in our application to 140 characters, because we may want to use SMS at some stage. That’s a tiny change, right?”
Wrong.
There are no tiny changes when you’re committed to delivery quality software. Let’s look at the above case. A naïve programmer may well get this coded in three minutes, after all it’s just an if-statement.
When handling requests like this, experience has taught me to ask a few questions…
- What happens when the review is above 140, do we crop the string, or display an error message to the user?
- If we display an error, where does it appear, and what does it say? Who is going to write the error message. How do we explain to the user why we’re limiting to 140 characters?
- How will these errors look? Do we have a style defined? if not who is designing it?
Delivering a good experience
In the unlikely event that we have answers to hand for all of the above concerns, we’re still not finished. Performing a round trip to the server is a messy way to handle errors. We can do better than that. Well if we’re going to do client side validation then I’d have a few more questions.
- Who’s writing this Javascript? What browsers must it be supported in? Does the Javascript display the same type of error as the server side code? If not what does the new one look like?
- Does this application need to work without Javascript? If so we’ll need progressive enhancement, for this feature. Also how do we ensure that updates to the 140 character requirement will affect client side and server side validation?
We’re still not done. Look at this from a users point of view, they’re already frustrated by having to limit a review to 140 characters for a bizarre reason they won’t understand, and now we’re asking them to guess how long their message is? There must be a better way. Let’s at least give them a character counter. That raises a few more questions…
- Who is going to write this character counter? If we’re using one we found on the net, then who wants to make sure that it works in all our target browsers, and not just Firefox?
- Where is the count of letters displayed on the screen, how often does it update?
- What does the count look like? The style should change as the user approaches zero characters, and should definitely look erroneous when they’ve used more than 140 characters, or should it stop accepting input at that point? If so what happens when you paste something in?
When all the issues are solved, and we’ve implemented the character counter, styled all the errors, implemented the server side validations, and checked it in all our supported browsers then it’s just a case of deploying it. This presents a new set of problems, as we need to pick a time when no business critical actions are being performed and have a team ready to roll back if necessary, even when it’s highly unlikely.
All of this is happily ignoring the fact that users will wonder why someone wrote an eighty word review just before them and now they’re only allowed write a 140 character one. Who wants to handle feedback on that one?
And don’t get me started on how we’re gonna deal with all the funky characters that are doing the rounds these days, thanks to CopyPasteCharacter. Good luck sending them in a text message. We’ll need sanitise the input string for rogue characters, this means new error messages, new server side code. The list goes on.
Once you get through all this you will have your feature in place, and this is just for a character count. Now try something that’s more complex than an if-statement. There are no tiny features when you’re doing things properly. This is why as a UX designer you need a good understanding of what it takes to implement a feature before you nod your head and write another bullet point.
This is why plugins and swhitelabel solutions can be troublesome. They make the addition of features look deceptively easy. Adding a plugin to a codebase is easy. Integrating a new feature within an existing application is not. When you’re striving for quality there are no small changes.