Re:Coding Horror: Treating User Myopia
by suprgeek on Friday October 23, 2009 @06:12AM
(#898522)
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.
Re:Coding Horror: Treating User Myopia
by pavlov on Friday October 23, 2009 @07:22AM
(#898556)
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).
Re:Coding Horror: Treating User Myopia
by JustAGeek on Friday October 23, 2009 @07:35AM
(#898568)
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.
Re:Coding Horror: Treating User Myopia
by ErrantX on Friday October 23, 2009 @08:14AM
(#898600)
> 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)
Re:Coding Horror: Treating User Myopia
by monos on Friday October 23, 2009 @08:18AM
(#898609)
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.
Re:Coding Horror: Treating User Myopia
by ErrantX on Friday October 23, 2009 @12:00PM
(#898998)
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 :)
Re:Coding Horror: Treating User Myopia
by pwmanagerdied on Friday October 23, 2009 @12:30PM
(#899069)
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.
Re:Coding Horror: Treating User Myopia
by ash on Friday October 23, 2009 @08:46AM
(#898642)
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!
Re:Coding Horror: Treating User Myopia
by rythie on Friday October 23, 2009 @06:32AM
(#898526)
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?
Re:Coding Horror: Treating User Myopia
by JoeAltmaier on Friday October 23, 2009 @10:15AM
(#898774)
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.
Re:Coding Horror: Treating User Myopia
by JoeAltmaier on Friday October 23, 2009 @10:17AM
(#898778)
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.
Re:Coding Horror: Treating User Myopia
by CWuestefeld on Friday October 23, 2009 @08:43AM
(#898640)
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?
Re:Coding Horror: Treating User Myopia
by btn on Friday October 23, 2009 @06:32AM
(#898527)
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.
Re:Coding Horror: Treating User Myopia
by tome on Friday October 23, 2009 @07:03AM
(#898544)
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.
Re:Coding Horror: Treating User Myopia
by forinti on Friday October 23, 2009 @06:35AM
(#898528)
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.
Re:Coding Horror: Treating User Myopia
by audionerd on Friday October 23, 2009 @09:26AM
(#898689)
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.
Re:Coding Horror: Treating User Myopia
by jrwoodruff on Friday October 23, 2009 @12:03PM
(#899005)
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.
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.
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).
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.
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.
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)
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.
The textwalls problem I don't have a solution too :)
I'm not saying that it's at all well-explained on the site, but there is at least a reason behind it.
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!
Lack of richtext editor support in browsers has been the problem so far - but I believe mostly there with contentEditable support in all browsers?
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.
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?
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.
"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.
I wouldn't want this guy doing usability design on my site. Woof.
thats about it. teach them that and you get 80% readable ascii.