Tufte-Latex, mentioned in the article, is a really nice template that produces some gorgeous Latex handouts with very little effort (I've used it a couple times when I wanted something to not look like the standard Latex article class). I thought it worth linking here for those that didn't read the link: https://tufte-latex.github.io/tufte-latex/
I went to one of Mr. Tufte's workshops several months ago, and I do believe he mentioned Overleaf while discussing LaTeX. I must admit I had forgotten about it until just now, so thanks for the reminder. It looks like a fairly slick interface (and a nice solution for what I recall was a relatively painful problem i.e. installing and using LaTeX).
Thanks -- yes, I believe he's used Overleaf in his workshops for the past couple of years (starting back when we were called writeLaTeX). The Tufte handout and book templates are ones we use again and again when we're asked for examples of such layouts, and they're very popular.
In general, I'm not a fan of the font. It doesn't seem to have very good hinting, so the horizontal strokes are blurry. It's also way bolder on a Mac than on Windows.
Indeed, that's a faux italic[1] created by the browser in the absence of a real italic font. Perhaps the author forgot to include Bembo Italic[2] in the @font-face declaration (or simply decided not to pay for it)?
They are generated. The only web-font being loaded is the Roman style (upright), and the browser is mechanically skewing it to try to replicate the italic. This is really noticeable when it's done to serifed typefaces, because the italic forms are based on a different model of writing and change significantly.
Cute idea. Needs a better example document to really be judged properly (for example, this document has a far too many large and imposing headings), but in any case, some comments:
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.
I get why people want their web sites to look as good as Tufte's books, but since they can't, I wish they wouldn't try. Make things that look good in the medium you're working in; don't blindly copy the rules from other media.
Fine advice for experts, surely. Those who recognize they are blind should copy. Copying Tufte seems like a reasonable way to open their eyes and save everyone else's.
I agree that design is medium-specific, but I think the idea of "looking as good as Tufte's books" is an underspecified one. Can a webpage be a better book than a book? No. Can a webpage be a better webpage by borrowing some ideas from books, then modifying those ideas to fit its own purposes? I think yes.
I find that columns with smaller width and larger text are far more readable - any text that is the raison d'être for the page should be readable first, with worries about looking like a "children's book" becoming second concern.
“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
> I find that columns with smaller width and larger text are far more readable
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...
That article is a bit suspect, since it found the max to be more readable. I would like to see what the curve is really like...how do lengths above 95 CPL begin to get harder to read?
I don’t have anything against children’s books; I love children’s books! If the goal is to fit 2 sentences on a page with a big picture and individual letters that are easy to discriminate to help when just learning to read, then large text is a perfectly reasonable part of the design. Large widely spaced text is just not necessarily appropriate for other types of material, where fitting more text on the screen is an important design feature.
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:
http://imgur.com/iLNgoaU
This will obviously depend upon what device you're using, but hold a book up in front of you at about the distance you would typically read it (this should be MUCH closer than your screen!). Now compare the size of the text (admittedly, this is tricky because of focus, but it's just about possible) - the font size in the example is pretty much exactly the same as in a typical book, for me at least.
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.
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.
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.
I found this post useful regarding small caps. It seems as though if the typeface contains the glyphs and you're using Chrome or Safari, you can use font-feature-settings: "smcp"
I agree regarding the example document. It's been troubling, because the fact of the matter is that those headings are legitimate, it's just that there's a mismatch between the goals of the description document and the goals of the kinds of documents that Tufte CSS is best suited for. I agree strongly with your idea of making several sample documents to experiment with. See https://github.com/daveliepmann/tufte-css/issues/26
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.
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.
The font appears to scale (in a step function?) related to pixel-width of your window. Try using a narrower window. (This may or may not be related to retina resolution. I didn't read the code to find out.)
Honestly, this is really rough. The impulse is admirable, but the implementation has a lot of rough edges and ugliness. A web author looking for good typography is going to be better served reading Butterick's Practical Typography (http://practicaltypography.com/).
It doesn't have the meticulous shine of Tufte's books, but this is a straightfoward CSS guide. It's a starting point, don't you think?
Butterick's implementation is more than a CSS guide though, right? I thought his design was to show off the power of Pollen[0], his online-book-publishing system.
It's a starting point, but a starting point that directs users to fake italic, fake small-caps, mismatched mono text, inconsistent apostrophes, and ugly underlines. (Oh, and sidenotes and other margin content just disappears on a phone.) If you're going to start from a template, it at least shouldn't lead you astray in multiple ways.
It also doesn't maintain your current position in the document if the viewport changes width, which... I'm not even sure how you break that. The user agent usually does a very good job of handling scroll position.
There's a lot of stuff you'd want to clean up before you let Mr Tufte see it.
I'm not sure what browser(s) or site(s) you're referring to, but just now double checking a few sites in current FF and Chrome I don't see them maintaining scroll position at all. I realize that this agrees with my developed expecations for text heavy pages. Text reflow as the page narrows dominates the viewport position -- content getting longer effectively pushes the viewport up the page. To the user, content appears to flow "downward" as the page narrows.
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.
We've fixed the fake italics, I think I've fixed the mono text (if you're talking about sizing), I've consistentified apostrophes, and changed how underlines are handled. Sidenotes are still a thorny issue (I'd appreciate any suggestions; we're discussing it in the GitHub Issues for the project) and small-caps are still on the to-fix list.
For someone well versed in typography, his monospace font Triplicate is absolutely terrible looking to me. The t's, f's, and a's all look oddly slanted and upset the balance.
I agree that Butterick is a better resource for general web typography. I was aiming less as a prescriptive resource (which Tufte's work definitely is, and which Butterick's is a good example of for the web) but as a way to work out web analogies to some techniques Tufte used.
Could you elaborate? What struck me was the limitation to two levels of section/subsection. Perhaps I'm deluding myself, but I think I prefer my information in clearly layered abstractions, with the presentation following the contours of the abstractions.
I love the margin diagrams, and would happily use this for print based output, but I fear the mobile world would have meant Tufte would redesign his approach to suit the smaller uni-column world, and the best layout on page is very different to that on a four inch screen
Looks quite good on desktop, but even on my Note 3 -- the space used for sidebars take way too much horizontal space.
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.]
I use sidenotes very heavily in my book[1], which is written in Markdown[2]. Instead of putting the contents of the asides in the middle of a paragraph, I pull them out into separate <aside> tags. Inside the paragraph, I have a little <span> with a name to indicate which text the <aside> should be positioned to line up with.
There is some CSS to put the asides on the side[3] (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[4]. 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[5], and try resizing your browser window or hitting it on a mobile device.
I like how your asides move into paragraph flow as the page narrows. The Tufte CSS page hides the sidebar content completely as the page narrows, which eliminates access to crucial information.
(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.)
It's not ready for prime time. I thought I'd posted some sample code. I'll dig for it. That was while I was doing anonymous codepens, so they're not on my profile there.
Searching "css sidenote edward morbius" on G+ might turn up something and basic CSS.
> I like how your asides move into paragraph flow as the page narrows.
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.
I don't think Tufte ever uses top and bottom borders for tables. Also, the delimiter below the heading should not be so bold; it's usually a very thin line.
One of the things I love most about Tufte is the way his text introduces every single graphic. He tells you what he's about to show you; then he shows you. This stands in stark contrast in most books where the figures are only very loosely coupled to the text. I didn't realize how jarring I found the convention until Tufte! And it makes perfect sense in hindsight: why did we think it's okay to put figures "within a page or two" of the relevant text?
This handout, by contrast, doesn't do this, and so it throws away something that, to me, is central to Tufte's appeal.
That's a great point. I added some text to the demo document making that point, but I don't have actually relevant graphics or figures to add to it. If you have any suggestions for wording, just email me or open a GitHub issue. Cheers!
For lack of a better word, this implementation is half-assed. If the whole point is typography that's both gorgeous and legible, then you had better dot your i's and cross your t's, and this doesn't. As a very simple example, look at the capital B here in the name of the font:
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!
They're not haters. This is the type of discussion you should expect when discussing typography. It may seem like endless nit-picking, but it's the sum of nit-picking over all the tiny details that adds up to great typographical design.
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.
I don't know if RPF himself had anything much to do with it, but the typesetting of the /The Feynman Lectures on Physics/ is beautiful.
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!
It's referring to the Feynman Lectures on Physics http://www.feynmanlectures.info/, he was presumably involved in the presentation aspects of that (the books I mean, not the site).
For a typography-centric project, it pains me to see that you're not including the proper italic version of the font used in the article, forcing my browser to do ugly guesswork [1].
106 comments
[ 2.9 ms ] story [ 203 ms ] threadIt'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...
Linux/Firefox FWIW.
Work: http://paste.click/LKBLqt
Home: http://paste.click/zfhnYG
Firefox 39 on Ubuntu 15.04
[1] http://alistapart.com/article/say-no-to-faux-bold
[2] https://www.myfonts.com/fonts/mti/bembo/
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.
“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
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...
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: http://imgur.com/iLNgoaU
Here’s what fits on a page in an Edward Tufte book: http://imgur.com/dTLcDx2
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.
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.
http://usabilitypost.com/2014/05/10/using-small-caps-and-tex...
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.
https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=...
https://github.com/daveliepmann/tufte-css/issues/22
More on that:
* http://www.smashingmagazine.com/2012/06/19/classes-where-wer...
* http://fiatjaf.github.io/classless/
https://en.wikipedia.org/wiki/Edward_Tufte
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.
Butterick's implementation is more than a CSS guide though, right? I thought his design was to show off the power of Pollen[0], his online-book-publishing system.
[0] http://pollenpub.com/
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.
http://www.markboulton.co.uk/journal/five-simple-steps-to-be... http://webtypography.net/toc/
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 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.]
Everyone criticizing the implementation, here, let me help you:
https://github.com/daveliepmann/tufte-css
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[3] (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[4]. 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[5], and try resizing your browser window or hitting it on a mobile device.
[1]: http://gameprogrammingpatterns.com/
[2]: https://github.com/munificent/game-programming-patterns/blob...
[3]: https://github.com/munificent/game-programming-patterns/blob...
[4]: https://github.com/munificent/game-programming-patterns/blob...
[5]: http://gameprogrammingpatterns.com/double-buffer.html
(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.)
http://imgur.com/a/TXpis
What help. /s
Searching "css sidenote edward morbius" on G+ might turn up something and basic CSS.
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. http://codepen.io/dredmorbius/pen/KpMqqB
Daniel Bos's sidenote implementation: http://loadingdata.nl/waves/
(Degrades nicely for non-CSS viewers, not responsive.)
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.
This handout, by contrast, doesn't do this, and so it throws away something that, to me, is central to Tufte's appeal.
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.
http://snag.gy/yup65.jpg
There's a chunk missing at the top, and it looks like crap! It should look like this:
https://upload.wikimedia.org/wikipedia/commons/4/49/BemboMT....
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!
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:
http://imgur.com/a/TXpis
(Using floats and negative margins.)
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.
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!
[1]: http://i.imgur.com/CNBSMVH.png