3 ms·

The results of the study are a bit counter-intuitive for me. I prefer to read and write software with <80 cpl, and find it difficult to read programs with longe

by z0r 12y ago

The results of the study are a bit counter-intuitive for me. I prefer to read and write software with <80 cpl, and find it difficult to read programs with longer lines. Maybe the difference between reading articles and software is to great to expect the same kind of outcome. In any case I don't think 95 cpl is an extreme enough line length to be really interesting. It would have been nice if they had run the study with more testing points at longer and longer lines until they found a point where reading speed dropped or comprehension suffered (if there is such a point, maybe not?)

JimDabell 12y ago
> I prefer to read and write software with <80 cpl, and find it difficult to read programs with longer lines. Maybe the difference between reading articles and software is to great to expect the same kind of outcome. Maybe the characters per line is not the relevant data point. The fact that there are so many studies that give wildly varying results using this measure seems to be a strong indicator that this is the case. They chose specific font metrics, and used a single monitor at a single distance in a single context, so they have no way of knowing whether it was the physical width, the pixels per degree, or some other factor that they were actually measuring. Think of it this way: if they had doubled the text size, that would undoubtedly have resulted in far wider line lengths in physical terms, yet the characters per line would have remained the same. If they rigged the conditions so the physical width and characters per line were fixed in lockstep, were they measuring responses to the number of characters per line, or were they really measuring responses to physical width? There's no way of knowing with this study. Any study like this that could usefully be applied to the web needs to take into account varying font sizes and all the other things that make the web different from print. Fixed font sizes in pt is not how the web operates.
teamhappy 12y ago
Compare 95 cpl Times New Roman at 12 pixels to, say, 80 cpl Source Code Pro at 14 pixels. People are more efficient at reading at a certain cpl because the eyes don't get tired (less movement) and it's easier to find the beginning of the next line (maybe I'm the only one who has trouble with that for long lines). Most of these factors depend on the typeface used, the font size, line height, and of course, the distance between your eyes and the medium your reading. When you're talking about code the syntax of the language probably plays some roles in all of this as well (Python is a narrow language, C++ isn't, JavaScript needs lots of indentation, etc.).
marvy 12y ago
There is such a point. If you have a widescreen monitor, you can verify this by maximizing your browser window and trying to read that article. I tried this. I couldn't take it. I then resized my browser to half the screen width (which in my case is 800 pixels) and was able to read it comfortably. But the comfortable size was still much more than 100 characters per line! (If you count spaces. I'm not sure if I'm supposed to count spaces. But even if you don't count spaces, the first line of the article on my half-screen browser had 102 non-space characters.)

by z0r 12y ago

JimDabell 12y ago

> I prefer to read and write software with <80 cpl, and find it difficult to read programs with longer lines. Maybe the difference between reading articles and software is to great to expect the same kind of outcome. Maybe the characters per line is not the relevant data point. The fact that there are so many studies that give wildly varying results using this measure seems to be a strong indicator that this is the case. They chose specific font metrics, and used a single monitor at a single distance in a single context, so they have no way of knowing whether it was the physical width, the pixels per degree, or some other factor that they were actually measuring. Think of it this way: if they had doubled the text size, that would undoubtedly have resulted in far wider line lengths in physical terms, yet the characters per line would have remained the same. If they rigged the conditions so the physical width and characters per line were fixed in lockstep, were they measuring responses to the number of characters per line, or were they really measuring responses to physical width? There's no way of knowing with this study. Any study like this that could usefully be applied to the web needs to take into account varying font sizes and all the other things that make the web different from print. Fixed font sizes in pt is not how the web operates.

teamhappy 12y ago

Compare 95 cpl Times New Roman at 12 pixels to, say, 80 cpl Source Code Pro at 14 pixels. People are more efficient at reading at a certain cpl because the eyes don't get tired (less movement) and it's easier to find the beginning of the next line (maybe I'm the only one who has trouble with that for long lines). Most of these factors depend on the typeface used, the font size, line height, and of course, the distance between your eyes and the medium your reading. When you're talking about code the syntax of the language probably plays some roles in all of this as well (Python is a narrow language, C++ isn't, JavaScript needs lots of indentation, etc.).

marvy 12y ago

There is such a point. If you have a widescreen monitor, you can verify this by maximizing your browser window and trying to read that article. I tried this. I couldn't take it. I then resized my browser to half the screen width (which in my case is 800 pixels) and was able to read it comfortably. But the comfortable size was still much more than 100 characters per line! (If you count spaces. I'm not sure if I'm supposed to count spaces. But even if you don't count spaces, the first line of the article on my half-screen browser had 102 non-space characters.)