HN Books @HNBooksMonth

I strongly believe that in order to do good interaction work you really just need to understand typography well. That might not be a popular viewpoint around here, but I encourage you to consider some of these references.

I recommend Josef Muller-Brockmann's Grid Systems in Graphic Design: http://www.amazon.com/Grid-Systems-Graphic-Design-Communicat... or Emil Ruder's Typographie: http://www.amazon.com/Typographie-Manual-Design-Emil-Ruder/d....

There are many, many other good resources but those are important primary sources. So is The Elements of Typographic Style, by Robert Bringhurst: http://www.amazon.com/gp/product/0881792128/ref=pd_lpo_sbs_d....

⬐ blawa

Thank you. While not exactly what I was asking for, this is great to know.

⬐ mattmanser

It doesn't sound like you know what software design patterns are. This has absolutely nothing at all to do with design patterns, which is about software design and how to manage complexity and nothing else. UX is not code.

⬐ ulisesrmzroche

The origins of patterns in software are actually from architecture. Code is just a medium that we work with, but they've been used in other fields for millennia.

Plus patterns in software are not all about managing complexity, and only some of them are about code construction. Like, do you know what the pattern is before you debug anything?

They're heuristics, basically.

In any case, a good ux pattern would be a top nav, but not fixed to the top.

⬐ domedefelice

@mattmanser the op asked specifically for UI patterns: "To give an obvious example of what I'm looking for- I would say, use margins to separate multiple instances of same components (among other uses)."

⬐ scarmig

Question of the day: did design patterns originate with the GoF, or did they originally exist in the world outside of code as patterns to improve human experience?

⬐ thuuuomas

Code producing bad UX is bad code.

⬐ bigtunacan

While I agree that the TC intended software design patterns, I don't think a WTF is in order for the confused reply.

The term "design patterns" stems from architecture, not computer science, and is used by designers as well for the common patterns that may be applied for good UI/UX design.

http://ui-patterns.com/patterns

Somebody better let Google know that "design patterns" don't apply to UX.

https://developer.android.com/design/patterns/index.html

https://developers.google.com/web/fundamentals/layouts/rwd-p...

⬐ hamburglar

> The term "design patterns" stems from architecture, not computer science

Do you have any references? I find this fascinating, but googling "design patterns" and "architecture" together just results in lots of "software architecture" topics. Who originated the idea?

⬐ Isofarro

http://en.wikipedia.org/wiki/Software_design_pattern#History

It's important not to oversell the touchy-feely/what-looks-good side of this. Font design is certainly about planning and calculation, it's just that those calculations need to be based on optics rather than geometry.

Instead of perfect circles, we use a shape that is taller than it is wide; instead of splitting the space in half, cross-strokes should be higher than the middle; different strokes need to be different widths in order to appear the same, etc.

There are plenty of actual scientific studies and theory behind this. See Ruder's Typography [0] and Hochuli's Detail in typography [1] for more info.

[0] http://www.amazon.com/Typographie-Manual-Design-Emil-Ruder/d...

[1] http://www.amazon.com/Detail-Typography-Jost-Hochuli/dp/0907...

⬐ bolder88

Possibly related, the fact that when you hang a door, the gap between the top hinge and the top of the door, should be smaller than the gap between the bottom hinge and the floor.

This makes the door spacing look equal from our usual standing position.

What sounds good on paper/design (Make the spacing equidistant) can often look terrible in practice.

I think the font looks ok, but the "d" looks bad to me. And I'm not convinced about the "t". Maybe they make sense on paper, and have very nice mathematically correct proportions, but they still don't look right to me.

⬐ cscheid

Similarly, I once heard a story that http://en.wikipedia.org/wiki/David_(Michelangelo) has a bigger head than usual because people would be looking at it from a funny perspective, and foreshortening would make it look strange if the proportions were not changed.

⬐ kbenson

What about the difference in use? Do you know of any work that examines whether there is a difference in the importance of attributes depending on whether it's for programming or reading?

I know different things are important to me when viewing programming text than reading. A simple, somewhat contrived example would be whether 'r' and 'n' together are easily discernible as 'rn' or 'm' (which is mostly a non-problem with mon-spaced fonts). When reading text, I can infer from context what the word most likely should be, but when programming, that's an error waiting to be found at some point.

To expand on this, different programming languages may stress different qualities of a font. From experience, I find when parenthesis look like curly braces in a font, it increases my frustration as it causes ambiguity where there should be none. This may be less of a problem in a language that uses fewer braces.

⬐ lallysingh

You read code when you're programming. The only difference is the mix of characters you'll see near each other. General readability matters -- when is it OK for a regular font to be unclear about which character (a zero or 'O') you're looking at?

The 'rn' case is one of kerning, and is an issue independent of the mono- or proportional-ness of the font; it's one of kerning. You can have 'r' and 'n' at full width for the font, and they'll look very 'm'-ish. If you have 'rn' looking like 'm', it's just as awful when you're reading a novel as when you're reading code.

⬐ hsitz

"The 'rn' case is one of kerning, and is an issue independent of the mono- or proportional-ness of the font; it's one of kerning."

No. Kerning applies to proportionally spaced fonts, not monospace fonts. See, e.g., http://en.wikipedia.org/wiki/Kerning Designing monospace fonts so that character combinations are more readable has nothing to do with kerning.

⬐ dragonwriter

> You read code when you're programming.

Right, but not for comprehension the way you read prose, but for technical accuracy of an input to a mechanical system that will read it and which is intolerant of errors even when the meaning is clear from context. For human consumption of prose, fonts that can sometimes create ambiguities of individual characters that are easily resolved from context but which keep the overall shape of morphemes recognizable are mostly fine, for creation of content -- particular content to be read by a machine, they are not.

> General readability matters -- when is it OK for a regular font to be unclear about which character (a zero or 'O') you're looking at?

For readers, quite a bit, because for most purposes, the meaning is clear from context (same with 1/I/l), and because people with more than marginal literacy mostly are recognizing the visual shape of (approximately) whole morphemes, not individual characters.

> If you have 'rn' looking like 'm', it's just as awful when you're reading a novel as when you're reading code.

For the reasons stated above, that's not really true.

⬐ n0nick

> You read code when you're programming. The only difference is the mix of characters you'll see near each other. General readability matters -- when is it OK for a regular font to be unclear about which character (a zero or 'O') you're looking at?

The difference in mix of characters reflects on the design decisions made for the font type. Target use is important. Some types are great for titles, some for text bodies, some for logos. It makes sense to me that code is another category.

Yes, readability is important, but it's not binary. The level and aspects of readability required for a novel body are not the same as for an article title.

Differentiating between zero 0 and uppercase O is critical for code (and work terminals, and perhaps data tables), but IMHO isn't interesting when designing for text bodies. Same goes for 'rn' and other issues that have ever annoyed only programmers.

⬐ thaumasiotes

> when is it OK for a regular font to be unclear about which character (a zero or 'O') you're looking at?

This is OK virtually 100% of the time, in that there are no circumstances where you'd be confused over which was meant. In contrast, I write 1 and l exactly the same way under most circumstances. That could be pretty annoying if, say, I was doing a geometry problem involving a line named l, since numbers frequently appear in math problems. In fact, I suspect that many other people have had that same problem, since high school geometry textbooks, while they still like to name lines l, use a cursive font for it.

It's very rare for a literary work to feature e.g. one character named Oscar and one named 0scar.

There is not. And honestly I don't think it's a must have. It's certainly a beautiful book, but you can learn most of what you need to know about grids just by Googling around. Typography is a comparatively much more complex topic, warranting the purchase of a book, and there's more to layout than grids and Swiss-German design.

If you want to buy a beautiful multi-lingual design book from that era, Emil Ruder's Typographie is the better buy: http://www.amazon.com/gp/product/3721200438/ref=as_li_ss_tl?...

For those interested in typography, while I found blog posts helpful in teaching myself, if you really want to understand, I recommend reading one of the canonical texts depending on your particular interest. Typography is a deep field with a lot to know before you can really know what you're doing.

The Elements of Typographical Style is a beautiful book and an elegant, literary introduction and guide: http://www.amazon.com/gp/product/0881792063/ref=as_li_qf_sp_...

Thinking with Type is full of contemporary examples to give you new ideas: http://www.amazon.com/gp/product/1568989695/ref=as_li_qf_sp_...

Ruder's Typographie is the book that established modern typography and is the de fact guide to modernist typography: http://www.amazon.com/gp/product/3721200438/ref=as_li_qf_sp_...

As an introduction to typography, I also recommend watching Helvetica: http://www.amazon.com/gp/product/B002RIOGI0/ref=as_li_qf_sp_... – it will give you a personal perspective on different philosophies of choice of type-face

For that matter, the same goes for color theory.

Here's a nice introduction to color in general from the Adobe website: http://www.adobe.com/products/adobemag/archive/pdfs/9611febf...

The Wikipedia entry is worth reading: http://en.wikipedia.org/wiki/Color

Kandinsky's Concerning the Spiritual in Art is a beautiful manifesto on art, but contains a very interesting theory of color: http://www.amazon.com/gp/product/1619491532/ref=as_li_qf_sp_...

Itten's The Elements of Color is the classic text on color: http://www.amazon.com/gp/product/0471289299/ref=as_li_qf_sp_...

Albers' Interaction of Color will teach you that colors are no absolute reference ponts – they interact with each other to create all sorts of effects (this text pairs well with the Kandinsky): http://www.amazon.com/gp/product/0300018460/ref=as_li_qf_sp_...

To get really deep into color, check out the IESNA handbook: http://www.ies.org/handbook/

All this is not to obviate OP's impetus to write posts on these topics. Blog posts are crucial as introductions and I find tend to work better as references than books, which tend to be overwhelming and ignored in this digital age. But if you want to go deeper, these are my favorite references after moderately exhaustive research.