This resonates with me. I typically narrow my Outlook windows to ensure a certain look/feel to my line length and breaks. I get flustered any time the window stretches across the the screen. So fun to read through another person’s experience with this.
Interesting. Scrivener 3 actually defaults to using no where near all the screen real estate for words when writing, keeping it in a thinner column (which I now wonder if has a way to configure it), and I wonder if a similar idea was why they did that.
So turns out you can configure it. On Windows under file -> options -> appearance button at the top -> Main Editor then change the default editor width. I assume it is at least similar on Mac though the tutorial I saw said the first part was Scrivener instead of Windows.
+1 about the tall and narrow, especially for editing.
I used to work from my friend's office who has these giant monitor that can pivot 90 degrees and I was easily 1.5x or 2x more productive given how much text was on the screen (almost and entire section of the book), and so I didn't have to scroll much...
First thing I noticed when getting a rotating monitor and put it in portrait mode was that reading speed went up. Not sure if it's less head movement and consequently neck strain, but anecdotally this helped my reading speed. Not sure about writing.
Great insight ... most Bibles are formatted with thin columns as well. Maybe why it is easier to memorize as well. I got to try this for writing! I don't know why I didn't think of this.
Someone there mentioned that Firefox supports this. I just tried it (it's called 'Wrapped Scrolling') and it works well. I can't see how to advance by a single page at a time, but that's minor thing.
Does anyone know how to get the narrow column at the center of the screen in full screen mode pictured in the article using vim settings? see https://breckyunits.com/writeThin.png
I tried :set textwidth=<tw>, but that gives left aligned so not quite the same...
Here are the additions to ~/.vimrc in case anyone is interested (this after installing vim-plug https://github.com/junegunn/vim-plug#unix and running :PlugInstall as per goyo instructions:
set wrap linebreak nolist
call plug#begin('~/.vim/plugged')
Plug 'junegunn/goyo.vim'
call plug#end()
"Goyo settings
let g:goyo_width = 60
let g:goyo_height = 999
let g:goyo_margin_top = 0
let g:goyo_margin_bottom = 0
Interesting. The tradeoff is of course that the wider columns are the more you're able to see at once, which is also important for editing.
I wonder whether it would be useful to be able change the column width with a keyboard shortcut. That way you could use small columns when you want to focus on the details and bigger columns when you want to focus on the big picture, both in writing and reading.
Interesting - I think wider columns produce exactly the opposite outcome. Too much space to cover and width to contemplate, hampering my ability to edit quickly. I don't think the width extra width helps you ingest and manipulate the words more efficiently.
The horizontally-condensed version of the same text allows me to see all of those same words, by the way. Just laid out in a format that isn't quite so exhausting to handle.
I even narrowed the HN editor while writing this reply and editing it for mistakes/grammar.
I don't mean that the extra width itself helps, I just mean that assuming vertical space is limited, then extra width means more words fit on the screen.
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
I also find paragraph length affects my reading speed and focus.
When a paragraph is too long I tend to skim past it, even though the same paragraph split into a few smaller paragraphs would have the same word count.
Here's a tip, read the first line of each paragraph you skip. A properly structured paragraph contains a 'thesis statement' in the first sentence most often. From there you know whether you want to complete the paragraph or not because what follows are usually supporting statements.
I think Hemingway mode is when backspace and delete are disabled. Ghostwriter (https://wereturtle.github.io/ghostwriter/) has Hemingway mode and another mode that they call "distraction free mode" which highlights just the current sentence.
FWIW I find it really distracting to have the current sentence highlighted because it means the file's appearance changes more than it otherwise would. Sublime Text has a "distraction free mode" (shift+F11) which goes to fullscreen, hides all menus, limits the current file width, and centers the file's contents.
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 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.
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.
> 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.
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.
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.
Yes, that's true. I was not trying to dispute or support OP's claim that short lines are better. I was trying to dispute my immediate parent's claim that the way to handle questions like this is to refer to the scientific literature.
> 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.
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.
> On HN, your line here is 200 characters in 9pth Verdana, so it's also pretty extreme (perhaps because I have a wider screen).
I'm actually doing two things to shorten the line width as measured in characters. #1, my browser window is set to a size I find reasonable, not fullscreen. #2, I have HN configured at "110% zoom" (not sure precisely what that means, but it's how Firefox reports it), which makes the text larger and therefore allows fewer characters per line.
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.
Blog author suggests 36 characters. I have done 50 before but am now tempted to try 36.
Edit 1: I did some quick experimentation with columns that were 36, 40, and 50 wide. There is something magical about 36. With 50 my eye movements were conscious. With 36 it was as if I was able to read the whole column in peripheral vision. Much more immersive. I wonder now about narrower fonts, if they could produce the same effect.
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) ;)
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.
Yeah, I read that one. As others in that thread point out there is research that actually shows long lines are better (with yet others in that thread questioning that research, but alas, it's certainly not a given shorter is better)
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 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 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.
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've found that when I condense an impressive amount of information down to 280 characters, the compression is lossy. People only pick up one tidbit out of the several that I've packed in; or maybe they'll come away with a completely wrong interpretation. Hell, even when I come back to my own writing, I find that it's too clever by half and I can't extract the nuance that I expected to be clear.
145 comments
[ 4.4 ms ] story [ 199 ms ] threadBut I find this insight more or less convincing so I guess the ideal writing screen is thin and tall.
Sadly, that’s the opposite of what horizontal monitors encourage. This might be another benefit of physical notebooks.
I used to work from my friend's office who has these giant monitor that can pivot 90 degrees and I was easily 1.5x or 2x more productive given how much text was on the screen (almost and entire section of the book), and so I didn't have to scroll much...
H
E
R
E
I
S
A
L
I
M
I
T
https://www.w3.org/International/articles/vertical-text/
I don't use Windows, but your comment led me to look at this GitHub issue discussing this feature in SumatraPDF: https://github.com/sumatrapdfreader/sumatrapdf/issues/246#is...
Someone there mentioned that Firefox supports this. I just tried it (it's called 'Wrapped Scrolling') and it works well. I can't see how to advance by a single page at a time, but that's minor thing.
I tried :set textwidth=<tw>, but that gives left aligned so not quite the same...
Here are the additions to ~/.vimrc in case anyone is interested (this after installing vim-plug https://github.com/junegunn/vim-plug#unix and running :PlugInstall as per goyo instructions:
I wonder whether it would be useful to be able change the column width with a keyboard shortcut. That way you could use small columns when you want to focus on the details and bigger columns when you want to focus on the big picture, both in writing and reading.
The horizontally-condensed version of the same text allows me to see all of those same words, by the way. Just laid out in a format that isn't quite so exhausting to handle.
I even narrowed the HN editor while writing this reply and editing it for mistakes/grammar.
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
When a paragraph is too long I tend to skim past it, even though the same paragraph split into a few smaller paragraphs would have the same word count.
Actually how I do most of my bulk writing.
FWIW I find it really distracting to have the current sentence highlighted because it means the file's appearance changes more than it otherwise would. Sublime Text has a "distraction free mode" (shift+F11) which goes to fullscreen, hides all menus, limits the current file width, and centers the file's contents.
It’ll use your buffer settings so if you’ve configured Markdown to only be 60 characters wide, it’ll look like the photo in the article.
Writing in thin columns allows you to keep an eye on what you just wrote more easily as well.
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.
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.
> 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.
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.
Yes, that's true. I was not trying to dispute or support OP's claim that short lines are better. I was trying to dispute my immediate parent's claim that the way to handle questions like this is to refer to the scientific literature.
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.
> 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.
I'm actually doing two things to shorten the line width as measured in characters. #1, my browser window is set to a size I find reasonable, not fullscreen. #2, I have HN configured at "110% zoom" (not sure precisely what that means, but it's how Firefox reports it), which makes the text larger and therefore allows fewer characters per line.
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 just checked, and it looks like Ulysses has a default width of 64 characters. Swapped it to 50. Let's see what happens.
Edit 1: I did some quick experimentation with columns that were 36, 40, and 50 wide. There is something magical about 36. With 50 my eye movements were conscious. With 36 it was as if I was able to read the whole column in peripheral vision. Much more immersive. I wonder now about narrower fonts, if they could produce the same effect.
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.
I'm on a 32" and I don't full screen anything except for the odd video.
Interesting. The programmer equivalent of using smaller plates so you eat less at meals.
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.
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.
https://news.ycombinator.com/item?id=29166673
It really got me thinking about monitor setups and how much space you _really_ need to write code.
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.
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.
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.
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!
In my experience, when I try to convert a text into tweets, it gets more concise.
I'm often baffled how much I can condense information down to 280 characters.
I wouldn't try to convert everything to one tweet. Often, I need to split it into a thread.