Optimal Characters Per Line
mikeyanderson.com
mikeyanderson.com
As long as browser zoom works, though, I don't think it's a huge deal if people have preferences for larger or smaller fonts. Firefox, at least, even remembers your zoom level between visits to the same site. What really annoys me is that browser zoom breaks some sites. I'd recommend testing your site at one or two zoom levels in and out and see if the results are at least vaguely usable.
Sadly, Web 2.0 seems to be desperately trying to re-tread all of the worst aspects of 1.0 design with framesets, animated banners, moire backgrounds, and the like. Some of the worst comes from Google -- G+ and many of the newer Blogger styles are completely unreadable.
gwern, who posts frequently to HN, has one of the better site designs. Medium is actually Excellent. But it's rare enough that I encounter such sites that they're far more remarkable than they should be.
I don't think the author can show that this big font provides better readability.
One can easily make assumptions on how far the average reader views the screen and optimize the font size to that. As the comments here show, the font size selection here is too large.
--------------------
Reading it on a 27" 2560x1440 display was really nice. Same in vertical mode on a 9.7" iPad, but not so good in horizontal mode; it felt constricted like watching a letter-boxed 16:9 movie on a 19" 4:3 TV screen.
What I've found is that optimal text formatting varies greatly across devices. This is very hard to design for due to the variety of screens. From small screen devices like cell phones and gray-scale Kindle's, through larger 24" - 30" monitors and even larger HDTV's. On top of that there are DPI variances.
I've always been a fan of MVC, separating the model (actual document data/text/pictures) from the view (how it's displayed), and using a controller (device/screen-specific code) to display things optimally.
It would be nice if there was a standard that existed allowing authors to simply write documents, saving them as models. Then, each device could read from a standard model file and, using custom controller code, generate a view displaying the text/images optimized for its display.
Right now you see web developers creating multiple CSS layouts for different screen layouts. This works for most cases, but not edge scenarios. It feels very hacky, and I can't foresee people building websites/content-delivery-mechanisms like this 10 years into the future. There must be a better way.
This standard is called "HTML". What you describe is the entire idea of HTML. Frankly, it's embarrassing that a web browser presented with a long stream of text won't keep the line lengths capped at a reasonable length.
Marked on the Mac, which is a Markdown renderer, loads .mmd files and renders them against a CSS template which you can swap out. That fits the MVC idiom nicely, although far from a perfect implementation as it's merely meant for viewing markdown files, not everything on the internet.
Same reaction as OP, same monitor dimensions (both resolution and physical size) as you. Head to screen distance is probably around 2 feet?
Having ~60 character columns is the important thing. Large fonts, not so much.
https://addons.mozilla.org/en-US/firefox/addon/nosquint/
My pet peeve on layout is when a page is multi-column, but each column is taller than the viewing window, so the reader must scroll or page down in each column, then go up for the next column, then down to the next page.
This issue often shows up in PDF versions of scientific journal papers.
Bonus points if a "page down" function operates on the source page images rather than on the window view (iow, if repeated "page down" only shows the top of each source page, rather than each visible part of the viewing window.) Mouse-wheel scrolling helps, modulo interface "features".
There's a reason I limit my source lines to 78 columns too. Well, many reasons if you consider 80x25. :-)
For HN, I personally set a max-width of 700px on .comment and pre blocks, to go with fonts of around 18px. If anyone new to Stylish wants the exact overrides I use to paste in verbatim, feel free to ask and I’ll look them up.
On my laptop screen a single line is about 35cm long and individual glyphs are about the size of those used in my 3 year old's book. In fact, this is exactly the problem with all such websites - they all look like kindergarten books. It is as if they are trying to speak to you s-l-o-w-l-y because you are both dumb and legally blind.
I don't think that's what the author intended. Back to the drawing board I reckon...
I've written books in both LaTeX and QuarkXPress and they were always using justification.
Actually most books in english / french are justified (and probably many other languages) are justified. Heck, I couldn't find a single book here not using justification and my oldest book (16th century!) is using justification!
As a matter of personal preference I find justification way easier on the eyes than justification (as long as hyphenation is done right) and I'm very thankful that most books out there are using justification.
Of course justification on the Web is hard, especially without hyphenation and even more so if you try to use lines with few characters.
But I find it a bit weird to "make a point" by taking of picture of a book which is jagged right when something like, say, 99% of the books out there are using justification.
And you could go farther and say "as long as justification is done right." All browsers that I've seen do justification use a very simple algorithm compared to LaTeX, Quark, and InDesign, and bad justification -- which tends to leave huge gaps of white space between words -- is harder to read than ragged right.
Personally, I think the best you can do reliably on the web right now is ragged right with CSS3 hyphenation enabled for elements that contain body text. But I wouldn't turn on full justification.
The studies I've heard of discuss how ragged right is easier for reading and comprehension, due to the 100% consistent spacing between words.
On some sites the word-spacing is so jarring I find myself wanting to leave the page even while I'm trying to read what it says ... one of those situations where, if you notice it, it's because there's something wrong going on.
I find it sad that the web page (every web page) has to do it. It would be so nice if the web page were text, which the browser displayed.
Sorry to be that guy. I only point out grammar flubs if they are on 20px font or greater.
He's also committing the fatal sin of mixing ems (for his h1 title font size) and px (for his h1 line height). The result is overlapping characters: http://i.imgur.com/tEplJmv.png
I've griped on HN (and elsewhere) more than once about small fonts, low contrast (http://www.contrastrebellion.com/ can't get enough good words from me), and the reading-friendly tools such as Readability.com (despite some recent updates I'm not entirely happy with), InstaPaper, Pocket, etc. The latter are a great way to avoid this pain with minimal effort, and "read now" bookmarklets make this pretty near instant for most users. The styles presented by any of these services would do well as a default for virtually all content-rich sites.
I also have become all but obsessive in restyling sites whose CSS fails me. Which is to say, most of them (including Hacker News: http://stylebot.me/styles/2945). Using the Stylebot Chrome plugin, I've created, as of this writing, 819 stylesheets (some applied to multiple sites, some the same basic "unstyled.css" sometimes lightly modified). I think I've reached the point where I can make some fairly definitive statements, at least as far as UI/UX goes:
⚫ Use ems. Do not use px (graphics positioning excepted). NEVER mix ems and px.
⚫ Provide a high contrast between foreground and background. No, you're not limited to black on white (though it's a safe choice). Brad Frost's website illustrates a styled but very clear example (and it's what he does): http://bradfrostweb.com/ (It's also a beautifully fluid site).
⚫ While we're talking about contrast: take your "but black on white is too much contrast" talk and bin it. The guidance for brown type on an off-white page is for paper. Which is a reflective medium. Screens are, almost always, emissive. Which is to say, they have a maximum brightness, a much lower native contrast ratio than paper, and their display properties get markedly worse as ambient light levels increase. Most displays have a brightness/contrast control which can reduce the maximum brightness, and on many devices this is either automatic or easily accessed by the user (Fn+PgUp/PgDn on my Thinkpad, Macs have similar controls). However they cannot be pushed over their maximums, and in many cases, that's going to be insufficient to read your tiny low-contrast font. In my experience, any text at #333 or lighter is already too light.
⚫ Single-column designs are almost always preferable to multi-column. With an adaptive width, this will frequently address the needs of both desktop and mobile users with very few additional adaptations.
⚫ Respect your user's font choices. There are two classes of user: those who've selected font sizes to address their reading comfort and/or visual needs, and those who have no idea or clue. By forcing a specification on them, you're frustrating both. Using relative sizes "medium", "smaller", "larger" is a better bet.
⚫ Break the zoom button and you may not die, but your page is dead to me.
⚫ Don't include iframes with their own stylesheets. These cannot be overridden by the user. And yes, I'm talking to you, Amazon. Given the visual discomfort these elements present, I've simply set them to "display: none".
⚫ Don't explicitly scale HTML elements (p, a, li, tr, td, ol, ul, dt, dd, blockquote, pre). Style classes or IDs instead. One of my quick-and-dirty fixes is to apply an "important!" inherit property to each of these elments. CSS hackers will know about reset.css stylesheets, these can be useful to users as well.
⚫ Don't push your text to the edge of the screen. Another style I apply to virtually all sites is a "padding: 0 2em 2em 2em;" to the main text block. Generally padding at the top isn't necessary, but keeping the text from running straight into the gutter greatly improves readability.
⚫ It's hard to go wrong with a 45-55em max-width, auto width, and auto left and right margins.
⚫ Put some fucking padding and/or margins around images and other inline elements. 0.5 - 1em at a minimum.
⚫ CSS columns (a trick I picked up recently here on HN) are a good way for presenting your navigation / sidebar elements. Not supported in all browsers (what is), but the good ones do. You can see them used in the article below.
⚫ And if I sound fucking grumpy, it's because I am fucking grumpy. My first response to opening your goddamned webpage shouldn't be "fuck it, do I really want to spend time fixing this?" Because usually the answer is "no."
I recently posted to reddit with several specific examples of sites converted from multi-column to single-column:
http://www.reddit.com/r/webdev/comments/1tm4ox/user_site_res...
https://chrome.google.com/webstore/detail/clearly/iooicodkii...
Swapping your video: http://fixyt.com/watch?v=1FmwefTTnbo
Unmentioned feature: export page as ePub for use on any electronic book reader.
My primary use case, though, is in organizing content I find online related to a research project -- the ability to tag, star, and archive content is particularly useful. Though I do wish the management and search tools were more powerful.
I'll also note that numerous of these problems have been encountered specifically with commerce sites (several, Target specifically comes to mine, broke zoom).
Now, of course, if your goal is (and/or business model depends on) having frustrated, clueless users on your site you can invert all my recommendations and do peachy.
div {font-size: .5em; }
And you have this HTML
<div><div>Hello</div></div>
The actual size of "Hello" would be .25em. If you want a font to have a font-size of, say, 14px on screen, then set it as that and you'll have less worries about it changing unexpectedly if the font of its parent changes. I save em measurements for things that are inherently associated with their parent font such as line-height and letter-spacing.
I know this is not orthodox, but I've been doing front-end dev for 12 years and I promise this practice has saved me from a lot of hassles.
If you are designing for the screen, pixels are your medium and you should be aware of them.
Pixels are an aspect of your medium. Not all pixels are created equal: they're not the same size, brightness, or color. Screens have hugely varying numbers of pixels, and can be resized pretty much at whim. Used to be you could rely on having at least 80 columns of text visible, with handheld devices, that's rarely a safe bet (reading the comp.risks digest, with its fixed-format presentation became all but impossible). I'd argue that ems and percents should be your principle units.
Where I use px it's for image padding (though I'm switching to ems for that), and border widths (though again, ems might actually make more sense, I'm just used to specifying 1-8px borders ...).
My point is that, for content, that is, text, your measurement should principally be about text. Your ems font sizing point has merits (well, except for your use of 14px for your font size), but you've got plenty of alternatives: smaller, medium, larger. Or absolute sizes: (though I'd suggest avoiding these): xx-small, x-small, small, medium, large, x-large, xxlarge. And realizing that '0.5em' is really saying "scale this to about 50% of normal text with" pretty much obviates your complaint that the typical character isn't 1em in width. Or, if you want a fixed relationship, percentages. I usually set my header tags at 150, 140, 130, 120, 115, 110, though I may bump that up (200% or 300% for major heads) or down (5% or smaller steps). And I'll often set these differently for header, article, aside, and footer elements (larger, normal, smaller, and smaller, typically).
Example of using ems for height and spacing is the drop caps on both my subreddit and Dreamwidth styles.
My focus on single-column layouts for text content (note that I actually like the multi-column mode for navigation and promotional elements -- when in sufficiently wide-screen displays) means that pixel-perfect placement is rarely an issue. I've also taken to styling navigation lists as "display: inline" or "display: inline-block" elements, several instances on the examples screenshotted at reddit, specifying inline-block gives you access to the :first-letter pseudo-element which you can see in the reddit menus on my personal subreddit http://www.reddit.com/r/dredmorbius. The inline styling means that you don't really have to worry about the width of the internal options -- they space themselves out appropriately.
And my use of margins plus padding means that you get both a fluid text box and a minimum guaranteed margin. 2em is tight but workable. This also means that you can set your default font for containers, say:
<body>
#container
<header>
<article>
<aside>
<footer>
As an example of where things go haywire with px-specific stylings, Google+ uses a really complex bit of HTML to render its post and comment scores. It includes independently placed "+", tens, ones, and rating button elements. And if you're not using precisely the font sizes Google assumes, the characters are horribly mis-aligned and clipped. I've had to fix this multiple times as G+ changed its classnames (some completely asinine CSS minifier/obfuscator they use). See here:
https://plus.google.com/104092656004159577193/posts/b4azoTVU...
I save em measurements for things that are inherently associated with their parent font such as line-height and letter-spacing.
Good practice there.
I swear to fucking god I'll shoot the next HTML monkey I lay my hands on who uses px for line heights, or fucks with letter spacing. It may just be with a squirt gun, but I'll shoot 'em.
The other factor to consider is that you also have access to the @media selectors which can key off of display size. I make use of this on my Dreamwidth blog, http://dredmorbius.dreamwidth.org/ The Kosmic Kat logo is a background image of the #header block which actually includes all of the top-of-page elements, not just the title segement. Given LiveJournal's HTML template, in order to accommodate both wide and narrow screen placements, I had to find a transition point at which the logo moves above the title text, and the right margin for the blog and post titles is removed. It's not a totally elegant solution, but it works sufficiently for me: I get my little branding element, and the text doesn't get horribly mangled.
Similarly, we get people telling us that we absolutely must use serif fonts, and others telling us that serifs make text harder to read and must be avoided.
Since our startup is focused on enhancing readability, we take these concerns and comments to heart, but we have realized that much of readability is more subjective and less guided by universal, hard-and-fast rules. So now we offer multiple text sizes and are going to incorporate multiple fonts.
...But then you get into the problem of offering too many choices instead of telling the user what is right (the paradox of choice). Sigh.
A big challenge with typography, and design more generally, is that sometimes what is objectively superior in some measurable sense (retention, reading speed, etc.) can contradict what a test subject prefers subjectively. I agree with your caution about providing too many options at the expense of simplicity, but when you’re asking a question that doesn’t have a single universally correct answer, I don’t see that you have any better strategy available. Interesting idea for the reading aid, BTW.
Interestingly, among the minority of subjects (15%) who perceive that our tech did not improve readability, most of them actually read faster in the test condition than in the control.
At the end of the day, both subjective and objective results matter. People don't willingly use a product that they don't like, and most people aren't interested in a product that is only playing games with their mind. So we have to build products and features that help people, and then provide education so that people feel can make fully informed decisions.
The number of characters per line is, however, important. I tend to either resize my browser to narrow sites like HN or use the 'Instapaper Text' button to totally transform the page.
One things missing in this article is talk about line-height. The longer the line of text and the longer the paragraph, the more line-height you need. The white gap between the two lines helps the eye to find the next line as it quickly scans back to the start.
Many news sites still use a small line-height reminiscent of newspapers where whitespace is expensive. I think the designers think it gives the feel of 'real' news.
TL;DR: lines around 70 - 80 characters are good. But more important is sufficient line-height to scan back to the start of the next line instantly.
I still use 80 columns as the limit on all the text documents I write, including source code. Occasionally I'll push it up to 128 but most of the time even I personally prefer 80 as an ideal width.
Also, who maximises a browser, unless their monitor is tiny? Especially with resolutions where they are today. I have around a dozen other apps open at the moment and none of them are maximised.
Unless the page doesn't have a max-width of course, which usually forces me to resize the window; for HN I created a restyling Greasemonkey script though.
Someone who doesn't have state-of-the-art resolutions. My 3 screens top out at 1280 px wide, so any browser window is maximized by default.
When I do have the luxury of working on only one thing and focusing on that, it's great. Much of my work (technical, research, or otherwise) involves flipping between different applications or windows. Usually a terminal (or several), and one or more Web pages open for reference.
One of my peeves with web pages in general is I choose a default font face, size and weight based on my monitor or laptop screen and the distance from which I view. The first thing usability experts do is override that with a custom font face at fixed point sizes. I don't get bored looking at the apps on the desktop using my preferences, why is it different on the web?
That said, I do think it is tougher to scan his site for relevant headings/navigation/etc. that I want to interact with. The text is just so huge and there's nothing else and even just quick checking the headings you have to scroll a lot. Smaller text would allow more glance-ability.
Side note: as monitors increase in size, I'm curious of the general population is increasing the distance between their eyes and the screen
i don't think i have a particular bias about this - i usually use tiny fonts and want my screen filled with text for coding purposes - although i do tend to stick to 80 chars or less per line for code as well but i think that because code isn't read quickly i've just never noticed this before...
I like larger text, but I find this too big (when I read it on a computer). And I think for valid reasons beyond just personal preference. For starters, it's hard to scan or keep track of where you are in the post. I don't think Nielsen would hold this up as a great example of scanability - on my 11" Air I get just about two paragraphs on screen at the same time.
It's own site doesn't use the whole screen. So pot...meet kettle.
Though, in general I agree with the font size needing to be larger. I'm curious if it is as important as portrayed. Probably depends on the type of reading being done. And, as always, effective use of graphics trumps most "text size" decisions, I would think. (As I look over a comic with ridiculously small type.)
If you put people into usability lab and test their reading speed and reading understanding with different text sizes etc. you get more objective results (that mostly agree with the OP as far as I can remember).
It's much less wrong than preference-based theorizing. If you switch to longer lines and viewer time on page increases...
> If you put people into usability lab and test their reading speed and reading understanding with different text sizes etc. you get more objective results (that mostly agree with the OP as far as I can remember).
In very different contexts than blogs or web pages, I'd guess, if your memory is not misleading you.
How physical text layout affects reading from screen.
http://images3.wikia.nocookie.net/__cb20060729105544/psychol...
If you haven't already, I highly recommend that you read Josef Mueller-Brockmann's Grid Systems in Graphic Design/Raster Systeme fuer die Visuele Gestaltung; the content is really right up your alley. Mueller-Brockmann gives the "rules" of typography, then gives examples of what happens when one deviates from those rules.
You'll also see from his book that the main problem with web design today is the lack of use of columnar text layouts. Blowing the text size up on web pages is just a hack to fill space; if more responsive layouts used multiple columns, that kind of trickery would be unnecessary. (Edit for clarity: I'm talking about multiple columns for a single body of text, much like you'd see in a newspaper or magazine.)
As you might expect, people who can read better can generally read longer lines, limited mainly by the number of words apprehended in a single "fix" or by the reader's visual acuity.
The article I link to references research on both physical line length and characters per line, but the methodology described in the article itself attempts to fix physical size of a character and distance of the eye from the screen.
Just a few letters per line
A novel concept
I agree that there's an optimal number of characters per line, but it doesn't necessarily mean you need huge fonts. just make your content more narrow, or use a multi-column layout.
The larger font amplified the "wall of text" feeling.
The 100% Easy-2-Read Standard http://ia.net/blog/100e2r/
Not OP's fault, but just a heads up.
Make them slightly smaller so they fit in one line, and can be read in one fell swoop.