“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.
40 Comments
SO right
Posted by Paco at 1:15 pm on 16 July, 2009.
All true of course - but many of these problems stem from the process of decision making.
A small, experienced, and well-knit team should be able blast through most of this subconsciously. (As could a single developer who knows what they’re doing - not just the naive ones.)
Not that those choices don’t need to be made, just that it need not be quite such a daunting decision tree.
On the other hand, there are always clients…
Posted by James Pearce at 1:24 pm on 16 July, 2009.
Absolutely James, we can usually answer all of the above pretty quickly, presuming the team is still available for work on this project.
But I often find explaining the above to clients helps them understand exactly why we can’t make snap decisions on seemingly small changes.
Posted by Des Traynor at 1:32 pm on 16 July, 2009.
uh… maxlength field of textbox preempts most of the issues you are talking about. there should always be javascript and server side validation.
this is a 2 minute update in a good environment. 2 days if you have to file the paperwork…
Posted by programmer at 1:57 pm on 16 July, 2009.
The real question is, why do you want to limit everyone’s experience just for the few people who will receive the reviews via SMS. Couldn’t you just send them a link to your mobile website version of the review instead?
Posted by Name at 1:57 pm on 16 July, 2009.
Yet another valid point guys! Thanks a mil
Posted by Jeff at 2:01 pm on 16 July, 2009.
This is such a great post. Consideration for these sorts of deceptively minor aspects in a web interface truly determine the quality of the user experience and the success of the app or service.
Next time a client can’t understand why such a minor request isn’t as simple and instantaneous as they’d expect, I’ll be referring them here (in a polite fashion, of course).
Posted by Matt Dempsey at 2:20 pm on 16 July, 2009.
I think this is a bit of an edge case, in that you’re trying to restrict an existing behaviour.
One effective solution might be to change the textarea into a single-line input - if you do this, I imagine 95% of reviews would be within 140 characters. A JS character counter can really be implemented in five minutes using a bit of jQuery or Mootools.
All in all, the change shouldn’t take more than half an hour to commit, although it certainly isn’t the 2-minute update some clients would like it to be.
Posted by Josho at 2:26 pm on 16 July, 2009.
@programmer
Agreed. Although the article is valid, to some degree, the example posed is rather trivial (even in a web app). Standard textbox just needs to have the maxlength set. A textarea box can either be handled by a single line of js code, or using a simple validation rule. And while paperwork, futile debate, or over-the-top excuses (see the article above for an example) can dramatically increase the time it takes to present a solution to the user, ultimately, this is a matter of scale. Yes, there are some items that may take days to resolve that, to the end user, appear to be simple (which was the point of the article), but when you have developers pushing back at every small change (which sounds like the primary failure of this article), then nothing gets resolved in a timely manner.
Posted by the other programmer at 3:50 pm on 16 July, 2009.
Great post Des. Actually worked on implementing something almost identical to the example you’ve given in the post this week
@programmer MaxLength doesn’t solve the issue. MaxLenth isn’t even a valid property for a textarea. Even if it did work, the only issue it would actually solve is physically how many characters fit in the box, all the other issues remain.
Posted by Peter McKenna at 3:53 pm on 16 July, 2009.
You forgot some.
Does this impact any existing unit tests? How many unit tests do I need to ensure coverage? Do I need client-side unit tests, too? Do any database columns need to be altered? Do any other consumers of this field need to be updated? Do any other methods insert data, and do they need to be updated?
Posted by pytechd at 4:01 pm on 16 July, 2009.
I disagree.
These choices and decisions are up to you as the developer. It is your job and your responsibility. The client pays you money to do all of this. You can tell them, jee client, I have some decision making to do, but this isn’t an excuse. You cannot refer them here and say jee client I’m going to need some more money for this because it will take way longer than you think.
I don’t believe these decisions are deceptively minor, they are negligible. The client doesn’t want to know about different validation stages or cross browser capabilities. The client wants you to enable something quickly, but if you want to worry about implementing CSS styles for BOTH server side and client side errors, then I ’spose you aught to tell them it’s going to be a week or two.
Posted by Harry at 4:03 pm on 16 July, 2009.
Great points, but most of all, a not so subtle nod to the excellent design work done at Twitter which serves as the template for the example your article uses. It’s hard work to make it look easy.
Posted by Walt Gordon Jones at 4:11 pm on 16 July, 2009.
its a two minute change… end of story…
you stand to lose business otherwise…
Posted by Anonymous at 4:30 pm on 16 July, 2009.
You’ve got a valid point but your streching your examples.
Since you’re so intend on quality you should already have length check in place server side with error reporting on the client side; style defined and all. After all you’re probably storing that in a database and your column already has a set length and you already won’t try to insert more than that. Unless you were storing everything in binary blob of course in which case you have greater issue.
Then you’re mixing two project to make your simple “restricting the length” seem more complex than it actually is.. your project is supposed to restrict the length of a textbox “because you may want to integrate with an SMS gateway *at some stage*” (as in not now) or integrating with the SMS gateway is part of the project. Different scope; different set of issues.
But yeah otherwise you’re right; a change needs to got though change management but I believe every project manager worth his salt knew that.
Posted by boyd at 4:37 pm on 16 July, 2009.
These are great points, and highlight the fact that software product design is more than just writing the code. In fact, the article’s examples are perfect for showing where the breakdowns usually occur. All of the related questions that arise from the decision to make a software change result in a handful of additional relatively-easy-to-develop dependencies. A style-sheet addition here, a java-script block there, a blurb for the error message, etc. It’s the decision-making process that breaks down and slows the progress. Great read, and Great reminder of the human condition!
Posted by Manata at 4:39 pm on 16 July, 2009.
That’s a small change. Still. Yes, you listed a whole bunch of questions to be answered.
But all those questions are trivial to a good programmer. There’s nothing complex in the answers to any of those questions.
Who’s going to write the character counter? You are! My god it’s simple as hell if you know what you’re doing.
My god people… solve the business problem and move on! Don’t waste your time harping over the trivial details. No one really cares what the character count looks like, as long as it’s obvious what it is. Like “You have x characters left in your message”, and then stop input once the limit is reached.
Maybe for some developers there are no small changes… only because they make mountains out of mole hills.
Posted by ME at 5:13 pm on 16 July, 2009.
Any time my customers beg for features I’m immediately directing them to this blog entry. Serious.
Posted by seth at 5:20 pm on 16 July, 2009.
Hey, I love some of these answers. Keep it up guys. Trust the form.It makes my life easier with greasemonky, firebug, or heck just perl/python scripts to feed your forms. Don’t bother to do server side validation. You probably just need another 10 seconds to put a terms of use on the form that people must enter the input the way you expect it. You can probably hire some contractors to manually clean up the data as a lot of people on the web can’t read.
Great post imho. Yes, a good developer will be thinking of all these things. But most of us work on teams. It’s not client->developer. Even when it is, it’s really client -> dev as pm, dev as analyst, dev as dev, dev as tester, dev as deployer, dev as maintainer.
Posted by Peter J. Schoenster at 5:35 pm on 16 July, 2009.
I agree with your point, but as for this specific example why not limit the text field to 140 characters, slap on some server-side validation? That only leaves about 10% of your questions, mainly dealing with explaining the character limit to the user. I mean, a changing character counter, seriously?
Posted by john n at 6:30 pm on 16 July, 2009.
I am impressed by the amount of comments that fail to see how a three minute change is never a three minute change. And even if it is up to the developer to make these decisions, they still have to be made.
Making light of any feature change/addition is asking for it. Not to say that this feature is too hard or shouldn’t be done, but it should be looked at carefully, just like any other feature.
Posted by Nathan at 6:33 pm on 16 July, 2009.
Comment
Posted by Name at 6:55 pm on 16 July, 2009.
Your typography needs some attention on Firefox/Vista/Cleartype. This is unbearable to read. The character spacing is nearly as large as the word spacing. It’s hard for me to read.
Posted by Nobody at 7:02 pm on 16 July, 2009.
All those issues you raise can be blown through in a 5 minute meeting. Done. End of story. I work in an area where seemingly simple changes have enormous repercussions, and, believe me, your simple change really is a simple change, no matter how much you try to blow it up into something it’s not.
Posted by Ben at 7:57 pm on 16 July, 2009.
I must be missing the point, but I see a different solution that makes the User Experience unchanged.
Don’t limit the user input whatsoever. After they enter their comment, have a server side script of sorts read the comment and validate it there. If the comment is longer than 140 characters, have it read in the first 130 and add a More tag so whomever reads the SMS will know, if they want more, they can log into the site and read the remainder of the comment. Leave the user out of the equation. Don’t frustrate them with nonsense limits that can be over come by just getting a snippet of what the reviewer needs.
Of course, that’s just ramblings of someone who has designed user interfaces before.
Posted by Palladium at 7:59 pm on 16 July, 2009.
Great Post. I must say that a compitant developer would handle these decisions with ease. Therin lies the problem. When you manage teams of developers you must make the choice to do it yourself or take a gamble that the bafoon developer you assign the task to does it right. So what will take more time, you doing it yourself or writing the instructions for a developer to do it. There are small changes but small changes never take a small amount of time to complete correctly
Posted by PM at 8:06 pm on 16 July, 2009.
Your questions are valid. The complaint about having nit-picky work to do is irrelevant if you want to keep your job. Just do it and bill by the DAY since any good programmer loses sleep over hard (fun) problems.
Posted by Paul at 8:28 pm on 16 July, 2009.
Amen.
Posted by Grant at 8:43 pm on 16 July, 2009.
And you wonder why most projects miss deadlines. Some people make mountains out of molehills.
Posted by Jack at 8:48 pm on 16 July, 2009.
Hey Palladium,
Your solution has merit alright, but this wasn’t a post about UI design.
To be honest, my advice to a client here would be to not make the change until its necessary rather than writing real code to solve fictitious problems.
The point I was communicating is that a seemingly small problem (limiting input size) will have larger repercussions. As I’m sure you know, even your solution has technical implications, that aren’t considered when someone says “Sure, we’ll do that, no problems”.
Des
Posted by Des Traynor at 10:10 pm on 16 July, 2009.
I’m with @Harry and @Paul: even if it’s an uber messy problem and definitely not a tiny change, as someone once said “Nobody needs to see how you make your sausage.” So in other words, if the client thinks its no big deal (providing they haven’t asked for the moon at no extra charge), I say get on with it!
Posted by Felix Desroches at 11:16 pm on 16 July, 2009.
I’m rather puzzled by the attitude expressed in the comments here of “O, just slap a maxlength on the textarea”. When told that maxlength isn’t a valid attribute, the reaction is “Yeah? Well then you’d just throw some javascript, done!”. This attitude seems to completely ignore the implications of one’s decisions.
I’ve implemented such text boxes for client applications that handle SMS messages, and although none of them were enormous technical challenges, there was plenty to consider, discuss and decide until we got to the end product.
Which is precisely Des’s point.
A naive solution of maxlength wouldn’t work, a simple javascript character counter wouldn’t work. The end product involved Javascript that counted certain special characters as multiple characters, and prevented the user from entering more than was permitted. Which wasn’t terribly hard, but certainly took longer than adding the 15 characters of maxlength=”140″ to a damn textarea tag and thinking your work is done.
Posted by David Barrett at 2:01 am on 17 July, 2009.
Most of the issues you point out are only problems in overly micro managed environments like the one I work in where managers and those with more years of experience with the company would feel the need to preempt and second guess any developers well reasoned, rational, and totally appropriate measures to deal with all the issues presented. Its really a matter of common sense for a person that has the proper focus on the users experience.
Posted by Greg at 2:42 am on 17 July, 2009.
The people who think putting in a maxlength is the solution provide me with a good income. Their unsatisfied clients knock on my door for a proper solution.
Of course it depends on the customer whether or not he will accept the ‘maxlength solution’. However as a good developer you’ll have to discuss the implications of a change with your customer.
Posted by Rico at 8:56 am on 17 July, 2009.
Lovely post. Fascinating that most readers gets hooked on the input-example instead of thinking about the whole point of the entry.
Everyone who say this can be done in two minutes have apparently never worked with clients. Explanation:
- You read the task (one minute).
- You set the maxwidth (It takes one minute + the time to for example connect to the ftp, open up your editor etc. In other words just to get going (here comes some other issues. What if the textarea is implemented in a bigger cms-system, you might have to find the template for just that page etc etc. Add as many minutes here as it takes to be able to edit the code.).
- You report the result to your client (add another 3-5 minute here of emailing/phonecall)
Clients comes back and tells you that his son complained that maxwidth isnt a standard and wants another solution. Back to the beginning. (plus another 3-5 minutes or to on the phone with the client complaining).
- You decide to go for the javascript solution.
- once again you have to open everything up ( insert time to open up the specific code here).
- Lets say that we live in a perfect world where you never make code-mistakes and you manage to develop javascript-code that works in every browser and you do it in the time a good experienced Javascript-coder would need. (five minutes).
-You report the delivery it to the client over phone or email (one minute)
- the next day the client gets back and says it doesnt work.
- It takes about 15 minutes of disscussion with the client to realize that he used a browser with javascript turned of..
So far we have managed to spend something between 30-60 minutes (things as starting your computer, locating exactly where that codesnippet was, isnt included in this).
This can go on forever (and I didnt even cover all the different problems that can occur on the database/serverside depending on the nature of the system).
For some real life examples.. go check http://www.clientcopia.com
The time
Posted by David Mobrand at 9:30 am on 17 July, 2009.
Is it just me, or does the font on this page get mangled on OSX? http://imgur.com/mJczW.png shows this page in both Firefox 3.5 and Safari side-by-side on OSX, and I’m having a hard time reading the page. Is this a problem for anyone else?
Posted by Quag at 10:59 am on 17 July, 2009.
@ “its a two minute change… end of story…”
Here, let me fix this for you:
“I am not a professional software developer”
Posted by Steve Friedl at 4:35 pm on 20 July, 2009.
Another thing just struck me about every comment that its a 2 minute-fix.
Everyone who thinks they can fix it in two minutes (either with javascript or maxlength) are free to download my sourcecode here and show me how:
http://www.mobrand.se/dump/textarea.fla
..and YES, its a flashfile, because who said that the textarea was a html-form? The client dont care if the form is within flash, html or perhaps a third unknown plugin with its own limitations?
..and by the way.. besides that, the flash needs to be compatible with every version of flashplayer 5.0 or later.
and yes, due to different dependencies within the whole fictious system, the textarea has to reside within this flashfile.
and finally, just upload the change to the live server after youve finnished it.
what do you mean you dont understand which server to upload it to? You are the developer. It was You who said this could be done in two minutes?
Posted by David Mobrand at 5:47 pm on 20 July, 2009.
I think the worst things is when you agree to make a simple change and you delve into someone else’s poorly formatted tables based markup riddled with spacer gifs. One small change inexplicably breaks the whole thing and it can take even longer to fix the problem.
Posted by Matt at 11:42 am on 28 July, 2009.
Just the number of responses to this post (which is excellent by the way), goes to show that his is definitely not a problem that will require a 2minute solution.
Perhaps, if all you had to do was build a form like this it might take a shorter time, but once has to be aware of all the impacts a seemingly small change could have on your application.
If it is solved with JS, then is it going to be consistent with what the rest of the application is behaving like?
What about previous reviews?
Should one make two versions of the review input for those that wish to send theirs by SMS?
For anyone claiming that this can be solved in 2 minutes, they might be right… but the solution will be poorly executed at best and potentially create more issues than would be solved by rushing a quarter-done product out the door.
Posted by teknoid at 5:01 pm on 19 January, 2010.
12 Trackbacks
popurls.com // popular today…
story has entered the popular today section on popurls.com…
Posted by popurls.com // popular today at 3:12 pm on 16 July, 2009
[...] McCabe over at Contrast has put together an excellent piece on the inability to codify granular changes within an existing web application. The situation he [...]
Posted by Matthew Garvin » No Small Changes. - Awesome Design at 5:20 pm on 16 July, 2009
[...] An excellent blog post today covered change requests for web applications. While the example used in the blog post may be a little overdrawn, the main point excellent: there are no small changes to web applications. [...]
Posted by Magento: specification, there are no small changes « momerco at 6:25 pm on 16 July, 2009
[...] Contrast | The Blog | There are no small changescontrast.ie [...]
Posted by Contrast | The Blog | There are no small changes « Netcrema - creme de la social news via digg + delicious + stumpleupon + reddit at 7:37 pm on 16 July, 2009
[...] There are no small changes 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. [...]
Posted by almost effortless » Weekly Digest, 7-19-09 at 5:01 pm on 19 July, 2009
[...] There are no small changes to a web app. URL shortening is a fairly simple, straightforward service. A tiny change gets noticed, and a big change like this can rock the entire landscape. [...]
Posted by Digg’s short URL fiasco and what we can learn from it at 4:12 pm on 20 July, 2009
[...] There are no small changes There are no tiny changes when you’re committed to delivery quality software. (tags: usability design) [...]
Posted by Blog Archive » links for 2009-07-23 » Small Farm Design at 6:53 pm on 23 July, 2009
[...] There are no small changes and Every pixel counts – Des Traynor with two insightful articles on user interface design. [...]
Posted by Developer Links – 27-07-2009 | Ross Duggan at 8:09 am on 27 July, 2009
[...] what about when the Client asks for something seemingly innocuous that is actually pretty complex? Do you make assumptions for them and run the risk of delivering [...]
Posted by The EchoUser Experience » Clients and sausages at 7:56 pm on 27 July, 2009
[...] If we work together on your idea, I’ve to put a great deal of effort into the software development. Software development is complex, detailed and a good programmer has very real talent, which has taken many years to hone. (I’ve never met a great programmer who wasn’t already at it from around 12 years old). Experienced programmers know that the devil is in the detail [...]
Posted by How much is an idea worth? | tapadoo at 6:57 pm on 21 August, 2009
[...] artículo es una traducción libre del post There are no small changes de Des Traynor. “Queremos limitar a 140 la cantidad de caracteres que permitimos para los [...]
Posted by No existen los pequeños cambios › Plus Global at 5:01 am on 2 September, 2009
[...] actual results and improve morale, while improving feedback between team members and customers. In software, there is no such thing as a “small change” (maybe the most important lesson a non-technical manager can learn), so cut the batch size beyond [...]
Posted by My take on Customer Development and the Lean Startup | Recess Mobile Blog at 2:14 pm on 9 January, 2010