Optimal Characters Per Line(mikeyanderson.com)
mikeyanderson.com
Optimal Characters Per Line
http://mikeyanderson.com/optimal_characters_per_line
45 comments
I wholeheartedly agree with your point, but why do you use Facebook comments, displayed in a whooping 11px ?
I wish that I could change do Disqus without losing all of my old comments. I had originally decided on Facebook I believe before this design of the site and now I'm stuck with it—if any one has a hack to change the type I'd love some advice. I can't seem to override the FB CSS.
Nice post. Something similar that was posted on here a while back is the "Interactive Guide to Blog Typography": http://www.kaikkonendesign.fi/typography/
Seems silly to say it should mimic a book, without acknowledging that many different type sizes exist in books.
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.)
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.)
Ironically I found that page hard to read. I think it might the constantly having to switch my eyes back at the end of a line breaks the mental flow of the sentances. Anyone else experience similar?
Yes, it's hard to read.
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.
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 had the opposite experience, although I would have preferred it just a teeny bit smaller. Coming back to read long lines on HN is quite awkward.
There's a reason I limit my source lines to 78 columns too. Well, many reasons if you consider 80x25. :-)
There's a reason I limit my source lines to 78 columns too. Well, many reasons if you consider 80x25. :-)
FYI, you can get a plug-in such as Stylish for a lot of browsers that will let you override styles for specific sites. For lightly formatted discussion sites that I visit often, I typically set a font and a (max-)width for comments and related material that I find comfortable.
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.
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.
Yeah, I stopped reading it due to the huge font being too hard to read.
I hope that this article has at least caused you to think about the way your web page displays text.
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.
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.
Large fonts stress my eyes more than smaller ones. I fit less words in the center of my vision with a large font, which means I read slower and my eyes have to travel longer.
Having ~60 character columns is the important thing. Large fonts, not so much.
Having ~60 character columns is the important thing. Large fonts, not so much.
One of the difficulties of a screen is that you can't control how far away the reader is from the screen. With a book and mobile device the user can easily adjust distance to match their preference—on a screen you can make the type responsive to screen size, but if someone is closer to the screen or further away there isn't much that I know of that can help get this dialed.
There's always responsive typography using the webcam :) https://hacks.mozilla.org/2013/02/responsive-web-typography-...
With Xbox One having an always on camera facing you this might actually be possible, although I think that the right size probably depends on your eyes and vary depending on how far or near sighted you are—that's just a guess.
Isn't this why browsers have text zoom? On Firefox if I want to make text larger I can simply do cmd + or ctrl +. Assuming the site is coded well, the text will flow accordingly.
I can recommend the "NoSquint" Firefox add-on that remembers your
preferred text size for each site:
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".
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".
> ...on this blog their are about 75 characters...
Sorry to be that guy. I only point out grammar flubs if they are on 20px font or greater.
Sorry to be that guy. I only point out grammar flubs if they are on 20px font or greater.
For the record, I zoomed out on this website for a more comfortable read. Not really the way to drive your point home I think.
I don't know. I found the article very hard to read.
Very, very hard to read due to way too large font. I immediately had to zoom out in order to read it.
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.
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.
It probably varies from person to person. I read all the blog from start to finish, although usually I don't read long texts, or read the start, then somewhere in the middle and maybe see what's in the end. So for the inpatient type like me it seems to work.
Curious; what type of display were you reading on? How big is
it? What was its resolution?
--------------------
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.
--------------------
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.
> 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.
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.
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.
Yes, this is why it drives me crazy that Safari on iOS does not wrap text as you zoom in. Every browser since the beginning of time has been able to properly wrap the text as you increase the text size, and Apple has totally broken that.
That was one of my biggest complaints about iOS coming from Android. Reading Hacker News comments on iOS is a horrible experience of swiping back and forth, back and forth.
What's worse is that the other browsers decided to emulate this bad behavior. Most of the mobile browsers now no longer properly wrap text when zooming, where once they did.
I guess you could say that HTML meets that standard. For example, <h1> through <h6> headers could be rendered by the browser accordingly; most default renderers still display things mostly the same way Netscape Navigator 2.0 did back in the Win 3.1 days (disable CSS on a site and you'll see).
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.
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.
I also have a 27" 2560x1440 display, and I found this really difficult to read. The fonts are far, far too large and I kept feeling a bit overwhelmed at any distance. It was an actual effort of will to continue reading it until I lowered the page size to 75%. Viewed from around 2'1" distance as well.
> Curious; what type of display were you reading on? How big is it? What was its resolution?
> Reading it on a 27" 2560x1440 display was really nice.
Same reaction as OP, same monitor dimensions (both resolution and physical size) as you. Head to screen distance is probably around 2 feet?
Same reaction as OP, same monitor dimensions (both resolution and physical size) as you. Head to screen distance is probably around 2 feet?
Bingo @ 2ft.
17" 1280x1024, viewing distance about 50 cm. When I'm reading a book, the text size is much smaller than on this page. Mostly like HN pages really.
The font size on HN is about the same as in a book when the book is held right up against my screen (my screen is almost exactly arm's length). When I hold a book up to my face, at my normal reading distance, the text size is much bigger than HN's and - roughly - the same as the OP.
Do you read childrens' books? :) Well, you are correct, but again it depends on the size of the font on the book, right? Normal book or magazine text seems to be slightly larger than HN test on screen when viewed on "normal" reading distance.
Well, of course, but the book I was referring to was a UK Penguin fiction paperback - pretty much as 'standard' as it gets, although I don't know about international variations.
I'm on a 13" MBP (1280x720) and I found his font size to be perfect. It was actually refreshing, since I'm used to tiny fonts. It felt like using a mechanical keyboard after years of chiclets.
For better readability, try 75 characters per sentence.
The larger font amplified the "wall of text" feeling.
The larger font amplified the "wall of text" feeling.
I can't read this while doing something else - I have to select the window and scroll every few words.
That's part of the point. If you don't get readers interacting quickly it's very hard to keep them reading.
Sorry what? Are you more interested in "keeping them reading" or actually making accessible web sites that are easy to read? What exactly does interaction have to do with it? When I'm reading a book, I really don't want to turn pages constantly.
I think the author has a point .. however we're all conditioned now to the standard-ish font size on the web. We all sit at a distance from the screen optimised for a particular size - and as most sites are about the same we zoom in or our a little. Changing that is just jarring.
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.
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.
Agree on the importance of line height—here's a calculator to help give a balanced line height—I'll add to the post. http://www.pearsonified.com/typography/
Maybe the author kept under the character limit
that he proposed, but due to large font I still had trouble
reading. Not only was it hard to find the next
line after finishing the previous one, but it
was also hard reading each word. I only want to
glance at a word to know what it is - which is why
those "the the" tricks work.
Limiting the text
Just a few letters per line
A novel concept
Just a few letters per line
A novel concept
So there were some great points in there, all of which were valid. But immediately addressing those points doesn't mean using large type follows.
Side note: as monitors increase in size, I'm curious of the general population is increasing the distance between their eyes and the screen
Side note: as monitors increase in size, I'm curious of the general population is increasing the distance between their eyes and the screen
Ironically when I read this on my iPhone the text size was much smaller than an average novel. (Also, the line-heights need some TLC).
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.
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.
Has OP A/B tested his claims and theories in any way, or is it just a tissue of personal preferences backed by rationalizations and just-so stories?
A/B testing is not the correct way to test what is objectively better. As we can read from here, people often have personal preferences to what they are used to and think are best. Unfortunately what people think is best is not necessarily same as what is objectively best for them.
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).
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).
> A/B testing is not the correct way to test what is objectively better.
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.
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.
Here is good overview of the research:
How physical text layout affects reading from screen.
http://images3.wikia.nocookie.net/__cb20060729105544/psychol...
How physical text layout affects reading from screen.
http://images3.wikia.nocookie.net/__cb20060729105544/psychol...
Hi; I love your writing! I can't speak for the OP (though I doubt they A/B tested), but most typographic conventions come from the days of typesetting and the subsequent studies of typographers and graphic designers in the 20th century.
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.)
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.)
I can't speak for the OP, but there have been studies of appropriate line lengths for reading text on computer displays. See for example https://web.archive.org/web/20020725135307/http://psychology... (found via WardsWiki: http://c2.com/cgi/wiki?TenWordLine).
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.
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.
This is about the font size I read most stuff on the web at, so I guess I agree. The font on most sites is too small for me, so I browser-zoom them in 1-3 stops.
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.
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.
The problem I've got with browser zoom is that it behaves wildly inconsistently across sites. In some cases, it will expand all containers along with the font size, frequently pushing page elements off the viewscreen. It almost always scales images, which I generally don't want. In some cases, narrow-format pages end up with ridiculously skinny columns of text floating in a sea of either whitespace or distractions. And in far too many cases, pixel-perfect styling elements break completely, leading to wrapped navigation bars, buttons with clipped text, or just plain broken page layouts.
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.
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 hate reading on any screen but my black and white kindle.
first thing I did to make it readable was hitting "ctrl -" three times. so the site kind of defeats itself in that respect.
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.
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.
I nearly lost it at "inforamavores"
In my experience, it's difficult — if not impossible — to please all of the people all of the time. My startup (www.BeeLineReader.com) has browser plugins that reformat text and display it using eye-guiding color gradients. We get comments from people telling us that the plugin's text is too big, and we get comments telling us the that the text is too small. I suppose we should be happy that the ratio of these comments is roughly 1:1 — maybe this means we've struck the right balance?
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.
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.
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.
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.
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.
Absolutely agree that users' subjective perceptions about readability don't always line up with actual results. We have a reading test on our website (controlled and randomized, n = 15,000), and the vast majority of test subjects find that it improves reading ease.
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.
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.
If anyone is confused like I was when I opened this, there's a media query that reduces the font size when your window is less than 900px wide. Full screen it and the article will have huge text.
We can't really debate the issue given that some of us are seeing a huge font (much larger than the 'magazine held up to the screen'), and some a more reasonable one, all depending on the width of our browser window. Apparently it flips between the two sizes around 900px width.
I don't think that's what the author intended. Back to the drawing board I reckon...
I don't think that's what the author intended. Back to the drawing board I reckon...
It's switching to mobile formatting. The text is smaller, but the phone is also closer to your face. I thought it was cool how you could switch layouts on the fly like that.
I actually found this really hard to read because of how large the text is, the author needs to reevaluate his font size.
Shorter lines are easier to read. Long lines with large characters like in the OP's post are harder.
As others have pointed out here, the article above is much too large on an Apple 27" Cinema Display.
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?
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?
I like the linked site, personally. I've always liked big huge readable text and will zoom or text zoom a site to make it so.
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.
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.
I'm reminded of the 'Osprey - The Magic of Reading' paper by the late (great) Bill Hill
Information Architects has a much more thorough article on this matter:
http://ia.net/blog/100e2r/
http://ia.net/blog/100e2r/
When I'm reading a book, I've already decided that I'm going to read every word. On your website (on any website), I'm going to skim first to evaluate how much fluff and filler is written and to hopefully get to the point. With such large font, there is so little content in front of me that I'm actually frustrated with the encumbrance. If I didn't know better, I'd feel insulted that you deemed it necessary to try to control my browsing experience so strictly.
I find it interesting that both the blog entry and the picture of the physical book he's using are not justified but simply jagged right.
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.
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.
I think your qualification "as long as hyphenation is done right" is the key here. I don't know of a single web browser that lets the user turn hyphenation on and off, and while CSS3 supports hyphenation, browser support is inconsistent. (Chrome is the most notable problem child here, oddly enough.)
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.
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.
It is really odd to me that Chrome is behind for hyphenation. It is such a crucial thing for typography.
Ragged right may be rare, but that doesn't make it less optimal. Many argue the Betamax was superior to VHS, but Sony lost that battle.
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.
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’m sick and tired of cramped websites that have tiny type and don’t use the whole screen well"
It's own site doesn't use the whole screen. So pot...meet kettle.
It's own site doesn't use the whole screen. So pot...meet kettle.
Nice, but here's an improvement: lose the 2-line section titles.
Make them slightly smaller so they fit in one line, and can be read in one fell swoop.
Make them slightly smaller so they fit in one line, and can be read in one fell swoop.
That is the one thing that jumped out at me. Otherwise I agree with everything.
Maybe this is why, even on an 11 inch netbook, I generally surf the web with the browser window at about 3/5ths the overall screen width. I don't like columns that get too wide.
On each full paragraph line of text on this blog there are about 75 characters—which is widely regarded as the most characters that you can put on a line and still have it optimal for readers.
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.
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.
I actually do maximize the browser quite often when just browsing, i.e. not using the web while working on other things. My main screen is a 27" at 2560x1440, and I like how a maximized window allows for less distractions and more horizontal tab space.
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.
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.
I always maximize my browser windows. There are a handful of applications that's true of, browsers, video players, IDEs, and games for the most part always get the fullscreen treatment. Chat clients, terminals, certain kinds of editors, etc. I usually tile. Of course my screen is only 1920x1080 so results may vary (I miss my 1920x1200 monitor, but they're so hard to find at a reasonable price now).
I maximize them. I'd rather use a tiling VM with a bunch of virtual workspaces than having to deal with resizing and minimizing windows.
It really depends on my workflow.
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.
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.
Yes, so does mine, that's why I use multiple virtual workspaces, with one or two windows per workspace. I have 18 open windows at this moment, with 16 of them maximized.
8 workspaces, 20 windows (a low count), none presently maximized (though 4 are near-full-screen).
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.
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.
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.
Mine are 1280x1024 too, and I've never had to maximise windows much - the browser window I'm posting this comment from happens to be 900x600.
Point #4 is basic journalism. Headline, nut graf + inverted pyramid.
I'm all about readable fonts, though mikeyanderson is going a bit overboard in the too big direction.
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...
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...
I agree with 95% of what you said, the main exception is using em for styles. If you are designing for the screen, pixels are your medium and you should be aware of them. If you are using any graphics elements you will need to use px anyhow and then you are mixing - which I agree is bad. Ems can have unexpected consequences as well. For one, because it is a measure relative to the size of the capital M, sizes can change when the parent font-family changes (moving from a proportional to monospace font, for example.) Also, it is relative (like %) so if you wrote a CSS rule like this (you shouldn't, but it is to illustrate an point)
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.
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.
To be clear: about 80% of what I know about CSS I've learned in the past 9 months or so, despite having dabbled in HTML since the late 1990s -- I've long hand-tooled my own HTML for my personal websites and many discussions which allowed HTML markup. And I'm coming at this almost completely from the user experience perspective. To be more specific, my user experience. I respect your experience, but the practices I've seen in live code are ... simply infuriating.
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:
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.
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.
You might like Clearly? I've found it pretty useful, especially for Wikipedia articles with big, complex tables.
https://chrome.google.com/webstore/detail/clearly/iooicodkii...
https://chrome.google.com/webstore/detail/clearly/iooicodkii...
That's pretty much what Readability does.
Swapping your video: http://fixyt.com/watch?v=1FmwefTTnbo
Unmentioned feature: export page as ePub for use on any electronic book reader.
Swapping your video: http://fixyt.com/watch?v=1FmwefTTnbo
Unmentioned feature: export page as ePub for use on any electronic book reader.
I used to use Readability to deal with problematic web sites, but I switched to Clearly after encountering a number of web sites that Readability had problems with (not rendering all the content). I didn't know about Readability's feature of exporting a page as ePub. I may have to give readability another try.
Yeah, Readability doesn't get them all.
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.
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.
Followup just to note: UI/UX considerations (which I'm addressing) may not translate into conversions or other performance metrics of the site. But ... well, that's not really my problem. And if your site is sufficiently poorly designed, I'll be going elsewhere anyway.
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.
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.
I love how this carefully designed site is sensible with its readibility and then you get the Facebook-powered comments with letters smaller than ants.
Not OP's fault, but just a heads up.
Not OP's fault, but just a heads up.
did anyone else quickly notice how many eye movements they were making on this page and how irritating it was? i've never before noticed this to be a problem... its surprisingly distracting, and i felt like it was slowing me down which became frustrating quite quickly.
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 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...
You can never really know how the end result is going to appear to your users/readers because everyone has different types of monitors, resolutions, layouts. For example, I have 4 monitors at work that have all been rotated 90 degrees from the "norm" - in other words they're all in portrait mode. My browser window dimensions are thus longer than it is wide - which I think is not what most web developers expect. Furthermore, I really do enjoy small fonts and much prefer to see as much of a site on 1 page as possible. I had to zoom out of that page just to be able to read it comfortably without scrolling too much.
Nm
The 100% Easy-2-Read Standard http://ia.net/blog/100e2r/