While by no stretch of the imagination high-brow literature, the book was a light, casual and entertaining read. It’s the year 1997 in the life of ‘A&R’ person Steven - narrated by himself. As such it moves pretty much along the stereotype of that business. No idea or interest in music - but terribly busy trying to find the next cash cow, scoring and using alcohol, cocaine and whores (not necessarily in that order and quite likely all three together), and a bit of disregard for everybody else from the ‘acts’ to the colleagues in between.

To make this more interesting the story was enriched with a hint of American Psycho - meaning that we don’t get the classy business cards but still the envy about better looks or cars. And a kill or two.

Bookmark: 19-03-2008, BA6410 CPT → JNB.

[Buy at amazon .com, .uk, .de]

I couldn’t have been more wrong. The fact that the book was written in 1988 - before bloggers even knew they’d go by that name - should have been a hint. And, according to the foreword added to the 2002 edition, the book was originally published with the title The psychology of everyday things. A title which reflects the book’s content more correctly but also led to it be shelved wrongly and thus selling poorly. Even though the new title put me off, I can see the point of that title change. As it is concerned with design, the book shouldn’t be waiting for buyers in the psychology section of a bookstore.

And Mr Norman presses all the right keys for me. He stresses that many mistakes are caused by the design not just permitting but encourageing them and he manages to illustrate that with (a few) surprisingly simple examples. Everybody knows that telephone systems or VCRs are proverbially hard to use…

in my experience that’s only semi-true, btw, but I only used 1990s VCRs with on screen displays, something that probably didn’t exist when the book was written. The VCRs I know aren’t wondrously simple to use and things like daylight savings time can be a real problem with them but they are reasonably easy to program and my own will even automatically tune into stations and set its clock - a fact which my flatmates amusingly still haven’t discovered although the button for the auto-tuning is one of the few buttons on the machine’s front.

… but what about door handles and doors, water taps or running into a set of light switches with no clue about which one is connected to which lights? A few of them are well designed while others aren’t. And the latter one are quite common and frustrating to use.

The book discusses the actions people take and how those work. It highlights how a user’s memory plays a role in performing tasks and how a good design can aid people using it. It is stressed many times that prettiness isn’t the objective of this exercise. A huge smooth wall may look great. But if it’s actually a wardrobe and you can’t tell that it has openable doors, it’s a usability failure.

The examples given in the book are good - particularly as they are traditional ‘hardware’ examples rather than the software examples we see so many of these days. I did find, however, that many of them were very simple. On the one hand that drives home the point that even very simple tools can end up being very poorly designed. On the other hand it makes you wonder what examples for well executed designs of very complex things are. Do they even exist?

Being the destructive person that I am I rather enjoyed the bits given on destructive testing around page 141. I tend to run into many problems when using software. And usually I don’t even need to try hard to do that. Perhaps that’s just because I’m more observant than other people or because I find it easier to blame the software for things going wrong where others blame themselves or perhaps it’s just bad luck  (I should really try to capitalise on that and rent myself out as a tester…). And just occasionally, when too many failures have happened, I enjoy abusing things.

For example it has always been agonising to accidentally drag a huge text file on Cocoa applications on the Mac. Endless stalls and unreasonable memory consumption usually followed that, with cursing at the computer following a little later. Guess how delighted I was when my Pavlovian bitching reflexes were already triggering in a similar situation in Mac OS X.5 but I realised that TextEdit had been improved to behave much better in such situations. Of course I had to stress test other Cocoa editors after this (the results of which were a bit disappointing).

Something everybody programming computers should read is the section on page 178f. With a good sense of irony it recommends to Make things invisible […] Be arbitrary […] Be inconsistent […] Make options unintelligible […] Be impolite […] Make operations dangerous […] - and I’m pretty sure that even today’s computer users may find those approaches in software shockingly familiar.

One thing in the book I really couldn’t agree with, though, is the discussion of a stove on pages 75ff. Perhaps American homes are just that huge or Mr Norman is just that rich that these things don’t matter for him, but the discussion in the book suggests that the arrangement of controls for the burners on a stove in a row is downright stupid. While the examples he gives as improvements certainly illustrate a point, they conveniently ignore many practical limitations of setting up a stove. The first is space. Usually 60cm by 60cm will have to do. On that area you can just fit four burners in a way that lets you use two large pans and two small pots at the same time. There won’t be any space left to put the controls on top.

Particularly so, if you take into account that you want the controls to be large enough to be handled easily while cooking, possibly with wet or greasy fingers. They should also give haptic feedback at the same time. I don’t think you’d want to have you stove controls too close to the burners or the hot pots on them - that’d be an accident waiting to happen. And if you can’t arrange the controls horizontally, you’ll have to go vertical. I have seen a stove where they were they put the controls on a vertical thing they raised at the back of the stove - which seemed immensely stupid as you always had to reach through the hot steam and whatever else might be coming from your pots and pans to reach them. What remains is putting the controls at the front of the stove. And there you simply want them to be as high as possible, so people can still reach them while standing upright. Making the design more ‘natural’ by putting some of the controls further down would spoil that (and quite likely collide with the door of the oven beneath the stove). It would have been interesting to see a solution for that stove problem in the realistic situation with space constraints. A solution that would work in practice.

[Buy at amazon .com, .uk, .de]

Bookmark: 04-08-2004, ICE Göttingen → Bremen.

Looking at sites like Presentation Zen gives you the impression that in those business presentations you’ll get away with some gradients, some stock photos and some tangential but clever quotes on your subject. And - giving the benefit of the doubt - I’ll assume these techniques actually work. In a more scientific context many of those methods seem to fail though. Basing a presentiation on stock photos and witty quotes will probably get you laughed out of the room or at least not be taken seriously. And, much more significantly, people usually have non-trivial information to tell.

At least in areas like science, mathematics or engineering that information already requires visual aids so the audience can see the measurement results, follow the deduction of the formula or visualise the constructions. After all that has been incorporated into the presentation there is little space left of the pretty or witty. But still bad presentations are very common in these areas and it was cool to discover that there’s a book on the topic: MIchael Alley’s The Craft of Scientific Presentations. It’s a book with a promising title and - even more promisingly - with Mr Feynman on the cover. While it is a bit repetitive at times and I am not sure it contains great concrete advice, it has a very helpful list of things that can go wrong, have gone wrong and do regularly go wrong in presentations:

• Giving the wrong speech (audience? purpose? occasion?)
• Drawing words from the wrong well (speaking from points, memory, paper, of the cuff)
• Leaving the audience at the dock (anticipating questions and bias)
• Losing the audience at sea (make changes in course clear, don’t drown people in detail)
• Projecting slides that no one reads (typography, colour, layout)
• Projecting slides that no one remembers (show images, results and the presentation’s organisation)
• Ignoring Murphy’s Law (rehearsing, arriving early, accounting for the worst)
• Not preparing enough (preparing visual aids, yourself to speak, talks in another language)
• Not paying attention (to the room, yourself, the audience, time)
• Losing composure (controlling nervousness, handling questions)

Most presentations will most likely improve by simply taking into account a few of those points before holding them. In fact, I’d wager that most people could nod to every single point in the list and think yeah, I’ve seen that or even yeah, colossal FAIL on that one in talk XY.

Of course the various points apply to different degrees in different subject areas. Both because of the differences in topics but just as well due to the differences in culture. In mathematics, say, the danger for technical FAIL is much lower because people frequently use blackboards which at the same time is good for reducing the presenter’s speed to a reasonable level (i.e. slide based talks are frequently incomprehensibly fast as it’s damn easy to flick through a bunch of slides with a complex argument in a minute but it will take time to write it out) and bad for his face time to the audience (not that mathematicians would notice that, anyway). On the other hand it’s really hard to adjust a talk well to an audience as being familiar with the intricacies of the topic makes many things look ‘obvious’ when in fact they are not to people hearing them for the first time.

The list will be helpful to keep in mind, both when making and when consuming presentations.

Nagnagnag: I had to sigh about the book’s typographic attitudes though. It’s set in the lovely Palatino but somehow they managed to make the font size a bit too large and the line spacing a bit too tight which makes it look like a school book. The author also likes Arial (headings in Arial Narrow Bold and recommendations to use it for slides all over the book) which makes it particularly amusing to see that the Regular version of the font was replaced by proper Helvetica. Now that’s a refreshing turn of things.

[Buy at amazon .com, .uk, .de]

As most of the texts are available on the internet as well and their snippet sized length makes reading them on screen no problem, there isn’t that much going for the book on the content alone (unless you like carrying books when you’re moving). However, each of the 79 texts is set in a different typeface. As a typeface geek I really enjoyed that. You can read something and get an impression of how a typeface feels at the same time. If you thought ‘yup, that was nice to read’, you can either say ‘… because it was Garamond/Palatino/…’ in my case or for the typefaces you don’t know flip to the back of the book and look up the name. A great idea that certainly beats your typical Lorem ipsum text. That said, it would be useful to also have an index of typefaces at the back, for convenient finding of the text using it.

Now I’ll just need someone to explain to me the choice of tiny non-matching typefaces for headers and page numbers as well as the urge to write the author’s name and the book’s title in the running headers rather than perhaps the current text’s title. I’d appreciate an explanation of the lack of images to illustrate the examples or issues mentioned in the text as well - the book deals mostly with graphic design after all. And ‘we were too lazy’ would seem like a disappointing answer.

Read more detailed and also justified criticism over at Joe Clark’s.

[Buy at amazon .com, .uk, .de]

Bookmark: 11-03-2004 - Flight AA1961 Dallas Fort Worth to San Diego, Seat 25A.

Each of those maps has to find the sweet spot between precisely representing the routes and creating an easily understandable diagram. And depending on the location of such a map greater focus may be given to either of those: On a street map at the exit of an underground station you’ll want to give truthful locations of everything while, on the other extreme, inside a train or on platforms served by just a single line you’ll probably be happier with a single straight line that just gives people information about their position along that line.

The maps they are using in the London Underground are commonly taken as examples for good and - back in the days - revolutionary diagrams. With their simple in train diagrams, the precise maps at the exists and the surprisingly distorted city-wide route diagram which not only distorts distances in the suburbs but also straightens out lines considerably and even manipulates the relative positions of the stations to fit them in an easily understandable and legible diagram. The ideas used there can be found in many other public transport diagrams these days.

Many examples for those can be found in the book, which is split in several chapters that put the large public transport systems for which they had a lot of maps to also illustrate the historical development at the front and things become ‘more efficient’ towards the back where newer systems with less sources are mentioned. To a certain degree these differences seem a bit arbitrary.

Most of the larger examples are accompanied by what I’d call ‘obnoxious commentary’ which often, but not really consistently elaborates on the past and future of the public transport system at hand as well, even when that seems fairly irrelevant to the topic of its maps. According to the commenary 45 degree angles are ‘signature’ or ‘classical’; straight lines and distortion for geometry over reality are good; Asian networks usually resemble a character of the […] alphabet; it’s worth describing things like black circles with white bull’s eyes over and over again for the symbols used for stations or interchanges.

In total I found the text rather repetitive and not particularly helpful. At the same time I could have easily imagined additions of text to make the book much better. While some general information about the length of the route network and the city’s size is provided for each system, what about some internet references? Either a web site to go with the book providing links to the site of all systems or just the address of their sites printed somewhere along with the maps. That would make further investigation easier. Less trivially, but more interestingly, I would have appreciated more detailed ‘general’ chapters discussing the stratgies in diagram-making: How simplified should diagrams be? How does that depend on the size of the city and the complexity of the system? How many maps are rotated from the usual north=up direction and why? Which symbols are used for stations and/or interchanges? What’s the benefit of extra symbols for interchanges? Are key parts of the city (rivers, parks, buildings) visible on the map? Each of those could be cross referenced to the examples that come later. At least I would find that interesting. Add some tables for quick lookups at the back and I might be drooling.

Might because apart from the text, which is easy to ignore, there’s another problem with the book. At least the edition I have (Penguin, 2007, Printed in Mexico) is very poorly printed. Most of the maps simply don’t appear crisp and clearly. While I appreciate that shrinking graphics can be tricky, I have also done this much better. And in a book focusing on a graphical topic and printing severely shrunk diagrams I expect that ‘better’. In a few places (photos of ancient prints) there might be an apology for the quality, but in most places it seems to be due to careless scaling and poorly aligned colour screens in printing. The fact that the book’s text seems to be printed in a colour slightly lighter than black without using a matching spot colour gives a fuzzy pixelly feeling even to the main text. And making a bit of effort in that direction - say to ensure that black lines in diagrams will be printed with solid black rather than rasterised would certainly make tiny text more legible. If that raised the price of printing it would certainly have been worth is as - huh - it would enable you to actually read the diagrams which are the book’s main content.

[Buy at amazon .com, .uk, .de]

Of the diagrams displayed in the book, I already used the ones in Berlin (luckily the book doesn’t discuss general usefulness of public transport graphics as Berlin is pretty crap in that respect - they may have a diagram, but they often prefer to not use them to help people…), London, New York, Paris, Hamburg, Lisbon, München, San Francisco, Amsterdam, Oslo, Prague, Vienna, Köln-Bonn, Frankfurt, Hannover, Rhein-Ruhr (now that’s a huge system because it includes several cities - quite a challenge), Stuttgart, Bratislava, [I’d love to say Genoa but I only used a bus there and they ‘system’ with a handful of stops on a single line is a bit trivial diagram-wise,] and San Diego. Not that many, really. Of course I also used other public transport systems, but apparently they didn’t qualify for the book.

Bookmark: 08-07-2007, London Underground day pass (yeah, that seemed adequate).

Each design pattern is discussed in the same form (with paragraph length sections on: what, use when, why, how, examples). The patterns range from blatantly obvious to cool and subtle. And likewise the detail of the discussion varies widely but is generally rather short. The examples, which are almost always given as screenshots from computer applications or web sites (design patterns for hardware are mostly neglected as are non-visual aspects of interaction design) are sometimes spot-on but in other places appear a bit forced and imperfect.

What the book absolutely lacks is a touch of negativity. And I mean that in the most constructive way possible. To me it seems that in user interfaces the don’ts are more important than the dos. Many bad interfaces seem to owe their badness to designers being too easily excited by the rich toolkits they have at their hands these days. And while the patterns’ ‘use when’ section sometimes touches situations in which the pattern at hand should be avoided, that is never exhaustive and we aren’t shown bad examples (of which the software and web world certainly provides many).

The book also seems to limit itself to being descriptive. Unlike the design patters which we found in works like Apple’s Human Interface Guidelines from the 1980s, these patterns seem to be mostly based on observation and lack research and indications on how well they work and where their problems are. For many patterns I do not doubt that they exist but I really doubt that they are any good. Examples here could be Number 45 (Putting numbers in filled circles as they do for numbering the patterns in the book must be one of the stupidest graphical ideas ever, btw. It is hard to make those look good. And whoever designed that book certainly didn’t even try.), the Action Panel, by which Mrs Tidwell refers to panes which you frequently see in the Windows Explorer, for example. And in that specific example, I remain unconvinced that they help at all. As their contextual changes make it hard to know which command is where. And - possibly - in longer usage, I keep thinking that having these panels at hand is a way of dumbing down the UI in a fashion which keeps the user from learning its real power. That’s just an unproven hypothesis as well, of course, but I would have loved to see a well founded discusssion of it. And perhaps a discussion of how the right sidebar of an application like Lightroom relates to that pattern. (Amusing bonus point: The screenshots for this pattern feature a Windows file browser displaying a .DS_Store file. Now I have to wonder whether I should take this as careless or as ironic.)

The next pattern, Number 46, Prominent ‘done’ button merits discussion as well. If you have a preferences window which applies any changed setting immediately, should it have a ‘OK’ or ‘Save’ button? The argument in the pattern suggests that even if the button isn’t necessary it gives the user an obvious and reassuring way out. On the other hand, I’d say it suggests that changes are only applied when the window closes and that a good preferences window should only have a close box.

The next one, Number 47, Smart Menu Items certainly merits some discussion as well. In many cases it’s good if menu items adapt their text to the specific action they will trigger. The Undo command is a prominent example for that and is more helpful when it states what will be undone. On the other hand, Mac OS X.5 overdoes that idea in some places. For menu items which essentially reflect and change an on/off setting it doesn’t simply use a constant text plus a check mark but instead it changes the verb in the text to its negative. At least for me that makes the interface harder to use as I have to actually read the menu item to learn the current setting. If you want to see a particularly absurd example of that, look no further than TextEdit’s Format → Text → Writing direction sub-submenu. TextEdit’s menu item for hyphenation would be an obvious example for that and the View menus in many applications provide many others.

Want another one? Try Number 49 Progress Indicator. It gives all the commonly known things about progress bars and how to handle indeterminate situations as well as time remaining display. But I totally expected a discussion of the ‘phenomenon’ of what I’d call ‘double progress indicators’ which you see particularly in installers or generally in situations where an action consists of several distinct steps and you get a ‘global’ progress indicator a well as one for the step at hand. What about discussing (or at least trashing) that pattern which without doubt exists?

OK, one more: Number 68 Forgiving Format is what I consider to be one of the most important design patterns these days and for which I’d borrow the freeform goodness name from Dave: letting people enter data or queries as relatively freeform text and extracting what they want from that without getting into the way. Of course a lot of the magic there lies in the code behind the graphical interface elements, but this ‘pattern’ seems so important to me that mentioning on a single page seems underdoing it. I suppose this pattern alone could be discussed in a whole book of its own.

Perhaps these few examples illustrate what I think is missing in the patterns the book gives. What is written there isn’t wrong but it seems rather incomplete.

The coolest chapter of the book is probably the sixth - on data visualisation. Incidentally it’s also the chapter which the author claims to find most interesting. That’s probably because everybody is fascinated by cool and efficient ways to visualise data and a few nifty examples are given in that chapter. The shame is of course that situations where you have to actually handle data which are sufficiently rich and varied to ‘pull a Tufte’ in your user interface are rare. In most situations all you have are a few numbers. And if you have more data, it seems likely that your application is so specialised that nobody wants to ‘waste’ a lot of resources on researching how you could refine the user interface for it.

All-in-all, I found the book interesting but a bit superficial. With dozens of ‘patterns’ at hand I’d also find it hard to actually remember all of them. Particularly as some of them are trivial while others are highly sophisticated.

But at the end of the day, who’d want to disagree with an author who describes overly colourful interfaces as a rainbow colored ‘angry fruit salad look’?

[Buy at amazon .com, .uk, .de]

That’s quite a messy area to work in. Simply because you have web standards on the one hand and you have web browsers on the other hand. Sometimes the standards aren’t entirely clear in what they specify. And usually browsers don’t exactly stick to them. It would be great to have a complete list with examples explaining how they should work and showing how they actually do work in various browsers. To be perfect, workarounds would be listed with the failures in browsers’ compliance. Web design would be simple from technical point of view.

Such a list doesn’t exist and the richness of even relatively simple-minded systems like HTML and CSS along with the huge number of browsers makes it vain to hope for it. Rather, you’ll have to depend on your own experience, a number of web sites with the standard hints and workarounds and the odd Google search when you see no way out. That does work but it also seems a bit less systematic than I’d hope for.

And while I have given up on finding that ‘perfect’ list, I started thinking it wouldn’t hurt to actually look at existing books on web design to see how professional writers people writing books on web design approach this set of problems. It turns out they simply don’t. They mostly limit themselves to describing the basics of HTML and CSS in a more or less systematic way. And never in a way that’s more helpful than what you find at sites like Self HTML or even W3 Schools. In part this may be because you can interactively test as well as copy and paste things from these sites, but my impression often was that it’s also a matter of people writing books on web design have no friggin’ clue about more than the most obvious basics and are bad writers. Compared to some books even the W3C specs for HTML and CSS start looking well-written and helpful. At least those - if only by definition - can’t be wrong.

Jeffrey Zeldman is historically one of the most vocal standards zealots who successfully tried to concile the business and technical side of using web standards. He knows the game and he wrote a well known book about it - Designing with Web Standards (without the the capital letters, to be precise), which I managed to look at as well, the ‘new’, second edition of which I looked at as well. It was refreshing in that it’s a book whose author seems to know what he’s writing about. But it’s very confusing as well. At least to me.

My problem with the book is that it seems to do everything at once and nothing properly. It spans the whole range from evangelising web standards to the clueless through to technical examples of browser hacks with the nitty gritty HTML given right there. (Actually XHTML because Mr Zeldman seems to be an XHTML zealot, even though that difference seems to distract from his main point rather than helping it.) While it’s laudable to attempt spanning such a wide range of topics, a book of less than 400 pages cannot do that satisfactorily, particularly in the chatty style it is written in. As a consequence many topics aren’t covered fully or are just mentioned. Even worse, many of the more advanced topics are merely mentioned in a single sentence and ‘covered’ by giving a link - printed in a monospaced typeface - in the text.

I keep wondering who is the target group of the book. As it only sketches the issue which you need to know about to actually do web design, it seems to be made mainly for the pointy haired bosses who need to ‘know’ about a topic and put the book back on their shelf after skimming the first few chapters. And that would be a waste.

I didn’t like the general style of the book either. It seems quite unfocused and arbitrary. I’ll list a few more oddities I noticed:

• It uses a strange font which looks a bit like Donatora but has Old Style Figures the 3 of which doesn’t descend beneath the baseline and gets its opening quotation mark the wrong way round and the closing one poorly spaced. I find it hard to read. But that may just be to get you into the spirit of web typography.
• Since when has ‘output’ become a verb? [Update: Roland points out that ‘14th century’ is an answer to that question. Now I’ll just have to meet someone who actually uses ‘output’ as a verb.]
• Highlighted boxes in the text are referred to as sidebars even though they are not on the side.
• The ratio of original content to cross references, name dropping and other things which are at best indirectly useful is at best 1:1.
• XHTML zealotry: For many readers of this book, XHTML 1.0 Transitional is likely to be the best choice for the next few years. [p. 152] I’d be amused to hear arguments for the X the 1.0 and the Transitional in that statement. Like real arguments.
• I’ve met some of the people behind XHTML 2.0. They are a lot smarter than me, and they be on to something. Still, I wish they’d spend time talking to folks like us, so they could focus their huge intellects on solving our problems rather than theoretical ones. [p. 153] Why not cut that crap and say you think they’re doing the wrong thing.
• The previous points are followed by the Top 10 Reasons to Convert to XHTML [p. 154]. All of which naturally come without arguments for them. Gems include that XHTML is the current markup standard, replacing HTML 4. or that XHTML is more consistent than XHTML, so it’s less likely to cause problems of function and display, and 8 other mostly vacuous points which hold for HTML as well as XHTML. I really don’t mind XHTML (although those stray ‘closing tag’ slashes in some elements are butt ugly), but I’d like to see web design things I cannot do in boring old HTML as well.
• I just won’t comment on the ludicrous 5 Reasons Not to Switch to XHTML that follow. I guess they could be true if you are switching from Microsoft Word as a file format or something.
• ‘Covering’ character encodings [p. 170] and omitting Latin-9 seems a bit ignorant these days if you do cover the ISO-8859 encodings.
• Patience, little sparrow. [p. 185]
• Thankfully, many smart designers and developers are leaving convoluted markup, proprietary browser code, and inline CSS behind them. [p. 204] Man, I am so thankful! And they are so smart!
• Many of us consider it bad form to write 0px or 0in or 0cm. Zero is zero. [p. 223] Many of you have no scientific backgrounds. 0°C (that strange temperature unit they use in the rest of the world) is 0°F is 0K. None of you ever used TEX.
• Even before Netscape and Microsoft agreed to build browsers that supported standards more accurately […] [p. 273] A whole paragraph of nothingness. With a ‘hero’ though. Is this a children’s book or what?
• Figure 12.1 on page 287 leaves me puzzled as how margins, borders and padding in the box model work. A proof-reader might have been helpful for that.

And those are just the things which really irked me while reading the book. It’s full of superfluous chattiness. And in many places it feels quite condescending in the way it treats the reader like a stupid little kid who needs to be guided. Instead of saying that was wrong for these reasons, it’s better to do it this way, it goes on and on telling stories about how people or we have always done things in this or that way and how in this flashy new world it’s much better to do it in another way. Particularly because Mr Zeldman himself or some of his friends have done it in that way in their latest redesign. If I cared about their latest redesign I’m sure I’d find a blog post to read about it and possibly learn what they did there. But in a book on web design I’d expect more neutral facts and less chattiness.

The sad thing is that the general quality of HTML books is so low that Designing with Web Standards isn’t as bad in comparison as the carefully selected quotes above may make it look.

[Buy at amazon .com, .uk, .de]

I think the closest I came to loving Fraktur was back in the early 1990s. We had an Atari ST at home and it was running the Signum application. For the time and for that computer Signum was an amazing bit of software. It used proportional high resolution bitmap fonts and allowed rather fancy positioning right down to fractional spacing of letters. And you could even mix different fonts as you wished. Sounds trivial today, but it was mind-blowing back then. Well, perhaps not quite mind blowing but leading me to do many things I’d consider atrocious today.

When after a while the charme of playing around with gimmicky fonts like GROT3D (a boldish sans-serif with a 3D effect) or DATA70 wore off and the font I tried to create myself was mainly an angular mess, one of the few excitements that remained was using a Fraktur font. Not just because it looked fancy but also because it included both the Fraktur-style long s ‘ſ’ and the usual round s. At least in German Fraktur writing both of them have to be used and I even seem to remember that I needed to use the + key to get the alternate s shape on the Atari (little font geek…).

One could say that Fraktur exerts a certain bit of fascination on me, but that - these days - I hardly ever have the desire to actually use it. Furthermore the uses you see of Fraktur or blackletter typefaces today - on conservative newspapers, pub signs or, quite recently, fashion - aren’t usually in conjunction with things I approve of, thus rendering the broken typefaces even more towards being forgotten by me.

On a technical level the book provides an overview of more than three hundred ‘broken’ fonts which are available today. A wide interpretation of the word ‘broken’ is taken and we get everything from Fraktur, to Schwabacher, to gothic letters, to decorative initials. The fonts are dated - both with the date of their original design and the date of their digitisation in case those differ - and their creators are named. Web addresses are given and, rather conveniently, many of the fonts which are freely available are included on a CD.

So far so boring. I doubt I would want a book like that. I hardly ever use broken typefaces after all. And many of them just don’t look that great or seem technically less than perfect (for example in many of the fonts, particularly the free ones, spacing after the ſ glyph seems to be too wide). Not much fun in seeing example alphabets for that, even when each of them is equipped with a slight variation of the same sentence to demonstrate the font’s look in a real sentence.

But those examples only occupy the odd-numbered pages in the book. And it’s the even-numbered pages which really make it shine: On those there are graphics, printed in black and pink, made just from the glyphs of the font that is presented on the other page. And those aren’t just pretty but real eye-openers in some cases. While some of them manage to create a Far Eastern flair (p. 109) and others look a tad Arabic (p. 125), we also get other effects like brush strokes (p. 239, 279), church windows (p. 285), plants (p. 303), architecture (p. 479) or little elephants (p. 403). All just from cleverly combining glyphs of broken typefaces or by simply magnifying them enough to really see the details out of context. Amazing.

The majority of the graphics is based on symmetries. By cleverly repeating and rotating the glyphs, patterns are created. And it’s fun to try and find out which glyphs have been used for a graphic. Usually those are just a few. And usually you’ll find that it’s surprisingly easy to spot which ones are used even though they may have been mirrored or rotated. On the other hand, this also highlights how similar some of the glyphs like the S, G and C are in some of those typefaces and how tricky these can be to distinguish when they are on their own.

If you love typefaces and symmetries I can absolutely recommend this book. It’s a joy to look at all those graphics and you’ll even learn a bit about the peculiarities of the typefaces in there.

Bonus notes: Some of the free fonts I quite liked were Gotenburg (p. 97), Fette Trump Deutsch for a German touch (p. 103), Harrowgate for an English touch (p. 137), Yonkers (p.231), Mars Fraktur (p. 331) [direct download link - that page is a royal mess], Nordland because it contains an elk glyph (p. 443), Gutenberg’s Ghostypes which boldly goes to abstract territory (p. 497) and the ‘exclusive’ Erika Mono Fraktur, a monospaced Fraktur font which kicks ass in ASCII Projektor and gives a whole new flair to it.

Bonus links: the book’s website, a convenient type specimen sheet of all fonts included on the book’s CD and some photos of the book at flickr

Extra brownie points if you can name the fonts I used for the initials above.

[Buy at amazon.de]

Ever since, I kept a vague interest in what happened to Adrian later on and kept picking up some later volumes when needing a third volume to fill a ‘3 for 2’ deal or so. And while the stories haven’t been quite as thrilling since, they have always been a fun read with all the family and person misery Adrian is made live through.

The latest volume I read was the somewhat current Adrian Mole and the Weapons of Mass Destruction in which we see Adrian work in a book store, go into debt for a fancy appartement that is haunted by a swan named Gielgud, watch his parents essentially lose their home while indulging in relationships which he knows he won’t enjoy from the very first moment.

In total I didn’t find this the most enjoyable volume of the series and at times reading it was downright painful because all-so-clever Mr Mole essentially knows he’s heading straight for misery but he still gives in and goes all the way. Other aspects like the affair with his girlfriend’s sister or the ubiquitous swan are downright funny, while his eternal adoring of the now Blair babe Pandora goes on and on. The war theme from the book’s title is actually a bit tragic as he sees one of his sons go to Iraq and learns about his son’s mate dying there. It’s even more tragic as Adrian just haplessly registers what’s going on there. But I guess that’s just what his ‘character’ has been built on since the first volume of the series…

Bookmark: 14-09-2007, railway ticket to Berlin and back.

[Buy at amazon .com, .uk, .de]

The new mystery is how the guy became such a great player. Here the real story kicks in and we learn that he had been locked away by the Gestapo in Vienna a few decades earlier and all he had to entertain himself while drifting towards insanity was a chess book. Both the chess skills and nervous problems seem to have stuck.

Bookmark: 06-02-2006, flight FR 436 Stansted to Lübeck, returning from Cambridge.

[Buy at amazon .com, .uk, .de]