a) looks like a reasonable simulation of Tufte's print style
b) is missing the point Tufte tries to make
Tufte isn't saying you have to make your presentation look like his, his basic thesis is "don't add unnecessary things that take away from the clarity of your presentation" and he's made a name by critically analyzing other people's presentation and work to show where they've gone overboard and why that detracts from the message they're trying to show.
I've sat in his class, read his books and website and followed him for years. His approach and critical analysis of web sites is actually fairly different from print. He understands that the web is a different medium and should be approached differently. His critiques of ESPN and various weather websites are fascinating not because he complains they aren't using enough whitespace or don't follow his print style, but because he actually likes how they clearly and concisely present summaries of dense, compact information.
I'm afraid this comes off a little like cargo-culting Tufte, going through the ceremony without actually grokking his meaning.
While I do think Tufte CSS could be a good starting point for a variety of webpages that want to communicate a point using text, tabular data, figures, and code, I don't think that websites should see Tufte CSS, or Tufte's print projects in general, as a design goal. Different projects, in whatever media, should present their information as best suits their particular circumstances.
Anyway, I apologize for giving the impression of cargo-culting. If there's any way I can change the wording in either the README or the demo doc to better reflect that this is not a design prescription, please let me know.
The reason san-serifs were better on screen is that screens used to have lower DPI's, and thus can't actually show the serifs as well as on paper.
In the old days of CRT's and 72 dpi screens, the serifs would be distorted because the display can't show details fine enough. In those cases, san-serifs get you around the problem of low dpi screens.
Nowadays, with retina and high dpi displays, serif fonts can look as good as in print.
Just be aware of why these guidelines exist. It's not always a firm "it has to be this way" hard rules.
On the linked page the resulting size of the letters on the page is simply too small to allow easy reading. When the area to display text is so small, the designer shouldn't insist on the white margins or the comments on the side. On web page, the comments could be much better done in the "Wikipedia" style (showing on click). The design of the Wikipedia articles on the moment is actually good on iPhone. Much better than this, very natural to read.
Would be better with less leading, a smaller text size, smaller left margin, and more characters per line. This current version has a text block more like a newspaper column width than a book, and the large type and unnecessarily generous leading (especially in block quotations!) make it feel a bit like a children’s book. Not much content fits on screen at any time.
Small caps shouldn’t be used with a typeface/browsers that don’t properly support them and just shrink capital letters instead, they just look spindly and bad. Either find a real small caps font, or skip the idea. Likewise for italics: use a real italic font instead of a browser-generated oblique version of the roman font.
If you want it to look like a nicely typeset book, use an indented first line for new paragraphs rather than a blank line.
Lots of other parts need tweaks, but it would take making several sample documents and then judging how the parts interact.
Final note: Tufte’s books don’t look good because of the basic style choices, but because of the incredible care and attention he puts into writing and composing them. Crappy content is not going to suddenly become amazing when a different stylesheet is slapped onto it, and any document that aspires to be as pretty as a Tufte book is going to take many hours of manual composition.
Totally agree. At least with italics, you can use CSS to instruct the browser to not create fake italics using the font-synthesis property: https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthe....
Also, setting the document font size to 11px is a bad idea for a whole lot of accessibility reasons. The current best practice is to leave the global font size at 100%, which in most browsers is 16px by default.
This allows users to scale the type up (or down) as needed, unlike various versions of IE which won’t allow this if the base font-size is set in pixels. This allows the media queries to work correctly, since they always assume 1em = 16px. Resizing the fonts should be done in rems, with pixels as a fallback for non-supporting browsers.
“Critics who treat 'adult' as a term of approval, instead of as a merely descriptive term, cannot be adult themselves. To be concerned about being grown up, to admire the grown up because it is grown up, to blush at the suspicion of being childish; these things are the marks of childhood and adolescence. And in childhood and adolescence they are, in moderation, healthy symptoms. Young things ought to want to grow. But to carry on into middle life or even into early manhood this concern about being adult is a mark of really arrested development. When I was ten, I read fairy tales in secret and would have been ashamed if I had been found doing so. Now that I am fifty I read them openly. When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up.” - C.S. Lewis
This is especially relevant when we’re talking about Edward Tufte: Tufte devotes a huge portion of his books to emphasizing that information presentation is improved when more information is presented in a smaller space, to facilitate references and comparisons between different items/sections. “Information wants to be spatially adjacent so as facilitate comparisons made within the common eyespan of the viewer.”
As a concrete comparison, here’s what fits in my browser view in this “Tufte CSS” document:
Here’s what fits on a page in an Edward Tufte book:
Designers have, for a long time, thought that 'small text is cool/looks better' but there has been a pushback on this by web designers over the past few years. Maybe even HN will one day update its styles for readability; at least a shorter line-length/larger leading would be a great start.
The 55-75 CPL seems to stem from research done on readability on paper. 95 CPL seems more apt for the desktop browser when it comes to reading speed. When it comes to overall satisfaction the result is interesting. http://psychology.wichita.edu/surl/usabilitynews/72/LineLeng...
I'll try to look into your points about leading, text size, and so on, but it would help a lot more if you could open a GH issue for them. As I've noted elsewhere in this thread, a real italic font has been added, and I'm considering what to do about small caps. To me it doesn't look so bad as-is.
I don't want Tufte CSS to look like a nicely typeset book, and it would take a lot to convince me to indent the first line of new paragraphs. I find that repulsive on the web.
Your last paragraph is gold. I wrote something similar about the table style earlier today. For me, I think this project is an exercise in making style choices using a rough template as a guiding star. I too worry that others will focus more on the finger than that star it is pointing at, by slapping this on top of existing content and calling it a day.
Butterick's implementation is more than a CSS guide though, right? I thought his design was to show off the power of Pollen, his online-book-publishing system.
There's a lot of stuff you'd want to clean up before you let Mr Tufte see it.
Do you have an example of a site and/or browser that exhibits the behavior you're describing? I'm quite curious if there's an approach to structuring a page that preserves position sensibly.
I'd really appreciate if you could add a GitHub issue or two for the problems you list in your other comment https://news.ycombinator.com/item?id=10012953
It's also available to try out online on Overleaf if you don't fancy installing LaTeX: https://www.overleaf.com/latex/templates/handout-design-insp...
(Note: I'm one of the co-founders of Overleaf, so any feedback appreciated, thanks!)
As an interesting tidbit re Overleaf, we recently passed the 3 billion pages compiled mark :) If you stacked up all those pages, you'd have a pile that's (roughly!) the height of Pluto: https://www.overleaf.com/blog/219-youve-created-three-millio...
If the user then increases the font size, the web page obliges, expanding beyond the window boundary, yet doesn't provide a horizontal scroller! Very bad.
The thing is: Tufte's style isn't designed for webpages. It's designed for books. Books have defined margins, a fixed size, and pages with a defined length. (Good) web pages don't necessarily have any of that. This is where sidenotes fall down, for example: the CSS author has to jump through a variety of hoops, breaking various conventions, in order to make them usable when the user narrows his window width.
Everyone criticizing the implementation, here, let me help you:
Medium's site is already on the upper end of what I consider to be a usable font size (22px), and this is even larger (24px). At some point, larger type makes it difficult to quickly scan the page.
For comparison, even Tufte's own site is rendered with a 16px font.
It will take some work, but with proper collapsing rules for narrow screens, this would be very nice.
One problem might be (as others have indicated) that what works in print doesn't have to be the best solution for digital -- especially where the page size/width (window size) can vary substantially. Personally I typically give my web browser 2/3 of the screen on my laptop, half on my desktop -- unless I'm using it for reference in which case my "work window(s)" -- terminal and/or editor get the 2/3 width slot.
This layout would therefore be useless in code documentation for my use-case -- the window would be ~50% padding, with an anemic main-column that'd be almost unreadable due to fitting only a single word per line.
[ed: At the very least tufte.css and/or latex.css should enable/use CSS3 hyphens in order to get word hyphenation that is a little more like LaTeX, and not completely broken! As is the ragged right is painful in narrow viewports.]
It's great for many other purposes, but a lot of people will probably prefer doing things in Markdown.
There is some CSS to put the asides on the side (with a ton of variations to make it play nice on mobile). Then there's a bit of JS to correctly line them up with <span> markers. It was a bit more effort than I expected, and I don't like having to rely on JS, but the output is really nice, I think.
For example, take a look at this chapter, and try resizing your browser window or hitting it on a mobile device.
(Aside: I really love using the Mobile Design View in Firefox and Chrome for inspecting responsive behavior. You can drag the viewport size by hand, or switch it to presets that represent target devices easily. All while keeping the full width of the browser pane for developer/inspector UI. FF even has a nice toggle shortcut, ⌥⌘M on OS X.)
Yup. This is a nice (deliberate) side effect of using separate <aside> blocks instead of jamming them in the middle of the paragraph. The original location of the <aside> tag determines where the sidebar appears in the text flow if there's no room for it on the side. In some cases, it may be a few paragraphs distant from where it shows up on the side if that leads to better reading.
This is also the fallback for users who don't have JS enabled. (Well, all both of them, at this point.)
> I really love using the Mobile Design View in Firefox and Chrome for inspecting responsive behavior.
Oh, yeah. I basically lived in that for a few days when I was tweaking the CSS.
What help. /s
Not responsive, but @media queries on width and re-scaling width, margin, background colour, and border colour is what gets you that.
Motherfucking Website. No sidenotes. but other bones of my basic design.
Daniel Bos's sidenote implementation:
(Degrades nicely for non-CSS viewers, not responsive.)
Searching "css sidenote edward morbius" on G+ might turn up something and basic CSS.
This handout, by contrast, doesn't do this, and so it throws away something that, to me, is central to Tufte's appeal.
It looks like sidenotes are floated right and given negative right margin. (https://github.com/daveliepmann/tufte-css/blob/master/tufte....)
There really ought to be a native HTML reference / footnote / sidenote entity with appropriate default styling.
My take, responsive:
(Using floats and negative margins.)
It actually is quite good semantically.
See also Readability's publisher's guidelines:
And the hNews microformat:
I understand this type of thread doesn't really fit HN's "no gratuitous negativity" guideline, but IMO there's really no other way to constructively discuss typography. The whole field is made of attention to excruciatingly tiny details, but taken together, it adds up to great and beautiful design. It's one of the things I love about it.
Maybe note that none of the criticisms are entirely dismissive or unnecessarily harsh, but well-argumented, just about tiny details.
Firefox 39 on Ubuntu 15.04
Perhaps it touched a nerve because there are quite a lot being done in a relatively small space that makes it look messy.
An option would be to show some features that gel together and list the others in the git markdown page.
There's a chunk missing at the top, and it looks like crap! It should look like this:
Now I understand full well that it's very difficult to make something that looks good on every OS, browser, screen size, resolution, yadda yadda -- but in this case, that's the entire point!
Woah! wait a minute. Style of Richard Feynman? When did Feynman get involved with typography/typesetting work?
It features the main column / side column design as discussed, with notes, diagrams and navigation hints in the side column and is a great demonstration of the value of whitespace!
More on that:
Similar thing happened to the full-width image.
I'll try to submit it to the Github.
Specific designs are born of their environment
Tufte's principles are born of their medium, and both message and format change as medium does. Understanding the why and wherefore is far more important than the what of design.
Borrow but don't ape
So take the concepts and use those which are applicable. But allow yourself leeway as well. Constraints of pagesize, contrast, and other aspects make some of Tufte's suggestions less advisible for online. I find the grey-field charts translate poorly, for example.
Layout doesn't fix bad writing, but it helps most, and exposes bad
Good writing can be killed by bad layout and presentation — this is a frequent observation in HN comments on overstyled articles. Middling writing, with good, well-structured layout, becomes easier to read. Bad writing lies naked on the screen when shorn of its shielding raiment. I've found that small changes — drop-cap initials and a bold first line, help in acquiring content particularly when presented in a "cards" view. Quite the accidental discovery, but one I find very useful.
Yes, much of the beauty of Tufte's books comes from the totality of how they're architected: ideas, structure, presentation, layout, typography. But incremental steps help.
Embrace and Accept Medium Properties
Paper is fixed size. Online is dynamic. Inks are expensive, colour moreso. Pixels and rgba values are cheap, though too much flash is distracting. Images can offer zoom for detail on hover or click.
Sections. While Tufte uses only chapters and section headings, his books are also divided into Parts. As are Feynman's Lectures as I recall. In practice you'll find at least three, and frequently four, levels of hierarchy may need support: Part, Chapter, Subsection, and SubSubSection. Technical writing may have more levels of hierarchy.
Font sizes: show deference to the user's stated preference, if it exists. If not, prefer rem and em units to px or pt. Yes, MSIE back support and broken Android implementations mean you'll need workaround fixes, but you can at least build em/rem units in as your base.
Font faces. I take exception with much of the font-bigotry noted here. I honestly Just Don't Fucking Care most of the time, though I find online font choices are occasionally spectacularly poor. Generally I prefer a decent, widely available, and good enough font for online presentation. Excessive fucking with dynamic Web fonts leads to many pages which fail to render text at all on older devices.
Colour. Text should be high, though not extreme, contrast. A slightly creamy background is preferable to lighter text. For Web-specific elements, particularly hyperlinks, some affordance indicated by colour is helpful. Also joining related items (e.g., sidenotes and related text).
CSS counters. These take the manual tracking out of identifying content and references. Sections, headings, references (side / end notes), figures, tables, images, etc., can all be automatcially numbered. This is useful (though not universally supported).
Graceful degredation. A challenge with any UI/UX enhancement is that various clients don't support all features. Degrading gracefully, and providing maximum possible content and structure, really helps. (My own sidenote experiments fail somewhat in this regard.)
:hover, :active, and other interactive elements. While the design shouldn't rely on these (see above), offering additional hints by way of these mechanisms can be useful.
Contrast. Provide it. ContrastRebellion is a frequently referenced site.
Accomodate Variable Viewports
Responsive design is pretty much a necessity these days, and it's easier than you think.
In the case of Tufte.css, some principles, such as ample whitespace, make sense in the context of print where sizes are rigidly defined. For online content, sidebars, sadly, fail to remain viable as viewport widths shrink. My solution was to transition sidenotes to what are effectively callouts, with a gradually increasing background shading to identify these, as viewport size decreases.
Or rather, in a mobile-first design, you build callouts which become marginal sidenotes as space increases.
What HTML/CSS Needs*
References. Seriously. Why are we hand-tooling fucking endnotes / sidenotes, still?
Robert Nystrom's Game Programming Patterns <aside> sidenotes are interesting, see his comments elsewhere. I'm not fully sold, but these could prove useful.
A client-manipulable comments / discussion aspect is another element that I'm finding myself increasingly wanting, something that is structured by way of data (author, date, references, subject), but whose ultimate presentation (flat, nested, collapsed, semi-threaded, etc.) is ultimately under client control.
HTML5 is an awfully good start
A grab-bag of some of my own experiments
I've been playing with many of the ideas presented here as well as others.
Motherfucking Website — this is the bones of my own preferred site layout, though it lacks the responsive elements and much of the polish (which I'm still working on):
HREF sidenotes: similar to the reference sidenotes I use, and incorporating elments: ::before and ::after content, counters, and negative-margin offsets.
Ello CSS implmentation of HREF sidenotes:
Sample site design with table formatting: this adds greenbar and a current-line indicator but otherwise borrows from Tufte's table concepts.