Designing with Typo

...graphy, that is.

It's been a while since I read a book that's worth mentioning, but here I am again, this time with The Non-Designer's Design Book.

It's rare that you read a book that would be useful to just about anyone. And when I say just about anyone, I really mean that. Not only programmers, or people interested in computers, but potentially also home moms, school children and practically anyone who might at some point of their life do anything that has something to gain from looking look and would involve some text.

The emphasis, however, is "text". I was a bit mislead with the title of the book, and understood that the book taught about design in the general sense. But, as the subtitle states ("Design and Typographic Principles for the Visual Novice"), it's very typography-centered – how to lay out text and how to choose your fonts. Just wanted to get that out from the start.

Although this book is recommended for practically anyone, I would recommend this especially to all the programmers out there. We programmers tend to be very left-brained; we like solving those puzzles with elegant algorithms, create nice structures for later use and tinker around, looking how changing this thingy alters that thingy. The right side of our brain gets suppressed quite easily, for a reason or another.

While I mainly speak of my personal experience, I'm sure there are others out there who relate with me, but when I try to present my ideas and thoughts (be it UI or even a website), I get lost, and don't know how to accomplish. I even might have a clear vision inside my head, but it never looks as nice outside of my head. This book gives very concrete, usable and easy to understand examples on how to lay out things. Even if the book uses text as its main design element, the main principles can be applied to some graphic elements as well.

I think the most important, yet easiest to understand, message this book comes across with is CRAP. Contrast, Repetition, Alignment and Proximity, that is.

• Contrast your type readily with other elements to make them stand out;
• Repeat some elements throughout your document/text to make consistency;
• Align your text consciously and in an orderly fashion and not just thrown around; and
• Place together (hence, proximity) information that belongs together.

The book has more extensive and visual explanations about these rules, so it's unnecessary for me to try and explain them here. This is the first half of the book, and, as said, the most important part. If you won't read the whole book, at the very least, read these principles, and you'll come very far, not to mention produce layouts that stand out from the mass of average.

The other part of the book explains about fonts, different families of fonts, what the basic structure of a glyph (a shape that represents e.g. a letter) consists of, and how font families can be mixed and matched. Although this part was a less generalized, and more about the art of fonts, I found this very interesting and gave me, as a web developer, much insight on choosing my fonts properly in the future.

In short, besides the misleading (to me) main title: I have absolutely nothing negative to say about this book, but only hearty recommendations. Since you are reading my blog, there is absolutely no excuse for you not to read this book (except if you already have read the book).

The fact that I don't own the copy I just read (I borrowed it from work) is kind of a bummer, since I can't just pull it off the shelf and refer to it later on.

---

On a more LightFrame-y note, the documentation process is progressing slowly but slowly. I have set up a GitHub repository for a reference implementation of the documentation. It uses the Git's submodule feature to refer to the documentation itself. I haven't played around much with submodules, you might need to read up on how to grab the latest version of the documentation itself. Setting up the environment isn't exactly user friendly either, so to just read on the current state of the documentation, I have put a copy on my own temporary server.

My Curse by Design

I am cursed. The curse is so potent, so strong, that it could affect other people. In fact, not only can it affect the behavior in others, it could even make other people less productive than how much they could be.

I know too much.

My curse is that of the Knowledge. I've long realized that I must suffer from it, because I've written all the code. I know LightFrame inside-out. The presence of The Curse has been in my rationale at all times, but I just never actually noticed anything that would indicate its grave reality. Until now, that is.

The first time that I got a vague yet concrete hint of Its presence was when I did the presentation of LightFrame at work. Soon afterwards, I realized that with not-at-all-that-much of misinterpretation, people could've missed the essential points of this project. I knew the points – I have them lodged somewhere in my frontal lobe. I simply assumed that the choices of my words in my presentation conveyed them to others, but I never really checked whether they were clear enough, once the slides were done.

Listeners might not become imbued with the niceties of LightFrame, discard it as redundant and go on with their lives. In fact, just about that did happen.

A more recent and real slap-in-the-face is the documentation process I'm currently busy with. If you'll excuse a slight detour in my writing; as I've told before, I held a brief Git workshop at work. During the workshop, I happened to make a comment about Git's documentation: [paraphrased] "The documentation can be a bit confusing and hard to get grasp of. Although it's thorough and informative, much of it is written by [the author,] Linus Torvalds himself. And that's the problem – he knows the material too well, and apparently has a hard time explaining the concepts to a person who doesn't know all the things he knows."

Well, see: I'm there now. I'm writing a non-technical manual, that should be easy to read and understand, about something I have intricate technical knowledge of. It's hard, if not outright impossible, to put yourself in the shoes of someone who doesn't know what you know.

I find myself constantly analyzing what I've written; erasing passages too elaborate and verbose, rewording sentences here and there and/or rewriting paragraphs because I'm trying explaining it from various angles. What does the reader not know? In which ways could my words be interpreted? Is this more helpful than confusing? These are the self-doubting questions that haunt me. The answer to all of these questions, more often than not, is "I don't know!"

I wish I knew less, so I could do a better job...

Musings about Exceptions and Exceptions

Because I'm in the middle of documenting LightFrame (or what it is today), there's not much of interest to report from the programming side of things*. So, instead, I'll revisit a past musing, and how it got resuscitated with a twist.

*) Actually, there might be something I could write about the documenting process, and how I was forced to fork an open source project, to be useful for documenting. But that story has to wait...

Time for a trip to memory lane.

Almost a year ago, I confessed my confusion of the difference between PHP's exceptions and errors. In that article, I wondered why both of them exist, as they seem to do the same things, but concluded, that errors happened when there's nothing one can do to fix the situation, while exceptions give you a second chance to fix things, or at least fail gracefully.

When I re-read the article (I always love to read what I've written in the past, to see whether I've grown wiser or dumber since then), I noticed the little postscript that I left on the page: "One must wonder whether these musings bite me in the ass someday..." I was then worried that the article would give away my naïveness when it comes to error handling and/or programming. But, it turns out that the confusion between errors and exceptions is nothing compared to the confusion between exceptions and exceptions.

Java, the promised language of correctness, robustness, design patterns and exceptions, brings uncertainty of how to really use its exceptions. Let me present you: Exhibit A. Turns out that I'm not the only one wondering about the semantics of stuff.

Java has two kinds of exceptions, runtime exceptions and checked exceptions. Runtime exceptions may be thrown at any place of the code, and they can be caught, or disregarded, while checked exceptions must be caught and dealt with – If you don't catch a checked exception, the code won't compile. The question was when to prefer one over the other.

I gave my opinion on the matter: I argued that the case in question shouldn't use exceptions at all, but a return code to differ between a successful run and a failed run – a third, totally different, point of view. Funnily enough, this answer was the publicly most accepted answer at the time of writing this!

What a relief: I'm not the only confused one!

...or actually, that's not a good thing at all. I would rather have it clear-cut how to use what features. It would make everyone's lives easier, when there's an intuitive and clear separation between Method A and Method B – that there would be no question of which method to use where, because doing it The Other Way would be just stupid, dumb and ass-backwards.

Unfortunately. This isn't going to happen. There will always be nuance-differences between Method A and Method B. They came to be when a language developer encountered a situation which couldn't be dealt with in the precise manner that would be 'correct' for that particular case. So that particular case gets generalized, and it's a free-for-all for anyone to use in what ever context they wish. This is why you can do the same stuff in a zillion different ways, each just a tad different from the next one.