One cannot condemn simplicity in favor of something that should be complex simply because we are used to things that way. It is our job as designers to turn these very concepts around.

“Every day after a user begins learning your design, they move more toward that expert category.” Right on, it is the failure to foresee scalability that prevents users turning into power-users.

Andy Rutledge has an interesting post about this, Complex Order, Simple Chaos.

:) Well, I’m one of them so I just want to confirm some things and sort them out.

BTW, @Jackson This is a nice read. Thanks!

In our testing, which was done originally in 2002, we found that 72-96 had the best reading and retention rates. We saw reading and retention drop off around 110-112 characters per line (12-14px font size 1.125-1.5 line height). We’ve done a number of studies since, where line length wasn’t the focus of the study, but a secondary measurement, and we continue to see the same results today.

The crux of the issue is that people say they “prefer” to fill their browser windows, but when line lengths get over 110, they’re actually doing themselves harm, or creating sub-optimal situations.

I didn’t think about it, but you’re right about the cultural considerations. Do you have any references or resources pointing to why Asian societies value busy UI’s? (Other than just looking at their designs.)

Thanks! =)

It’s probably important to remember, in this discussion, that accessibility is not a standing target. Being accessible to a mass audience often means avoiding overwhelming a user, and is far different from being accessible to experts who usually want all relevant information. Every day after a user begins learning your design, they move more toward that expert category.

There are cultural considerations as well: Asian societies value a busy interface far more than one more simple.

@Karine: I don’t think today’s web *should* be about blind simplicity, but I think there are far too many examples that simple approaches are chosen when a more complex approach is really needed to solve the problem.

Today’s web is all about providing the simplest answer to a given problem. Yet, simplest can still be complex if you indeed take into account parameters that really matter.

Like the minimalist artwork of Sol Lewitt, there is beauty in simple rhythms, shapes, lines, forms, but I find work like the Issenheim Alterpiece to be unbelievably human and deeply compelling. The Altarpiece is complex, and possibly even over-busy by today’s standards, but it remains the more accessible piece by a greater number of people.

I wonder how those principles play into how we architect and design for the web?

It’s powerful stuff, even if it’s not tied to a mobile device.

On the 508-compliant project that went through ten iterations, I would copy the entire set of wireframes and add in the new functionality. The previous iteration’s signed and approved wireframes were saved for baseline purposes. Inevitably, post signoff, there are always additional changes, and when necessary, the wireframes would be updated. However, I still haven’t fully reconciled how to ensure the wireframes completely match all the functionality of the production version. For the most part, the last set of wireframes is a reasonably close match to production.

There has been some talk of creating our own custom UI control library with a corresponding list of visual icons. The IAs/UI designers could use the icons in the design and the development team would then know that those match up to a specific component in the UI control library. However, we haven’t fleshed this out yet. It seems like it would help by eliminating the IA/UI designer’s need to spend excessive time tweaking the HTML prototype, and the developers would already have a reusable component to start from and customize as necessary. It sounds efficient in theory, but I’d be curious to know if anyone else had implemented a solution of this sort.

I can read small print on a cereal box, but I sure don’t enjoy it. (But alas, I have nothing better to do at the breakfast table :)

Very useful tutorial!  Such a simple thing, but think how many UX lives it can make better.

It’s too bad you didn’t finish, or we’d have been able to see how the combination impacted you!

PPS: the lines spacing of the text in these comments here is much better than the one from your test.

I believe, a bigger line spacing would have improved readability of the textmuch more, than shorter lines would.
So here’s food for another stufy ;-)

Thanks for sharing,
Mike

It’s certainly a belief of mine that research should be readily available to the industries it impacts as much as possible.  For those who work on the web, “readily-available” is largely synonymous with “googleable.” If we were talking about a field dominated by academia, it would, I argue, be a different story.

I assert that a decent estimate you can put your hands on, as a practitioner in this field, is far better than the best-laid research you can’t. What we’re offering is an attempt at a decent estimate, and that’s all it claims to be.  I welcome your dissent as well as your support.

I don’t find it “unsatisfactory” that peer-reviewed research is published in actual journals. You seem to think everything should be Googlable. What if not everything should?

Really, you seem to be insisting that “dissent” disproves reputable scientific claims because you can’t search for and read those claims from your iPhone.

I’m not even going to bother with your pointless little demo. Hire a Ph.D. to run a real controlled experiment and then we’ll talk.

I found that XHTML prototyping makes sense when I free-lance and have a close relationship with my client. With less parties involved, I can take the time to explain UX, aesthetic, and behavioral decisions step by step, and gain the trust of the client by involving him that much in the process.

On the corporate level, however, some rules are fixed through strict guidelines, others through experience, and yet others are my personal view on the question after testing what works and what doesn’t. Showing an XHTML prototype or even a wireframe to the hierarchy is risky at best, for the amount of questions regarding revisions is unlimited. This environment leads me to favor non-recyclable work that is really explicit of the expected production level: a photoshop comp, sometimes as stand-alone, sometimes as background of an XHTML-enhanced prototype.

I guess my goals are different depending on the environment… In the first, it is a real dialog. In the second, I need validation as quickly and painlessly as possible. The discussion has not mention the client’s experience.

The line length was uncomfortable, but not so much to be unreadable. The terminology of the piece made it difficult to comprehend at first and I found myself re-reading whole sections. Also, knowing it was a test of some sort, I forced myself to read it more carefully than I might have under other conditions. The questions themselves were about pivotal or repetitive portions of the text.

I can’t help but wonder if those things will skew your results.

Still, I’m sure you’ve thought about some of this and I’m interested to know what your testing criteria are. I certainly appreciate something simple that continues the conversation while its hot. :)

I also want to read more about this now.

However, it’s a bit unsatisfactory that the relevant research isn’t terribly accessible to the people who need it most.

So today, we opened a bit of a research project that might help the situation a bit.  Head on over to http://readability.viget.com where we have a timed reading sample and some straight-forward comprehension questions.

Maybe we can come closer to some decent conclusions.

In other words, this post’s reliance on a single study is unwise.

@Carson — Glad to hear it’s working for you too!

@Brian — It ended up about 1:2 in terms of time spent sketching to doing the walkthroughs.

I’d imagine you’d want a good amount of time to extract concepts and goals from visual UI sketches with the client. How much of the allotted time have you been spending in executing the exercise versus reviewing its outcomes in meetings?

@anon, I’ve found that an internal cardsorting exercise, in an IA-driven project, can produce the same type of results, where clients are describing often specific content/functionality first which later generate (via a review) concepts and goals.

Keep getting the word out. Great stuff.

You really can’t have a productive discussion of line length without discussing height and spacing. This topic has been explored so extensively in real, peer-reviewed and published academic research studies that you can’t just say “Users will be perfectly fine reading longer columns of text.” It’s like saying “it’s perfectly fine to use Flash on any site you want” and leaving it as a blanket statement without even mentioning accessibility, seo, penetration, etc. It’s so vague and incomplete as to be misleading and effectively would be bad advice if followed literally.

To readers who want to know more, get on an academic research database and search for ‘readability’. There’s plenty of information out there waiting for those willing to search for it.

I find simpler and more efficient approach is to just create a bunch of grey boxes (using divs, 960.gs and some minimal CSS) to represent the layout of the new features, then fill those boxes with textual information about interactions, states and functionality. In the case of forms I just go ahead and markup the forms straight off. It is a very low-tech approach. :)

There is very little duplication of work doing it this way because you need that markup anyway, and the only CSS you need is to color the boxes different shades of grey to differentiate them from each other.

Incidentally I found a jQuery library the other day that you could use if you want to get a bit more sophisticated with representing different states in your wireframes: http://24ways.org/2008/easier-page-states-for-wireframes

That said, this is an area that could probably use some more research/study. The medium (paper vs lcd) may affect this rule, but only in the sense that the light coming off the screen will burn your eyes out.

Plus research should never stop.

1. To help the reader easily find the next line of text.
2. To cause less distractions.
3. To not tire the reader.

All 3 improve readability. Speed and efficiency aren’t the main priorities of the rule. Speed actually doesn’t matter at all and faster reading could affect comprehension.

I think test is flawed because it’s measure the wrong attributes.

@John, I’m curious how you’ve managed the wireframe styling/presentation of new pages when working in a currently designed app/site. Do you have separate CSS files for wireframes and the final site design? Also, when working in these new pages, how do you find yourself describing interactions, states and functionality?

I like the idea of making this work more transparent to the client through your suggestion of weekly releases. It definitely fosters education on the design/UX process and why its there. I’d assume you’d need to set expectations with your client in a few ways with these releases, but aside from that, have you noticed any downsides to working this way?

For example, I can think of a couple of reasons why line-length MAY be allowed to get longer on the web:

a) Writing *tends* to be in shorter paragraphs, broken up by blockquotes, lists, and other visual clues. Links, bold/italic text, and other graphics alongside the copy can all aid the eye when returning to the beginning of the line.

b) For some readers, the distance between the top of the viewport (think of this like a ruler or bookmark) might be much closer to the text itself than the top edge of a book (if no other aid is available). This can aid visual location, and scrolling down a page is natural and easy whilst reading a long article.

Based on my current understanding of the (limited) research I’ve read based on Tiff’s reply, though, the way we read would be impacted less favorably by the distance to the object than one might expect.

My understanding is that the time involved in the eye movements made while reading is fairly negligible, while the fixation of the eye on a set of characters is really what’s taking up the time.

One other thing I didn’t see mentioned that could be a possible reason people are able to read longer lines on screen without a drop in efficiency: distance to screen. We’re generally farther away from a screen than we would be holding a book at half-arm’s length, meaning that our eyes have less distance to travel (and thus take less time to travel) to the beginning of the next line.

Interestingly, Google Reader goes up to about 115cpl.  And, for what is worth, I usually enjoy text in Google Reader more than I do at the original source.

My reading experience also agrees with what Doug says about paragraph length.  Longer lines can make text look weird when paragraphs are short (and when paragraphs are separated by the full height of one line, as is the prevalent convention on the web).

Cheers!

@Jackson: Yeah, definitely agreed that this is far from conclusive, but I think it’s more valuable to note that the traditional limits may be limiting without reason.  Experimentation by designers in this area should be welcomed and embraced.

@Victoria: Obviously I should do a bit deeper dive into the books to see what’s out there.  I’ll see what I can come up with.

@Brian: There’s probably (my hunch) a significant impact from the role of the text being set.  Text to be scanned probably calls for more fragmentation (more, shorter paragraphs and a shorter line length), while text to be absorbed—like an essay—may benefit from these longer lengths.  It’d be an interesting factor to bring in, and things like journalism kinda fall in-between.

@Tiff: There’s a reason you’re one of my favorite people. Good food for thought there. I’ll have to look this stuff up, but if three saccades is 64-84, why not four saccades (which napkin math suggests is 85-112)?

@Wolf: True, but there may be something to the notion that efficiency (especially when it comes to comprehension) is dependent on comfort, especially over a longer span of time.  If you’re able to quickly comprehend something, does that imply a level of reading ease/comfort? If so, providing text that is most quickly and easily understood is tantamount to providing the most comfortable text setting.

Lots of geek-out stuff in there, really—probably too much for sane design discussions; leave cones, rods and hot/cold color palettes for later, for sure.  However, I do recall a lesson about short sentence lengths on the web changing things up a bit.  Same with text legibility and contrast.  Studies on the ACM somewhere (shot not look them up again) indicated that eyestrain and/or dyslexia is more than often mapped to irregular saccadic movements.

Our sources for line-length design conventions may lack guts under scrutiny, but understanding vision adds back some of that grounding.

I’d love to see more research how leading affects readability and if the same results hold true for older generations. There are so many factors involved that I think it’s hard to make a blanket statement.

This is probably related to my reason for preferring shorter line-lengths: scanability, for lack of an actual word.  I find it much easier to scan a page of content that has more narrow columns of content.  I can jump around, re-find my place, and quickly pick out sections of content that are most important to me.

If I’m committed to reading every word regardless of line-length (as was the assignment in the study you reference), I would expect that speed, efficiency, and comprehension would probably be about the same for me.  But, frankly, I rarely ready every word—especially on the web—so I’d seek out a format that I can more easily scan.

1) How long are your paragraphs? A strong visual cue for finding the “next line” is its distance from the beginning or end of a paragraph. The further you get from one end of a paragraph, the harder it seems to repeatedly find the next line. Inversely, it can be difficult to deal with lots of super-short paragraphs that stripe up the page. Stretching line-lengths can help keep long paragraphs to a healthy 4-8 lines, while reducing them might help bump up staccato ‘graphs to the same line number.

2) How are the lines spaced? Compare the reading experience on Victoria’s (excellent) link to an article on Ars Technica: I definitely find the latter ‘preferable’, and (anecdotally, of course) don’t notice a drop-off in reading speed or focus. Spacing could be a third factor that interacts with the other two.

It’d be fun to see some research done with mixed factors like these, I imagine there are some semi-ideal ratios out there to find…

I might be a little cautious about tossing out the perceived wisdom.  It’s true that the line lengths increased reading speed, but it doesn’t look like there are any meaningful conclusions to be drawn about optimal lengths for comprehension, efficiency, or even user preference. Of course, there weren’t any significant negative effects found either.

In the end, it’s nice to know that I probably don’t need to be so anal about line lengths.

PS: I really wish they’d published their full data tables.