UNDERDOG of PERFECTION

Update (5/29/2012): Upon working further with the project that formed the basis of this post, I discovered that my solution did not work, or at least, no longer worked. It’s not uncommon as I get deeper into a project with a large CSS file that there are subtle, inadvertent effects of the various CSS properties that get added along the way. Looking back now, I can’t determine for sure whether my solution did once work with the simpler version of the site, and something else I added later counteracted it, or if I was just too eager about a solution to realize it never quite worked in the first place. As a result, I had considered deleting this post entirely, but I have decided to leave it live, to further the discussion of the topic, or at the very least to serve as a monument to my challenges.

WebKit, the rendering engine “under the hood” in both Safari and Chrome, has a known issue handling the CSS letter-spacing property at certain small increments, and at certain font sizes.

Specifically, if defining letter-spacing in increments smaller than 1px or 0.1em, it seems to just ignore the property altogether… except at larger-than-default sizes.

I typically use em or % these days to define text sizes in CSS. So in my situation, I’ve found that my letter-spacing: 0.05em works if I also specify font-size: 125% (or larger), but if I have font-size set to 100% or less, the letter-spacing gets ignored.

Typically, after loading reset.css, I set a baseline font size for the document with body { font-size: 100%; } (or some size… actually it’s usually 80% but these days I’ve been leaning towards larger type).

I decided to play around with this a bit to see if I could resolve the letter-spacing issue, and I found a nice, easy solution that works at least for the particular site I’m currently testing it on. Your experience may vary, depending on how your HTML is structured and how complex your design is.

Here’s the solution:

body {
  font-size: 125%;
  letter-spacing: 0.05em;
  line-height: 1.3em;
}

body>* {
  font-size: 85%;
  line-height: 1.3em;
}

You may want to adjust the exact values of font-size to suit your needs. (And, yes, I’m aware that mathematically 125% and 85% don’t cancel each other out, but they’re close enough for my purposes.) It’s important to include the line-height property in body>* to define your target line height; otherwise your lines will be too far apart. Set it to whatever your ideal value is. (I usually prefer line-height: 1.5em personally, but for larger type, as on the site I’m currently working on, it gets too spaced-out.)

So what’s going on here? Well, strangely, it seems WebKit can actually render smaller type with line-spacing less than 1px or 0.1em just fine, but it won’t unless somewhere in the “cascade” the type has been defined as being a certain amount larger than 100%. I don’t get it, but until the bug (which it seems clearly to be after all of this) gets fixed, at least this seems to be a reasonably clean workaround.

It’s very important that you use body>* and not just body *. If you don’t know why, well… try it out and see. (The upshot: we’re applying a uniform scaling-down across the board on all elements directly under body, which is practically the same as just defining our target font size directly on body itself, but with the benefit of working around the letter-spacing bug.)

Note: I have only tested this using em as the unit of measure for letter-spacing. I’m aware of the issue with px as well, but I’m not sure this solution will work for that. But… really… just use em instead!

Aside from the fact that both topics would put the average blog reader to sleep before the end of the first…

OK, now that they’re asleep, let’s talk. Throughout most of my career, open source software and Microsoft’s (or, really, any software behemoth’s) enterprise “solutions” have seemed diametrically opposed. But the more I think about the situation, I begin to find some startling similarities, at least in their implementation (and reasons for said implementation), if not in their actual structure and licensing.

If you’re the one person (besides me) who’s spent any significant amount of time reading this blog, you probably know two things: 1) I don’t like Microsoft, and 2) I don’t like Drupal. So these are the objects of my scorn in today’s post as well, although the problems I’m describing can be generalized, I think, to the broader sectors of the software industry that they represent.

When I worked in the corporate world, I resented Microsoft’s dominance across the board from operating systems to desktop software to enterprise systems. It just seemed that most of their tools weren’t really that good, and eventually I began to realize that the reason they were successful was that Microsoft’s customers were not the end users, but rather the IT managers who made purchasing decisions. These decisions were largely based on their own knowledge and experience with Microsoft’s software (to the detriment of other, possibly superior options), but also (I believe cynically) to preserve their own jobs and those of their staffs. Microsoft’s systems require(d?) constant maintenance and support. Not only did this mean bigger IT staffs on the corporate payroll, but it meant lots of highly paid “consulting” firms whose sole job was to promote and then support the sales and implementation of Microsoft products.

In the indie developer world, where I now reside, the culture and software platforms are different, but perhaps not as different as they seem. Apple’s computers dominate the desktops in small studios, and the tabletops in coffeehouses where freelancers can frequently be spotted hunched over their MacBooks hard at work while sipping lattes and meeting (usually a little too loudly) with clients. And open source software dominates at the server level.

But just like Microsoft’s platforms, I think most open source software just isn’t really very good. And the problem, once again, is the customer (or… well… whatever you call the person who makes the decisions when selecting a free product). It seems that the end user experience is rarely given much priority when most open source software is being designed and developed. Part of the problem is a lack of direct contact between the development teams and those end users (or, to be honest, even between the geographically scattered members of the development teams themselves). Devs don’t really know what end users want or need. They only know what they want or need, along with what’s been submitted to their bug trackers.

It’s not that these devs are bad people, or bad at what they do. There’s just a disconnect between coder and user, and as a result the goal of building good software isn’t met.

So, why do independent developers still use tools that are not really the best for their clients? Again, cynically, I wonder sometimes if job security isn’t a factor. It’s a lot easier to build something that works, but that requires indefinite, ongoing attention and support, than to build something that is flawless, that you can hand off to your client and never touch again. It’s easier… and it provides built-in job security.

Now, I’m not perfect, and I’m not above all of this. There is no such thing as flawless software, and I have ongoing support contracts with some of my bigger clients. But I’m proud to say that’s mostly because I’m constantly building new sites for them, or building functional enhancements onto the sites they already have, rather than doing endless bug fixes and technical support because the tools I’ve sold them are too confusing or simply don’t work right. Sure, the bug fixes and tech support do happen. But the tools — primarily WordPress and cms34, my own CMS — are built much more with the end user in mind, and have managed to avoid the pitfalls that mean a guaranteed job for me at the expense of a mediocre user experience for my clients.

That’s harder, and riskier. But it’s better. I’m delivering a higher quality product to the clients, and I’m keeping my own work interesting and moving forward.

The new design is here! About a week ago I revealed on Tumblr that I was working on a new logo for the blog. And now I’ve mustered the energy to do the bare minimum to my CSS to implement what can be called a “redesign.” Enjoy!

I’ve assembled a lot of IKEA furniture in my life, and along the way I’ve learned a few things, such as:

• Every piece of IKEA furniture comes with an identical Allen wrench, which you will only ever use to assemble that piece of furniture, and which will forever after gather dust in a drawer in your basement with all of the other identical Allen wrenches you’ve acquired at IKEA.
• A lot of stuff that looks like wood is actually a woodgrain pattern printed on plastic-coated paper, wrapped around a block of glued-together sawdust.
• Every piece of IKEA furniture will take two hours to assemble, no matter how large or small, or how many separate pieces it contains.
• Assembly might take slightly less time if you possess a Ph.D in archaeology with a special emphasis in either Egyptian or Mayan hieroglyphics.
• You will almost always realize 2/3 of the way through the process that you are doing it backwards.
• It never gets any easier.

Those universal hieroglyphic assembly instructions are, along with the ubiquitous Allen wrench and product names featuring umlauts or o’s with slashes through them, the most easily mocked symbol of IKEA. The pictures are often inscrutable, and the overall impression overwhelming. More than once I have felt compelled simply to curl up in the corner of the room and weep silently.

But written assembly instructions (from other companies, of course) are often far, far worse. If I can’t make sense of a diagram showing exactly how the parts fit together, how am I possibly supposed to understand written instructions along the lines of “insert the ball socket assembly into the reverse threaded wall mount bracket and affix with the supplied 8mm Torx screws and self-locking bushings”? (OK, I just made that up, but it sounds real, doesn’t it? Wait, what are you doing over there in the corner?)

And therein lies the problem: there is a great mental chasm between instructions and understanding. It doesn’t matter what form the instructions take: written, visual, verbal, semaphore. Whether you approach them in an unthinking, just-get-it-done, “paint by numbers” fashion, or you attempt to read and absorb them all before beginning, instructions can only communicate so much.

Recently I attempted to assemble and install a curtain wire system from IKEA, for the purpose of hanging posters from bulldog clips at the new Room 34 studio. The instructions supplied with the curtain wire were some of the most panic-inducing I’ve ever seen from IKEA, and that’s saying something.

The first two times I tried to put this thing together, I just gave up. Then I decided not even to bother with the instructions. Instead, I closely examined the various parts, until I came to my own understanding of how they fit together, and how it all attached to the wall. From that point, I was able to refer back to the instructions in a new way, as a reminder of my own thought processes, rather than as a bizarre alien communication from some distant Hömwørld.

I’ve been in IKEA’s shoes, though. Not literally. I don’t think they sell shoes, although I have seen fuzzy slippers there in a big wire bin for 99 cents a pair. But I have had to prepare instructions myself, and to lead training sessions where I attempt to communicate to my clients how to use web applications I have developed for them. It’s a challenge.

How much information is too much; how much is too little? What is the right information to convey, and what can they do without? Is it better to provide a broad foundation of knowledge or a targeted “cheat sheet” of most commonly used tasks? How do I stop instructing people and help them to understand?

I don’t have the answers. I’m still exploring. In my own experience, it’s direct, hands-on activities that are directly applicable to solving real-world problems that best allow me to develop my own unique understanding of how a system works. But it can be incredibly difficult and time-consuming as an instructor to develop suitable training materials and create an environment where that type of learning can take place.

Every field of human endeavor has its experts: those individuals who, through the right combination of talent, practice, and experience, acquire the highest levels of knowledge and skill within that field.

It is also one of the most basic observations about life and learning that the more you know, the more you realize you don’t know. As such, those who know the most are also (often) the most keenly aware of their own limitations, and are therefore the least likely to comfortably inhabit the identity of “expert.”

And yet, plenty of people proudly inflate their own status to that level, be they charlatans seeking unearned power and influence, or earnest practitioners of lesser abilities, who are simply benignly unaware of their own limitations (if such ignorance can truly be benign). It doesn’t help that we live in a world of “resumé inflation”, where everyone is an expert in everything, simply by virtue of putting those words on a piece of paper.

Of course there are also the occasional “true” experts who act as provocateurs — or simply have raging egos — who may be aware not only of their own limitations, but also of the even more extreme limitations of everyone else around them, and who leverage that knowledge for greater personal gain. But we have another word for these people. (Assholes.)

The challenge then is this: how do we identify those on whom we can most rely to share their “expertise”, if the true expert refuses the label and the self-identified expert is anything but?

I think the answer is simple: we find experts by the admiration of their peers.

Unless they’re all assholes too.

A note about the photo above: That’s Pete Prodoehl, a guy I don’t know much about but whose website I’ve long been aware of, and who does not appear to self-identify as an expert (except in the seemingly tongue-in-cheek way of this photo). But I found the photo on a post on a douchey motivational website for aspiring entrepreneurs, encouraging “expert” self-identification, while not bothering to identify, credit, or link to Pete’s website. Take all of this as you will.