Coding Horror: Treating User Myopia | Hacker News Reader

Coding Horror: Treating User Myopia

codinghorror.com

36 pointsbillpg23 comments

This really is "Coder Myopia": Jeff should be the first one who is familiar with the "eye movement hotspot" study that we see over and over again. Users rarely notice anything along the Right Hand Border (most web ads show up here). All user attention is focused on the top left edge, left margin and the top few lines. If you want to catch the user's eye this region is your best bet.

Move the formatting suggestions just below where your "Title" is placed and you will see a higher uptake - guaranteed. Blaming Users for Poor UI design smacks of unwarranted arrogance - never a desirable trait.

It's no wonder that users don't read the Formatting Reference (as shown in the screenshot). It's written in totally cryptic jargon that's only understandable by someone who knows HTML, and is itself formatted in a manner that makes it illegible.

Worse, those big blue buttons in random alignments grab all the attention and make the text even harder to read (they should probably be plain old links).

I think I would just put a link above & below the preview window: "Preview look funny? Click here for formatting help."

How about just getting the preview to format correctly in the first place. The way it's typed into the text area it looks fine.

Users shouldn't have to read a manual of markdown tags to enter text on a site, not unless it does some really special stuff.

Hm, I didn't know the MarkDown-Syntax and I must say that it really is totally unintuitive to have put 2 spaces at the end of a line to get a linebreak. That's just not what one would think having to do.

Ok, so there is the preview but I must admit that I would probably think that the preview is broken, if such a simple thing such as line breaks aren't displayed correctly. I've encountered so many broken things in web apps that I'd simply assume that this preview is broken, too. It wouldn't occur to me that there is a special syntax for something as simple as a line break.

> I must say that it really is totally unintuitive to have put 2 spaces at the end of a line to get a linebreak

Agreed!

One way I get round that is to run text through a Markdown parser first then do a regex to replace \n with <br />

That seems to work fairly will ~99% of the time.

(I do like Markdown though - compared to, for example, BBCode. It degrades fairly gracefully, ignoring the line break issue, so you can just write a chunk of text and it looks good but formatting is fairly easy to pick up and eventually intuitive for more advanced users)

the problem with replacing backslash with <br/> is that there are also the kind of users that make to much carriage returns whenever they feel a sentence is finished.

this turns out to be just as ugly.

how do you get to the 99%?? i would say there are more people pressing ENTER when they really want a line-wrap then people writing textwalls.

Umm well I was respondign to the guy above me with references to the 2 spaces to get a line break problem. Markdown does not parse \n (at least not so I have seen) at all.

The textwalls problem I don't have a solution too :)

If you separate text by two line breaks it will be broken into paragraphs, which is how the text looks. Line breaks are only supposed to be used when you don't want a paragraph break, which is at least somewhat uncommon.

I'm not saying that it's at all well-explained on the site, but there is at least a reason behind it.

I've posted this in the comments:

There's also a loss of information in the example. The user typed "\\<path to shared folder>\c". Markdown produced "\\c". I do understand it was interpreted as html tag. But I feel it had to be ignored - there's no "path" tag in html.

Edit: It was difficult to get this comment posted properly on Coding Horror - had to use < and > It's much nicer here on HN. KISS at its best!

It seems like there is a basic problem here. Users have spent years using WYSIWYG editors like MS Word, Email apps and so on. Having a basic text box breaks that. Not only that, it's different markup on every site you go to. User don't want to relearn the basics, especially not for each site.

Lack of richtext editor support in browsers has been the problem so far - but I believe mostly there with contentEditable support in all browsers?

WYSIWGY helps for printing, but not formatting. Somehow the tools have to be made available, without a blizzard of tool buttons giving the user snow-blindness.

I didn't see the instructions either.

Everyone's brain knows a block of text in the right-side column of a web page is an ad and provides nothing useful to the task at hand.

Yes, and also every app designer is proud of her baby and thinks the user is just aching to learn it. When in fact the user has an actual task to get done, and your tool is actually in their way. Imagine building a house, and having 47 tools in a pile in the driveway when you arrive. Not helpful, probably you'll just pick up the hammer and start pounding.

I'm all for making a UI as simple and helpful as is practical. But at some point we reach diminishing returns: we invest so much in being helpful that it exceeds the cost of users misunderstanding. With Jeff's suggestion at the end, it may even be that pre-supplied question text causes enough badly-presented questions, or questions with the boilerplate itself left intact, that it makes the situation worse.

So I think it's worth playing devil's advocate: is there some point at which we're justified in expecting the user to just grow up and read, or give a little bit of thought to what you're doing? Why do we, in the software industry, beat ourselves up so much, when the rest of the world is given a free pass?

I mean, whether it's figuring out how to use some kind of glue, or operating the PBX system, or planting a garden, and on and on, we expect that the user is going to read something about what the heck he's doing. Why not with computers?

I'm thinking we need to put the formatting help -- for new users only -- directly in their line of sight

Even then, you'll find that some users will just spend their time looking for a way to get rid of the help (and do what they came to do), rather than read it.

Is it possible to evaluate the readability of the submitted text using some algorithm? If so, when text is entered in the input box, the page could automatically display some kind of assessment of readibility.

We've recently had to put up a "You have a stale link and will be forwarded shortly..." page. As expected, people started calling us to ask why the system wasn't working.

Maybe they don't know what "stale link" means. If I saw that I'd be confused too. Can't you just silently redirect?

Maybe all that text just isn't connecting with the user's goals. What if they added a sentence, unavoidably in the users line of sight, to the effect of:

"Want be understood? Format your text using the simple formatting guide on your right."

So, it points out how to achieve their goal (being understood) but it doesn't clutter their line of sight with too much information.

For all intents and purposes, that field looks like a rich text editor. Of course I wouldn't read instructions on how to enter text. I learned how to type in rich text editors a long time ago.

I wouldn't want this guy doing usability design on my site. Woof.

correct usage of carriage return and spaces are hard to get right for users who are not used to type writing.

thats about it. teach them that and you get 80% readable ascii.

Perhaps someone should also teach them about the correct use of capital letters and how they make sentences easier to read.

Reply on news.ycombinator.com