A quote from the Discussion section:
"Most of the studies on line length report faster
reading with longer lines, and point to the number of
characters as the variable responsible for the differences, rather than physical line length (visual angle)."
The OP thinks that humans read thinner columns faster. Generally, this seems not to be the case, so maybe we should treat his main conclusion with some skepticism. In any case, it's probably best to refer to the scientific literature.
> The OP thinks that humans read thinner columns faster. Generally, this seems not to be the case, so maybe we should treat his main conclusion with some skepticism.
> In any case, it's probably best to refer to the scientific literature.
You might not think so if you read the literature review which takes up most of that paper. The literature covered is generally focused on questions of no obvious interest and then, even in its own terms, finds little or no effect. Particularly funny is the paper (Youngman and Scharff (1998), covered in §2.7) comparing the independent effect of physical line length vs physical margin length. Or in other words, they investigated whether it's faster to (1) read six inches of text with half an inch of blank page to the right of the text, or to (2) read six inches of text with a full inch of blank page to the right of the text.
The paper you cite also goes out of its way to express the authors' dismay over the extreme nature of one experiment invalidating the finding they wish to support:
> The study also fails to replicate [the finding of] Dyson and Kipping (1998a) and earlier studies that more characters per line can result in faster reading. The difference may be due to the extreme nature of the longest line, i.e. 132 characters in 12 point Arial (rather than 10 point Arial used by Dyson and Kipping). The line length therefore not only has more characters but is also physically longer because of the larger type size.
later:
> A setting with no margin would not be typical practice, but may have been included to assess an extreme of a variable in a similar manner to using 132 characters per line.
How unfair!
Of course, as I read your comment on Hacker News, it contains a line of 130 characters.
This paper isn't even trying to address the questions you think it's addressing.
On HN, your line here is 200 characters in 9pth Verdana, so it's also pretty extreme (perhaps because I have a wider screen). Personally I find the max line length on HN really uncomfortable.
> nature of the longest line, i.e. 132 characters in 12 point Arial (rather than 10 point Arial used by Dyson and Kipping). The line length therefore not only has more characters but is also physically longer because of the larger type size.
I'd say anywhere from 50-100 characters is fine for line length, stray too far outside that and you're not allowing enough words to scan well, or have too many so that it's hard to jump to the next line.
> The OP thinks that humans read thinner columns faster.
Tbf, "reading faster" in the linear sense is probably not exactly the metric to use when writing text. When writing, I usually need to jump randomly a lot in the text to cross reference something (from the last paragraph, the last sentence, or the beginning of the current sentence). It's a kind of nonlinear scanning that I'm guessing could be more efficient in narrow column text, even if wider columns would be faster to read from beginning to end.
Your points help with discounting the claim that long lines read faster. But that does not say anything about OP's claim that short lines are better.
I'm not convinced by OP's argument "New York Times does it": pretty much any book does the opposite.
Perhaps we need more/better research.
For what it's worth, I set my screen to be very wide when I write because I like to write each sentence on a single line: it allows me to easily spot sentences that are too long, a mistake I often make.
The paper focuses more on reading. OP focuses on editing.
Both are very different mindset. The second is supposed to make the first enjoyable and fluid. When editing you need to keep the reading location (kinda “cursor”) and move back to some sentences to test the “fluidness” of the flow. When reading, you don't need to do this anymore. I suspect OP prefers short line length to avoid the cognitive load implied by “finding” words back and forth during the editing step.
I do wonder if scanning is different from sequential reading. When reading code, I'm most often looking for the right place to change or add something.
Thinner columns allow for more of a "Z" pattern of reading, where you can kind of scan-read backwards when your eye scans back to the left, as opposed to the standard "E" style of reading of reading an entire line, returning to the left, then moving to the next and repeating.
Writing in thin columns allows you to keep an eye on what you just wrote more easily as well.
I find this to be super important for noticing when my writing is getting repetitive; when I'm reading in that "Z pattern," it's easier to pick up repeated words or phrases in the last few lines of text.
A vast majority on book typography agrees on 66 characters per line in one-column layouts and 45 characters per line in multi-column layouts as being the optimal numbers for reading. The text-block should also be placed assymetrically on the page, with the margins in size order being inner<top<outer<bottom. The line height should be set at 120% of the highest character hight for normal book typefaces, but should be increased for typewriter typefaces and can be decreased slightly with shorter lines. A small set of typefaces are economic without losing readability, and if you use them you can increase these numbers slightly. But any more than 80 characters and anything less than 40 characters is suboptimal for texts that are longer than a paragraph or so.
If you adhere to these very simple principles, you will have avoided like 95% of the typographic choices that can make texts hard or slow to read.
Robert Bringhurst in "The Elements of Typographic Style" (a bible for this kind of thing, and one of the most beautiful books ever made), has this to say on the topic:
"Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. For multiple-column work, a better average is 40 to 50 characters.
If the type is well set and printed, lines of 85 or 90 characters will pose no problem in discontinuous texts, such as bibliographies, or, with generous leading, in footnotes. But even with generous leading, a line that averages more than 75 or 80 characters is likely to be too long for continuous reading."
This. Art of typography. I stick to this a lot. Major problem here: A lot of corporate templates suck and changing them is pita or impossible due to non negotiable guidelines.
On a related note: At one point I switched to working exclusively on a laptop and after a while realized that the smaller screen had forced me to write better code. I wrote smaller methods, made smaller files, kept my concepts together, the whole nine yards. I even wrote better tests since that helped me keep my work small.
It didn't last; I'm writing this on a 27" monitor, but I think that has more to do with bad laptop ergonomics than space.
> On a related note: At one point I switched to working exclusively on a laptop and after a while realized that the smaller screen had forced me to write better code. I wrote smaller methods, made smaller files, kept my concepts together, the whole nine yards.
Interesting. The programmer equivalent of using smaller plates so you eat less at meals.
I see some coworkers with ridiculous setups. Three monitors, one vertical, one ultrawide and curved. I don't see why you need that much screen to write code... when pressed they say it's for having references, Slack, etc. up on other screens but then you just end up moving your head around a lot (what a pain in the neck!) I do everything on a single 27" monitor.
I'm writing an operating system, its build system, a verifier for it, and writing docs, usually switching often between them. I wish I had that much screen space.
> but then you just end up moving your head around a lot (what a pain in the neck!)
If moving your head causes you neck pain, you should get that looked after ASAP!
Generally, a static posture over a long time is really bad for your health. Make sure to stretch, fidget, move around, change your posture a lot when working with a screen.
I understand you, I also use one primary monitor in front of me. I have another monitor next to it, which I mostly use to put documentation next to the IDE. But the second monitor ist 90% of the time unused. Sometimes I put tool windows (test runner) there. Or something entertaining (YouTube/Netflix) ;)
It depends on the type of work. For people who code like they're writing a novel, yeah, a laptop can be perfect and encourage focus. But for anyone who works with real-time financial data, working on a laptop screen would be a nightmare.
I love coding on a huge 40 inch screen: the main reason is that I can view an entire file without scrolling. Less mental overhead to move your hands means more brainpower is left to do useful work.
I push back on the mantra that smaller methods are always better.
Yes, they usually have less responsibility, by virtue of being smaller. However, sometimes it is best to just get a larger task done in a function. You can have parts of it logically called out, without having to use the languages features for function declaration.
I feel like there is probably something to be said about how well particular languages work with less horizontal space - the more verbose ones out there might lead to code that is so long vertically, that a lot of time will be spent scrolling through it, unless you're using a vertical monitor for that.
Then again, limiting the line width to something like 120 characters should allow you to edit two files side by side simultaneously, or run into far less problems when using something like a laptop, as opposed to having large monitors, while also help people who prefer larger font sizes, so it should be better for accessibility as well.
I currently have about 4 monitors in total, 3 of which are 21.5" at 1080p and there's also one vertical one, which to me that seems like a pretty decent setup - being able to browse code, work in a terminal, preview things in the browser and maybe get a few filesystem windows in there as well seems to improve productivity, all without the tradeoffs that tiling window managers might incur (though mostly just the learning curve) or struggling with software that doesn't work well with less horizontal space.
Of course, the technicalities of getting such a setup working are a bit cumbersome too - i cannot afford one of the fancy VESA mounts, so instead two of the monitors use a DIY monitor leg that's basically one long PVC pipe with some 3D printed mounts and screws, another sits atop of the computer case to the side and the GPU I/O is kind of a mess, since there's occasionally an adapter in there as well (monitors with DisplayPort are more expensive, rather than VGA/DVI/HDMI).
Honestly, it'd be nice to sidestep all of that with something like VR, but we're not quite there yet in regards to the resolution, or may never really get there at a good price point, even if there are some really interesting projects out there: https://arcan-fe.com/2018/03/29/safespaces-an-open-source-vr...
Virtual workspaces (basically multiple desktops) might help mitigate some of the issues, though!
I wonder if this is something analogous to Parkinson's law. I have found that transitioning to a single screen was initially frustrating, but it forced me to adapt to the lack of space by condensing my writing, both code and prose.
It seems intuitively convincing and almost obvious to me that the quality of your output would be inversely proportional to the amount of available "space" for that output, although the exact relationship doesn't seem so clear.
If you have done any typesetting, say for a book, you'd realize that there is a sweet spot between the font size and the number of characters in a line. This has changed little over the hundreds of years. I think some of that effect is what we're seeing on the screen here in this post. There is a lower limit though, if you set the line too small, you'll be scrolling very often as the other comments have pointed out.
Interesting take. On hackernews I also learned about an approach called "ventilated prose" or writing with "semantic line breaks." That is, when you write, say in vim or emacs, you put one clause per line. Then when you are done, you can use pandoc or something similar to convert what you wrote into standard prose. But the artificial line breaks, which results in thin lines, make it easier to edit, and also easier to comprehend diffs if you use git to track changes.
Pandoc ignores single line breaks when exporting markdown.
So all of this
would be treated
as a single sentence.
But an empty space in between indicates a new paragraph.
If for some reason you require to have separate lines, perhaps when enumerating something, you can leave two trailing spaces after the line, that preserves the break.
I always find myself fighting this on practically every website.
But it makes sense to me, that this should be something we think about in, well, most of our editors as well.
I debate about the measure of code, but I do find 100 to be a reasonable fit for most languages. The problem, is that I want code at 100, and then comments at 66. Oh well.
Yeah, I chuckled that page didn't apply the fixed width that it recommended. If you just apply the width rule, it seems to mess up the right column.
It's like a microcosm of how challenging CSS is to get right.
The actual book this website is based on comes from print media. That website is just trying to apply those ideas to the web. And, as we see, not quite getting it right
Readit News
How physical text layout affects reading from screen https://www.researchgate.net/publication/220208446_How_physi...
A quote from the Discussion section: "Most of the studies on line length report faster reading with longer lines, and point to the number of characters as the variable responsible for the differences, rather than physical line length (visual angle)."
The OP thinks that humans read thinner columns faster. Generally, this seems not to be the case, so maybe we should treat his main conclusion with some skepticism. In any case, it's probably best to refer to the scientific literature.
> In any case, it's probably best to refer to the scientific literature.
You might not think so if you read the literature review which takes up most of that paper. The literature covered is generally focused on questions of no obvious interest and then, even in its own terms, finds little or no effect. Particularly funny is the paper (Youngman and Scharff (1998), covered in §2.7) comparing the independent effect of physical line length vs physical margin length. Or in other words, they investigated whether it's faster to (1) read six inches of text with half an inch of blank page to the right of the text, or to (2) read six inches of text with a full inch of blank page to the right of the text.
The paper you cite also goes out of its way to express the authors' dismay over the extreme nature of one experiment invalidating the finding they wish to support:
> The study also fails to replicate [the finding of] Dyson and Kipping (1998a) and earlier studies that more characters per line can result in faster reading. The difference may be due to the extreme nature of the longest line, i.e. 132 characters in 12 point Arial (rather than 10 point Arial used by Dyson and Kipping). The line length therefore not only has more characters but is also physically longer because of the larger type size.
later:
> A setting with no margin would not be typical practice, but may have been included to assess an extreme of a variable in a similar manner to using 132 characters per line.
How unfair!
Of course, as I read your comment on Hacker News, it contains a line of 130 characters.
This paper isn't even trying to address the questions you think it's addressing.
> nature of the longest line, i.e. 132 characters in 12 point Arial (rather than 10 point Arial used by Dyson and Kipping). The line length therefore not only has more characters but is also physically longer because of the larger type size.
I'd say anywhere from 50-100 characters is fine for line length, stray too far outside that and you're not allowing enough words to scan well, or have too many so that it's hard to jump to the next line.
Tbf, "reading faster" in the linear sense is probably not exactly the metric to use when writing text. When writing, I usually need to jump randomly a lot in the text to cross reference something (from the last paragraph, the last sentence, or the beginning of the current sentence). It's a kind of nonlinear scanning that I'm guessing could be more efficient in narrow column text, even if wider columns would be faster to read from beginning to end.
I'm not convinced by OP's argument "New York Times does it": pretty much any book does the opposite.
Perhaps we need more/better research.
For what it's worth, I set my screen to be very wide when I write because I like to write each sentence on a single line: it allows me to easily spot sentences that are too long, a mistake I often make.
Both are very different mindset. The second is supposed to make the first enjoyable and fluid. When editing you need to keep the reading location (kinda “cursor”) and move back to some sentences to test the “fluidness” of the flow. When reading, you don't need to do this anymore. I suspect OP prefers short line length to avoid the cognitive load implied by “finding” words back and forth during the editing step.
Really? This is absolutely the case for me. I use "reader view" / "readability" in Firefox whenever possible and it's incredibly helpful.
I do wonder if scanning is different from sequential reading. When reading code, I'm most often looking for the right place to change or add something.
Writing in thin columns allows you to keep an eye on what you just wrote more easily as well.
If you adhere to these very simple principles, you will have avoided like 95% of the typographic choices that can make texts hard or slow to read.
"Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. For multiple-column work, a better average is 40 to 50 characters.
If the type is well set and printed, lines of 85 or 90 characters will pose no problem in discontinuous texts, such as bibliographies, or, with generous leading, in footnotes. But even with generous leading, a line that averages more than 75 or 80 characters is likely to be too long for continuous reading."
It didn't last; I'm writing this on a 27" monitor, but I think that has more to do with bad laptop ergonomics than space.
Interesting. The programmer equivalent of using smaller plates so you eat less at meals.
Everyone has their own workflows.
If moving your head causes you neck pain, you should get that looked after ASAP!
Generally, a static posture over a long time is really bad for your health. Make sure to stretch, fidget, move around, change your posture a lot when working with a screen.
I used to prefer dual 24" monitors. I felt the physical separation let me better organize my tools.
Now I prefer my 34" widescreen. More flexible, less distracting.
Yes, they usually have less responsibility, by virtue of being smaller. However, sometimes it is best to just get a larger task done in a function. You can have parts of it logically called out, without having to use the languages features for function declaration.
Then again, limiting the line width to something like 120 characters should allow you to edit two files side by side simultaneously, or run into far less problems when using something like a laptop, as opposed to having large monitors, while also help people who prefer larger font sizes, so it should be better for accessibility as well.
I currently have about 4 monitors in total, 3 of which are 21.5" at 1080p and there's also one vertical one, which to me that seems like a pretty decent setup - being able to browse code, work in a terminal, preview things in the browser and maybe get a few filesystem windows in there as well seems to improve productivity, all without the tradeoffs that tiling window managers might incur (though mostly just the learning curve) or struggling with software that doesn't work well with less horizontal space.
Of course, the technicalities of getting such a setup working are a bit cumbersome too - i cannot afford one of the fancy VESA mounts, so instead two of the monitors use a DIY monitor leg that's basically one long PVC pipe with some 3D printed mounts and screws, another sits atop of the computer case to the side and the GPU I/O is kind of a mess, since there's occasionally an adapter in there as well (monitors with DisplayPort are more expensive, rather than VGA/DVI/HDMI).
Honestly, it'd be nice to sidestep all of that with something like VR, but we're not quite there yet in regards to the resolution, or may never really get there at a good price point, even if there are some really interesting projects out there: https://arcan-fe.com/2018/03/29/safespaces-an-open-source-vr...
Virtual workspaces (basically multiple desktops) might help mitigate some of the issues, though!
It seems intuitively convincing and almost obvious to me that the quality of your output would be inversely proportional to the amount of available "space" for that output, although the exact relationship doesn't seem so clear.
I never write code in a full screen window. Either code on two sides or a terminal on one side, etc.
Long horizontal lines really mess with comprehension and attention.
I typically go 13" laptop, but when docked on a 4k screen, I use screen splits to achieve a similar effect.
I'm on a 32" and I don't full screen anything except for the odd video.
https://baymard.com/blog/line-length-readability
So it is different if there is or if there is not a line break.
How do you manage it? Double line break?
But an empty space in between indicates a new paragraph.
If for some reason you require to have separate lines, perhaps when enumerating something, you can leave two trailing spaces after the line, that preserves the break.
http://webtypography.net/2.1.2
I always find myself fighting this on practically every website.
But it makes sense to me, that this should be something we think about in, well, most of our editors as well.
I debate about the measure of code, but I do find 100 to be a reasonable fit for most languages. The problem, is that I want code at 100, and then comments at 66. Oh well.
It's like a microcosm of how challenging CSS is to get right.
The actual book this website is based on comes from print media. That website is just trying to apply those ideas to the web. And, as we see, not quite getting it right