Hacker News new | ask | show | jobs
by xjay 3798 days ago
I don't have a comment on the work itself, but like most sites, it has no awareness of line length, and it's therefore painful to parse the information without resizing the window.

Both HN, and the linked website, could benefit greatly in readability by simply limiting line-length to ~32em for textual information. It's strange that a browser, designed for human use, has no notion of humans in that regard.

3 comments

Hi, xjay. Thank you for bringing that to my attention. I'll experiment with it later on today. If you don't mind me asking, do you have a reference site I can look at that you think really shines in terms of readability?
Sure! Matthew Butterick opened my eyes on the world of typography. He has a site with tips: http://practicaltypography.com/

He also has a very good talk called "Typography for Docs": https://www.youtube.com/watch?v=8J6HuvosP0s

Those are perfect, thanks! After I'm doing fiddling with things later, do you mind if I solicit your feedback?
I'd say that resizing windows to make text readable should be normal and using maximized windows on todays large displays makes little sense, but... I was looking at that site myself on a maximized window :-) Why? Because I had other tabs open with developer tools and I needed all the space. So yes, sites should set line length and line spacing appropriately. When we see lot of white space around a column of text we should know that our window is too large. By the way, there are CSS multi column properties to fix that

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Columns...

https://www.w3.org/TR/css3-multicol/

It's supported by all browsers. Funnily IE leads the way here, the other browsers require vendor prefixes.

http://caniuse.com/multicolumn

To turn it around; maybe browsers don't utilize space very well?

Imagine if we could divide a tab into regions of sites instead?

Having a maximum line length is the humane thing to do, unless the person has phobias of empty spaces, of course. :>

The links you provided are not for the user, but for the designer. Text, however, is a global means of communication, so it should get better treatment, and care in general. Especially by browsers.

Hey, xjay. If you do a hard reload in your browser, you should see that the encyclopedic data is now bound to a 32em width (with a smaller font size). Does that look a bit better to you?
The idea is to have a maximum line length that makes sense to human beings, and that's what the site does now. It is very pleasant to read the text.

Thanks for considering the feedback.

PS: The typographical rule I based 32em on comes from the general rule that, there should at least be room for two alphabets (a-z) on one line. I found 32em to be a sweet spot. The em unit scales in proportion to whatever pixel size you choose for the font, or whatever font size I tell my browser to enforce, so it's highly consistent.

PPS: Another bonus for having a sensible maximum line length, is something I'd never thought about unless it happened to me. It's the nuisance called eye floaters. It's basically an obstruction that floats around in your vision. So whenever the eye moves, the obstruction will dash across your field of view to follow, before coming to rest again. The less the eye has to move in general, the better.

PPPS: For HN (and wikipedia) I eventually ended up making a CSS rule that would override the width of various sections, to comply with the human inside. It's just that there is no line-length attribute, so it must be hacked together specifically for each trouble site.

Thanks for the info, and again, I really do appreciate the feedback! I don't want people to have to make up their own rules for things simply because the defaults aren't sensible. For this particular project, certain UI considerations were deferred until later. I never expected this post to garner more than a handful of views, so needless to say, it was an abrupt call to action to start fixing those things once it broke 10,000+ views.