User Failure
As a developer it would be wonderful if I could blame any failure to adhere to my interfaces on the user. That is what Jeff Atwood has done in his latest post. The unfortunate reality is that if the users are failing in a consistent way, the real failure is more likely that your system doesn’t conform to their needs appropriately. There is a limited amount of time in the day and we cannot code for every kind of minor formatting failure, but solving the common problems is worthwhile. Jeff has some good observations in his recent post, but seems to be asking the wrong questions, and really misses a few key issues.
The specific examples brought up in Atwood’s latest post seem to lambaste the clueless user incapable of reading a simple set of instructions:
Our formatting rules aren’t complicated. You can get a lot done with a bunch of simple paragraphs. We use Markdown, which offers basic formatting conventions that ape ASCII conventions. On top of that, we offer a real-time preview of how your question will look once submitted, directly under the question entry area. But none of that seemed to work for this particular asker, who, apparently, was totally satisfied with obviously broken formatting — even though a few choice carriage returns would have worked wonders, and been immediately visible in the live preview. -Jeff Atwood
The problem with this is that it is followed by a diagram indicating a small set of instructions at the lower right of an input box. He highlights this instruction panel with many red arrows and asserts UI designers see the question page this way. The first issue with this is that English speaking UI designer should be well aware people read from top to bottom, left to right when reading text or scanning a document. The second issue is that when viewing content your eye tends to drift away from negative space towards the heaviest or most complicated elements, and in this case it is the toolbar above the edit pane and “How to Ask” box directly above the formatting rules. I would argue your average person would read the “How to Ask” heading before (and probably instead of) the “Formatting Reference” heading.
In fact, an interesting eye tracking study was done in which it was determined people scan pages in an F shaped pattern very quickly. This would quite precisely miss the red arrows completely and utterly. In this instance F is for the failure of the instruction placement Jeff clearly wishes people would read. Another issue is that even if I saw it, I probably wouldn’t read it. According to this resource by the same group, bullet lists would work better than the blob of instructions presented.
The toolbar type element is so typical that visually it may be noticed first by a novice computer user, but it will likely be skimmed over by an average or expert computer user (much as all pop ups are viewed and worried about by novice users “YOUR COMPUTER HAS BECOME INFECTED, CLICK HERE TO BUY OUR SOFTWARE.”) The toolbar will almost invariably be ignored until your typical user has a problem that needs solving. If they don’t believe they have a problem they won’t inspect it further, so issues like not pressing enter twice to make a new line wouldn’t even be considered toolbar-related issues.
There is an entirely different set of issues which has not been touched on here, however, and that is that people probably won’t read any of that stuff because they’ll see an input box and immediately “satisfice”. If they have a question that is immediately where they will begin typing information. People come to a website with a problem or looking for specific information and they set about the task in a goal-oriented manner ignoring almost everything else.
The goal might be to read a blog article, or it might be to find an image, or it may be to ask for advice on a technical website, or to read an answer. Some users will come to the same site with different goals and you will find that they scan the page very lightly until they find key words or phrases or input fields which match the type of result they are after, at this point the “good enough” mentality kicks in and they stop exploring alternatives or seeking new information until an unbearable problem crops up in which case they may begrudgingly look for more information or alternatively a different solution somewhere else.
Desktop application UI design is a bit different in that you aren’t directly competing with the entire world for a user’s attention at every step in the process. When you’re working with the web as your medium you have to accept all the user expectations that come bundled with that, the internet is a big place and your users are trained to not read everything from the get go. Your formatting rules box has no hope in hell of being immediately noticed no matter how many imaginary red arrows you draw around it.
This wouldn’t be a problem if the formatting rules weren’t so arbitrary. That extra information exists and is useful for people interested in it, but for somebody who doesn’t care if they can make some text bold I guarantee they will skip it. This knowledge of behavior is incredibly valuable information because if you know what your user is going to do you can stop bitching about all the arbitrary rules you’ve set up and actually focus on making the user experience better. Those formatting rules are getting in the way of the relatively simple task of asking a question, so the right approach shouldn’t be how to make the user read those rules, but rather, how to make the system understand the user. There are certainly more complex tasks which may require technical training of a user, but the common tasks a system has been built for should be immediately obvious.
One of the main points of contention Jeff outlines in his post surrounds this set of rules:
Formatting Reference:
indent code by 4 spaces
don’t want colorization? Use <pre>
to linebreak use 2 spaces at end
> blockquote
backtick escapes `like _this_`
If I press enter on my keyboard I expect a new line, this seems pretty basic. If I have to press enter twice, that is a hidden trick that breaks everything I know about pressing enter in a text box and it is making it more difficult for me to ask my question in a logical way. Let’s not even consider the fact that a space could indicate hitting the space bar, so the instructions are confusingly worded.
Block quotes really should be a parse-able discovery, it isn’t so hard to detect an entire paragraph or series of paragraphs which make up such a block quote.
The specific failure example involves an ordered list of elements, this should also be discernible through parsing. Use of numbers, an asterisk, a dash, or a plus to precede several lines in sequence is a strong indication that a list is being used. There isn’t a compelling reason to require contrived markup for such a list in a system where entering them may be common (I often use lists in describing a set of steps to resolve an issue).
I’ll be fair, though, it seems that he realizes the instructions would need to be moved to be read (even if earlier he states UI designers seem to want people to look where they just plain will not):
More and more, I’m thinking we need to put the formatting help — for new users only — directly in their line of sight. That is, pre-populate the question entry area with some example formatting that is typical of the average question. Nothing complicated. But at least then it’d be in the one — and apparently the only one — place myopic users are willing to look. Right in front of their freakin’ faces.
But even so, I feel a vital point is lost in attempting to contrive new and annoying ways of forcing your user base to read something they shouldn’t have to. This is assuming they would even read it if you put it right in the text box. Default text gets erased, so it may actually be more difficult for a struggling user to find.
It is well and fine to provide instructions and to provide buttons to click to automate the creation of these control structures, but it makes more sense to simply detect behaviors where it is simple to (like in text processing) and to account for these. Always provide a way to turn this off or to cancel it, but at least try to find the natural solution before falling back on contrived markup for commonly expressed problems. Even if we can’t make things as intuitive as we would prefer due to time constraints or technical limitations it pays to avoid blaming your loyal user base for being daft or oblivious.
October 29th, 2009 at 2:11 am
I’ve noticed a trend scrolling through Jeff Atwood’s responses of replying to such criticism about the line breaks by basically stating everyone puts two line breaks between paragraphs anyway. The real point here is that he used an example where the user obviously did not do this and decided it was a common enough issue to post about it. The snarky tone could be done without, I think.
The real problem here is that if I press enter, there damn well better be a new line. This is how every text editor I’ve ever used works. This is how the browser’s text field works. When a precedent is set for expected behavior and you have the option of conforming to that behavior or breaking it there should be a very strong case for breaking that expected behavior or you should conform. Not doing so is user hostile and counter-productive.
If you want to enforce the full break between lines you can always filter the content to add as much or as little spacing as you like. You can consolidate extraneous line breaks and make a horizontal rule out of it if you want. It doesn’t have to match the exact line for line output of the user, but you should try to capture the spirit of the message and make it readable (all the while making sure the escape option works correctly to give the user control when you can’t guess correctly at behavior).
If I press enter and I have an option:
A) No breaks, just put it on the same line, it’s ok if everything blobs together into an unreadable mash.
or
B) Put in an extra line (or paragraph tag or whatever you want to format it as) and make it appear a bit wider of a space than I entered.
The obvious win would be B.
October 29th, 2009 at 3:59 am
This newline malarky hasn’t been helped by the rather strange way the tags work on web pages, i.e. a blank line at the end. It is completely wrong IMHO for this idea to extend beyond web pages, in fact, I’d say the HTML designers got it wrong. It was with horror that I found Word 2007 doing the same thing!
Cheers, Rob.
October 29th, 2009 at 8:31 am
Thanks for your post, Rob!
I haven’t tried Word 2007 yet, but this is the second time I’ve heard about it performing a strange behavior with line breaks, what exactly does it do? I thought you just had to press enter once and it would add a new paragraph (this is different from old versions of word, but is still consistent with enter making some kind of a difference.)
I think the issue with HTML is that people would like the ability to indent the text, but as soon as you have to be able to indent you need to be able to accept line breaks in arbitrary places without mangling the output.
HTML is a language though, it isn’t an application for end-users. It has certain flexibilities it requires that make requiring a manual acceptable.
Posting on what is basically a listing site should not require a manual, however. It is a very specific application with a very narrow purpose and it should do its best to not make me think about silly formatting rules every time I want to interact with it. I’m totally with you on the idea not extending beyond HTML or other such languages which require certain concessions be made for embedding text in code.