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!

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.

• 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.

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.

But one place I always get snagged with CSS is in using the :first-child pseudoclass. The idea behind :first-child is that you can apply different styles to the first child element inside a parent element than for the rest of the instances of that child element inside the same parent.

A way I end up wanting to use it a lot is to give the first child different margins than the rest. Maybe most of them need margin-top: 2em; for instance, but I want the first one to be flush to the top of the parent by using margin-top: 0; to override the default margin.

The full CSS might end up looking like this:

div>h2 { margin-top: 2em; }
div>h2:first-child { margin-top: 0; }

And then that would be put together with some HTML like this:

<div id="content">

<h2>First header</h2>
<p>This is the first paragraph!</p>

<h2>Second header</h2>
<p>And, surprise! This is the second paragraph!</p>

</div>

So far, so good. The problem is, what if you stick something else into the <div> before the first <h2> that isn’t another <h2>? Say, something like this:

<div id="content">

<div class="floating_sidebar">This should be floating to
the right of the content.</div>

<h2>First header</h2>
<p>This is the first paragraph!</p>

<h2>Second header</h2>
<p>And, surprise! This is the second paragraph!</p>

</div>

You may have guessed at this point that I’m not describing a hypothetical situation here. This is a stripped-down version of exactly what I’m building right now. The problem is, now the first <h2> is no longer the first child element of the parent <div> overall, so the :first-child CSS gets ignored.

True, it’s not the first child element, altogether, inside the parent. But it is the first <h2> child inside the parent. I can understand how, in other circumstances — say, if the inserted <div> wasn’t a float — you’d want the h2:first-child not to apply here. But in general it seems to me that if you’re specifying a tag with your :first-child, it should only matter that it’s the first tag of that type under the parent, even if there are other different tags before it.

I guess the real solution here would be to create another pseudo-class that does what I want. Now I just need to convince the standards folks and the browser makers to do that.

Note: The sample HTML was kind of a mess when I originally posted this. That’s what happens when you write a blog post in a hurry before rushing out the door for a meeting. It has now been corrected, and I made some other edits for clarity while I was at it.

Gruber responds:

It’s not that Android is suddenly in a lot of trouble — it’s that a lot of people are suddenly realizing that Android has been in trouble all along.

Exactly. But he doesn’t go on to mention why it’s been in trouble all along (though as I recall, he has in the past). I’ve seen plenty of reports, like this one from comScore that iPhones use WiFi networks significantly more than Android phones in the U.S. and U.K. This is one way of measuring the qualitative differences in how people use iPhones compared to how they use Android phones. You could also talk about app revenue, for instance.

All of these measurements and analysis revolve around one clear conclusion, especially when one considers how people end up walking out of a store with either an iPhone or an Android phone. Carriers are pushing Android because they can control the experience more. They’re giving away Android phones as stock upgrade models when customers’ contracts come up. People who don’t even care about owning a “smartphone” are bringing home Android phones because that’s just what the sales rep at the store recommended.

Android is in trouble because a lot of its users (the majority? the vast majority?) are just using it as a phone. It’s a commodity. A lot of the people buying it don’t really know or care what it is, and will never actively use its full potential. It’s just a phone. It may be capable of much more, but if it’s not being used for more, what difference does that make?

People who go into a store wanting to purchase a smartphone predominantly choose the iPhone. Not all of them, of course. Tech-savvy people do choose other smartphone platforms, including Android, especially those who want to tinker with the system. But the rest take whatever they are told to buy by their carriers’ sales reps.

This is the biggest reason Android tablets haven’t taken off, and it’s been discussed too. There’s a built-in market for the apathetic purchase of an Android smartphone. But no one (well, I hope) is walking into a cellular carrier’s store and saying “I want a tablet. What tablet do you recommend?” People who want a tablet don’t just want a tablet; overwhelmingly they want an iPad. Most people who don’t want an iPad don’t want a tablet at all. (Almost) everybody needs a phone.

The problem for the carriers, and the reason they’ve been promoting Android, has typically been that Apple retains too much control (from the carriers’ perspective) over the iPhone. That’s not likely to change, but with Windows Phone, suddenly the carriers have other options. Microsoft is definitely keeping a tighter rein on Windows Phone than Google does with Android, but with Windows Phone, the carriers still have options they don’t get with the iPhone. (Not that this lack of control has prevented them from selling millions of the things.)

If Verizon is serious about pushing Windows Phone (along with the fact that they still sell huge numbers of iPhones), then we’ll soon begin to see just how Android was, as Gruber says, in trouble all along. The success it has achieved to date was largely dependent upon carriers pushing it on unsuspecting or indifferent customers. If they stop doing that…

Well, this happened:

That would be the reception area at the front of the new Room 34 Creative Services studio. The business has moved out of my house and into a real storefront space. It’s been a lot of work (plus, I’ve had a lot of work to do anyway), so the blog has suffered. Never fear, I’m still here!

More to come…

I’ve been adapting my designs for the Retina Display on the iPhone 4/4S for a while now, but it’s easy enough to build a responsive web design that just shrinks down large desktop website images to half their size for display on a tiny iPhone screen. Making an essentially desktop-sized display support high-resolution graphics is a whole other story, and even though I knew (or presumed, along with the rest of the world) that a Retina iPad was coming, I think some small part of me was still in denial about what it would mean for web design.

Well, that future is here. Sure, most of the world is not browsing the web on a Retina Display iPad. But if you think the HD revolution ends there, think again. It’s just getting started. I’m about to enter the implementation phase on a handful of big web projects over the next month. Accommodating the new iPad’s display is going to be one of my top tasks.

I’ve been thinking for the past month or so that I was going to need to address this, and I’ve made the decision that, moving forward, on any site that has responsive web design as a component (which will probably be all sites I do), full-size “Retina Display” graphics are essential.

I posted a comment on Joshua Johnson’s post, where I noted that “Retina” (or, to avoid using Apple’s marketing term, “HD web”) graphics don’t really need to be 326 pixels per inch (ppi), the iPhone 4/4S’s resolution, or even 264 ppi, the new iPad’s resolution.

The standard practice with web images has always been to render them at 72 ppi, but the fact is, browsers don’t care what resolution an image is set to. A pixel is a pixel, and web images get displayed at the screen’s native resolution (unless, of course, you resize the image dynamically in the browser using HTML dimension attributes or CSS). The Retina Display approach Apple uses is to simply double the resolution (quadrupling the number of pixels). Web images by default get “pixel-doubled” in this scenario, displaying at the same relative size as they would if the iPad still had a low-res display, but appearing pixilated or blurry as a result.

You don’t need to render your images at 264 ppi for display on the new iPad. In fact, you can leave the resolution at 72 ppi, because the browser still doesn’t care. (Well, maybe it does; I haven’t actually had an opportunity to test it, but I strongly suspect the answer is no.) You just need to make the pixel dimensions of the image twice what they were before. In fact, even if you do change the resolution, you still need to double the dimensions. That’s the key.

After mulling all of this over for the past week, I’ve decided I’m going to have to get a new iPad (what a hardship, I know). I could technically do this work without it, but I think it’s important to be able to see what I’m producing, if for no other reason than to remind myself how important it is.

This is going to be an ongoing process, and because web design (or, more accurately, web design implementation — I usually work with designers who produce the initial UI in Illustrator or Photoshop) is only one part of my job, I can’t give it my undivided attention. But it’s something I am preparing now to immerse myself in as fully as possible. From now on, this is just how I do things. And with that in mind, there are some key points to consider:

1. Some images are more important to represent high-res than others. Logos, absolutely, 100%. Design elements that are on all pages (backgrounds, borders, navigation) come next. One-off photos are not as critical, but probably still are if they’re on the home page. But consider the next point as well.

2. Bandwidth is a concern. I’ve been somewhat dismissive of this up to now, as I’ve been focusing on high-res logos for the iPhone’s Retina Display — it can just take the regular web images and show them at half size to achieve high-res — but if you’re suddenly talking about downloading 4 or 5 high-res photos for a home page slideshow, it’s going to be a problem. Making users with standard resolution download unnecessarily large images is bad; making iPad users eat up their 4G data plan downloading your perfect-looking photos is bad too. Most of the attention paid to bandwidth in this discussion that I’ve seen so far has focused on the former, but both need to be addressed.

3. CSS and SVG. Joshua Johnson talks about this in his post. If we can render elements using CSS instead of images (things like curved corners, gradients, shadows, etc.), we should do that. More complex vector graphics can be displayed in SVG. All modern browsers now (finally) support SVG. Up to now it’s been a cool but essentially useless technology, due to lack of widespread support. But IE8 and earlier don’t support SVG, so if those browsers matter (and unfortunately they probably still do), you need a backup plan.

It is an exciting time to be working in web design and development. More and more, the challenges center around adapting your techniques to take advantage of cool new features and capabilities, not accommodating the limitations of crap browsers. But they’re still challenges, and we’re just beginning to discover their depth, along with their solutions.

Update: Over at Daring Fireball, John Gruber just linked to Duncan Davidson’s post detailing an issue with WebKit (the rendering engine inside Safari) automatically scaling down images above a certain size, specifically over 2 megapixels. Looks like sending huge, high-res images to the new iPad might present even more challenges than the ones I’d been considering.

P.S. I did get that new iPad, and Duncan’s demo of an 1800-pixel JPEG on the iPad’s Retina Display is truly impressive. But what I find really interesting about it is that the 1800-pixel version of the photo looks better than the 900-pixel version even on a regular computer display… because, as I’ve observed, WebKit downscales images better than Photoshop does.

Knowing what I now know, I would not be likely to recommend OpenX to any client. In 2008, however, I was new to the world of ad server software, and took someone else’s recommendation to go with OpenX. Much has changed since 2008, but — for better or worse, and I’m leaning toward worse, mainly because I’ve come to realize how bad OpenX is, and that there’s probably not any better alternative — that client is still relying on OpenX for their web ads.

The intervening years have brought a handful of challenges where OpenX is concerned. Besides its excessive complexity (143 data tables! most of which by this point either contain 0 records or over 2 million!) and inscrutable structure (why are statistics a “plugin”? and why are the built-in plugins not actually installed automatically?), it is notoriously susceptible to security exploits.

Such was the case about a year ago, the first time I ran into the problem of missing statistics, when I ran the version 2.8.8 upgrade to patch a hacked installation.

This time around, I had only myself to blame. An errant maintenance script in my own CMS had inadvertently deleted all of the files in the openx directory, effectively wiping out OpenX, though thankfully leaving the precious data tables untouched. I had an outdated backup that contained most of the ad assets, and the client was able to provide replacements for the newer ones, so within the same day we were back up and running, serving ads on the website again.

Except… no statistics.

My second mistake was that I hadn’t made notes of the solution I had eventually discovered the first time we ran into this problem, so I was forced to spend several days once again trying in vain to hunt down the solution on Google. Today I finally did, so I would like to share it here, with the deepest gratitude to its author, Frederik Schøning.

Before I detail precisely what did, at long last, restore statistics to our OpenX installation, I want to describe a few of the things I did before that, which did not solve the problem, but which may have been critical to my ultimate success. (I’ve learned over the years that, when debugging, one problem may obscure another, and that there’s rarely only one thing wrong.)

First, installation itself. For quite a while, OpenX required you to jump through a number of frustrating hoops just to get the actual installer. Recently, they’ve cut the crap and provided a direct download link. I ran the installation, snagging briefly on the fact that my data tables already existed. The installer sort of accounts for this situation, however, allowing you to upgrade the existing data tables instead of creating a brand new database. (This, I believe, is where my problems with statistics began. More on that in a minute.)

After installation, I went through several iterations of repairing data tables, fixing file permissions, copying files from my old installation (be sure to keep that around, if possible!), etc. Lather, rinse, repeat. I spent a lot of time in the Maintenance section of the OpenX admin system, trying to get the plugins to stop reporting errors.

Here’s a key problem: statistics in OpenX require the openXDeliveryLog plugin (possibly among others). Although it comes with the installer, it is not installed by default. There are empty folders under plugins where the plugins should be. Instead, the plugins are all zipped, inside the etc/plugins directory. Fortunately, when running OpenX as the administrator account, you can go to the Plugins tab and install them. Unfortunately, they still probably won’t stop reporting errors, because not all of the files end up in the right places. I had to extract openXDeliveryLog.zip and manually place the files for the deliveryDataPrepare plugin, a prerequisite for openXDeliveryLog.

A few more lather-rinse-repeat cycles and I got the plugins to stop reporting errors. But I still wasn’t getting stats. That’s when I discovered Frederik Schøning’s blog post, and was reminded that last time this happened, the problem was a second administrator account in the database. As he suggests, last time I was convinced this happened when the system got hacked. This time, I’m pretty sure there was no hack; the duplicate administrator account seems to have been created while I was running the installation/upgrade process (as hinted at above).

If this is the case, then the OpenX installer is broken on upgrade, and it creates a situation that breaks statistics reporting. Fortunately, it’s pretty easy, if you have direct database access, to remove the duplicate administrator account. Check the ox_accounts table for more than one record with account_type set as ADMIN:

SELECT * FROM `ox_accounts` WHERE `account_type` = 'ADMIN';

One of these should have account_id equal to 1 since it’s the first account you create. Delete the other:

DELETE FROM `ox_accounts` WHERE `account_type` = 'ADMIN' AND `account_id` != 1;

(Be sure to change 1 in that query to whatever the lower numbered account ID is, if it’s not 1. Or you could make the last bit = 80 or whatever the higher numbered account ID is. In my case, it was 80, but I suspect that will vary.)

Next, you need to make the proper admin account the system’s configured admin account again. That’s in the ox_application_variable table. As per Frederik Schøning:

UPDATE ox_application_variable SET `value` = 1 WHERE `name` = 'admin_account_id';

(Again, if your correct admin account’s ID is not 1, change the 1 to the appropriate value.)

As soon as I made these changes in the database, statistics were instantly working again. And I could stop thinking about OpenX… until the next crisis hits.

But before I stop thinking about it entirely, I want to pose a couple of questions to ponder:

1. Why, when updating an existing installation, does OpenX create a new administrator account?

2. Why are broken statistics the only (readily apparent) problem resulting from the presence of that second administrator account?

The most likely (and boring) suggestion is that they’ll start paying dividends to their shareholders. Bolder predictions include buying one of the cellular carriers (can you imagine Apple owning AT&T?) or possibly even Google. (OK, I don’t think I’ve actually seen that one, but I think they could do it.) Or, if they were Dr. Evil, they could hold the entire world ransom.

But let’s have a little fun, shall we? Here are some other things they could buy with $100 billion:

• A large supreme pizza for every person on earth
• A new stadium or arena for every team in the NFL, MLB, NBA and NHL
• The entire GDP of Morocco
• 500,000,000 iPod touches (“iPods touch”?)
• Over 41,000 of the most expensive car on earth
• 6,200,000 of the most popular car

Or, they could just give every person in America $320.93. Or pay off 0.64% of the national debt.

My Subaru Outback is due for service. Time to schedule an appointment. This is the kind of thing I just love to do online. No human interaction necessary!

Unfortunately, my dealership (who shall remain nameless, although I am happy to tell you that their shoddy website experience, which I am about to detail for you, was delivered by auto dealership web development behemoth Dealer.com) has not made the online scheduling option easy. And by “not easy,” I mean “practically impossible.”

First of all, for no good reason, the scheduling interface is built 100% in Flash. I’m pretty sure this scheduling system predates the iPhone, and Flash was at the time a de facto standard, but I’ve been building web applications since 1999 and there was never a time when it made sense to build a system like this in Flash. I deliberately don’t have Flash installed, except the version built into Chrome, so I couldn’t even load it in my browser of choice (Safari). Strike one.

I don’t think so.

Switching over to Chrome, I was able to go through most of the appointment scheduling process, picking the service I needed done, etc., until I got to the point of actually scheduling it, where I was stuck in an endless loop of picking days that were marked “available” on a little calendar overlay, only to get an error message stating “Not available due to shop capacity.” Over and over.

All but giving up, I spotted a curious item at the bottom of the page:

Ooh, this looks promising! Except… wait. How can clicking a link on my computer download an app to my smartphone? Maybe I should visit this site on my iPhone and then tap the link. Except… wait again. This part of the interface is in Flash, so I wouldn’t even see the link on my iPhone. So, what happens if I click it, anyway?

Are you kidding me? We are now at a place where I am interacting with a Flash-based web app on my computer, having it send to my phone an SMS message containing a link to the dealership’s mobile website. I’d even prefer a QR code over this convoluted mess. Strike two.

This is not how you do the Internet.

So I just decided to go over to my iPhone and try loading their website directly. It “smartly” (using the term loosely) redirected automatically to a separate iPhone-optimized version of the site, which I can only assume must be the mobile site the SMS would have linked to. (That is a reasonable assumption, right? We shall see.)

Here’s what I found when I navigated through the iPhone-optimized site to the service department’s page:

That “Service” button calls the service department. The “Contact Us” button is a link to a general-purpose email form. There are no other options.

“The mobile site will let you create, modify, and cancel appointments.” That’s what the SMS form promised. I decided (solely for the purpose of this blog post at this point) to fill out that form, but have the link emailed to me rather than sent as an SMS message. Not surprisingly, the email ended up in my junk folder. Also not surprisingly, the link goes to a different site than the version my iPhone was automatically redirected to when I tried to load the dealership’s main website. (So this is three separate websites they have now.)

I loaded this other mobile site on my iPhone, and it works!

Except, no, wait… it doesn’t:

Except, no, wait again… despite that weird error message, it actually does work:

(How many “except waits” is that now?)

But since it apparently only lets you edit existing appointments, not make new ones, I guess it really doesn’t work, after all. Also, don’t ask me why the iPhone version of the site doesn’t even have a link over to this version, but I guess ultimately it doesn’t matter anyway. Strike three. And four, five and six. In fact, let’s just call the game. And I’ll call the dealership.

Conclusions

What have we learned here? Aside from the fact that I am willing to spend far more time writing a blog rant about this problem than I am just calling to schedule an appointment over the phone, I hope I have impressed the value of web standards. If this site’s interface had been built in simple HTML and JavaScript, instead of Flash, which I can tell you is 100% possible — there is absolutely nothing in the interface functionally, and not even really anything in terms of the design or interaction, that could not have been done with HTML, CSS and JavaScript, even several years ago — then it would have worked fine in Safari without Flash, and it would work on my iPhone.

There has always been a lot of temptation to use Flash to do things that couldn’t be done with web standards, especially when the standards weren’t up to Flash’s capabilities. But succumbing to that temptation led to two trends that were profoundly harmful to the open web, and the effects of which we are — and I am literally — still experiencing today.

Bad UX as standard practice

First, since the sky is the limit when designing Flash interfaces, it created a feedback loop where designers took excessive liberties in experimenting with how basic interface elements like scrollbars and buttons should look and function. Then, project stakeholders who didn’t have the requisite background to make informed UX design decisions made demands that further pushed how these elements look and function. And since Flash had so few constraints on interface design, designers could accommodate those expectations, and the situation spiraled out of control.

This problem is not exclusive to Flash, of course. These days CSS and JavaScript offer tremendous potential for messing with standard UX conventions, and I’ve gotten myself into trouble with this on occasion. Customized scrollbars, fixed-position content, etc. Always remember, just because you can do something doesn’t mean you should. Things in the future will change in ways you can’t anticipate. Those changes are likely to accommodate existing standards, but not your customizations, no matter how brilliant they may be.

Flash as an industry

Second, as Flash grew in popularity it created an entire industry of Flash developers. Suddenly you had people whose livelihood depended upon building interfaces in Flash, regardless of whether or not Flash was really the right tool for the job. And as someone who has always favored open web standards, my perspective is that Flash is only the right tool for the job when it’s the only tool for the job. Even if standards couldn’t do something in quite as… ah-hem… “flashy” a way, if they could do it at all they should be chosen over Flash. I recognize this is a bit subjective, but one thing I can say about it with objectivity is that favoring web standards over Flash for a system like the one I’m describing here would almost certainly have obviated all of the problems I encountered this morning.

A metaphorical lesson to all technology workers: when your only tool is a hammer, every problem looks like a nail. Diversify your toolbox. It will serve your clients better by ensuring that you’re using the best tool for the job, not just the tool you know best. And it will serve your career better by not limiting your job options.

Future-proofing the web

There’s an even bigger reason now that having built this kind of system then using web standards instead of Flash would’ve been a good idea. If this site’s forms had been built with semantic HTML, it would be a comparatively trivial task to build new CSS with responsive web design techniques, allowing a single site to deliver the complete user experience on any device, rather than having to pay for and build three separate, wholly inconsistent, and all inadequate websites. By supporting and adhering to standards in the past, we could (and did) build websites that still work fine today. And by continuing to adhere to standards today, we can build websites that will still work fine tomorrow, even if we don’t really know what tomorrow’s devices will look like, or how we will interact with them.

A few of the details miss the mark: I taught myself BASIC, not Pascal (although I did try to make sense of Pascal while tinkering with my uncle’s IBM 5150 when I was 8), and I specialize in PHP, not Perl (distant cousins). But the lower left corner pretty much covers that, and also explains away the fact that I am married, for good measure.

Going back earlier in time, it even captures (and I’m being quite serious here) what might be the ultimate pivot point in my life: being massively obsessed with Atari but not getting into the next-generation game systems that followed it. It wasn’t for lack of interest; my parents simply refused to buy me an NES, and got me a Tandy computer (not a TRS-80, but close enough) instead. So thanks, Mom and Dad, for making a decision 25 years ago that set me on the path of lucrative uses of computers, instead of fantasy baseball and MMORPGs.

Here’s my version of the flowchart, with my path highlighted in yellow. Click the image below to see the full version, and be sure to check out the source, Taschen’s massive tome of infographics, while your at it.

Each morning I start the day by perusing the latest on Twitter and my RSS feeds, and I almost always find something interesting to read. But today was more interesting than most, and simply retweeting the links didn’t seem adequate. Also, some of these links may become topics for discussion on this week’s episode of The Undisciplined Room, so this is your homework.

First up, we have a post on The Verge discussing homeless hotspots at SXSW. This is a topic I’ve been reading about for the past few days, but this post was the first that made me think beyond my gut reaction that this was shameless exploitation.

Next, with a HT to Daring Fireball, and via Marco Arment, we have a look at Curator’s Code and why it’s a bad idea. The evidence has been mounting for me that Maria Popova’s 15 minutes of (borrowed) fame are almost over (especially when I’m reminded of her love of Ayn Rand and Malcolm Gladwell), and Marco helps solidify that thought.

Then we have type designer Mark Simonson (who designed the Proxima Nova font that I use in the Room 34 logo and branding materials) discussing font anachronisms in The Artist. As much as I enjoyed The Artist, issues with the fonts it used (especially straight quotes, and the fact that it used fonts in a lot of places where hand lettering would have been more appropriate) even distracted me, so I can’t imagine what it must be like for someone like Mark Simonson or Chank Diesel. (Full disclosure: I did development work on Chank’s mobile website.)

And finally… Chicago musician and multi-talent Joshua Wentz has just announced the release of the Side 2 EP by Absinthe and the Dirty Floors, one of the many musical projects with which he’s involved. He’s also made a video for each song on the EP, like this:

Over the years I read a lot of Seuss books at the school library, but none made such an impression, both immediate and lasting, as The Lorax. I loved it like nothing else, and I still do. I loved the book, and I loved the 1972 animated TV special, which not only captured and expanded upon the spirit of the book, but did so with the kind of funky music that only could have appeared in a children’s television program in that decade.

Therefore, it was almost a given that I would hate the new CGI animated feature film adaptation. But I was not prepared for how much I would hate it. OK, the notorious Mazda commercial gave me a clue, but I had been lulled since first staring gape-jawed in disbelief at the audacity of a car company claiming that an SUV with a standard combustion engine was “Truffula tree approved” into thinking that maybe the movie wouldn’t be so bad, after all.

Oh, how wrong I was. I was wrong — as were the filmmakers — in so many ways that I can barely begin to catalog them.

Fortunately I don’t have to. In his Vulture review, The Badness of The Lorax Is a Shock, David Edelstein says it all for me.

Almost.

We disagree over whether the source material is any good, apparently, and Edelstein seems to like most the part of the movie I hate most — the tacked on conventional family movie chase sequence in the final 20 minutes. I found it so gratuitous and unbearable (and frankly just plain boring) that I excused myself to go to the bathroom, but I really just wanted to get the hell out of the theater so I didn’t have to witness any further abomination.

Please. Do not see this movie. Read the book. Or watch the 1972 TV special four times instead.

Here’s some more.

I’m not a hardcore runner. I’ve rarely, if ever, gotten a “runner’s high,” but I think it happened today, about 2 miles into my run, while listening to “Raconte-moi une histoire.” Is the fact that the song’s lyrics are spoken word, by a child, describing (I think) psychoactive toads? Perhaps. Whatever it was, the music was a perfect tempo for me to lock into, and as the music built up, I lost all sense of physical limitations. My limbs were tingling and I felt like I was floating up off the ground.

Then as soon as the music faded and I rounded a corner, I crashed back to earth and was slogging along again, but at least I kept at it.

Anyway, there’s no official video for “Raconte-moi une histoire,” but here’s a live performance of “Midnight City,” the big single from Hurry Up, We’re Dreaming. It first aired on Carson Daly’s extremely-late-night show. Enjoy!

Rod Hilton has devised an ingenious viewing order for the complete Star Wars saga. OK, actually not the complete saga, but what could come to be viewed as the definitive saga. He makes a compelling case for shuffling up the order a bit, and for removing The Phantom Menace entirely.

The ultimate sequence he devises is as follows:

• Episode IV: A New Hope (or, more properly, Star Wars)
• Episode V: The Empire Strikes Back
• Episode II: Attack of the Clones
• Episode III: Revenge of the Sith
• Episode VI: Return of the Jedi

I’ll leave it to Hilton to explain in detail how he arrived at this solution, along with its (mostly) pros and (few, minor) cons. The whole post is definitely worth reading and I look forward to watching the “complete” saga in this order soon.

Spoiler alert, I guess: This is the film that plays a central role in Martin Scorsese’s brilliant 2011 film Hugo. It is great to be able to see the film in its entirety, especially accompanied by Air’s brilliant soundtrack.

An excerpt is available on YouTube:

I purchased the album, which includes the full-length (15-minute) video, on iTunes, but it’s also available as a CD/DVD set from Amazon. I’m considering buying the CD/DVD set anyway, as the music is that good and the download version of the video contains some annoying compression artifacts (horizontal stripes that appear whenever something fast-moving appears, which I have to assume were a result of the process of compressing the video for download, and are not inherent to the version on the DVD).

I watched the full video last night, and found myself more profoundly moved than I would have expected from the film’s light and fantastical story. I’m not sure if it was because the hand-coloring brought the film to life in a way that black-and-white couldn’t, but there were two thoughts I just couldn’t shake as I watched it, which I don’t normally think about when I’m watching very old film footage:

1. Everyone involved with this film is dead.

This is not a profound revelation. But again, I think the color brings the film to life in a unique way. There’s nothing realistic about the color, so it’s not seeing people in color that makes it more vivid. I think it’s the simple fact that it’s in color, and the way it was colorized. That the creators of the film put in the incredible effort of hand-coloring each frame of the film. That they imbued it with their personality. And, beyond all of this, that it conveys a sense of frivolity and wonder that I don’t often associate with the early 1900s.

Grainy, black-and-white film of the era feels dark and dismal. Since that’s how we’re accustomed to seeing it, that time period, for me, exudes grit and grime, the ugliness of early, soot-choked industrial cities. This color, literally, casts these times in a new light, and brings out a joy and humor I would not have seen or felt otherwise.

2. We have learned so much about the universe in the last century.

It is obvious, I think, that Méliès was not attempting to create a realistic depiction of a journey to the moon, or of what people would find there. If Ben Kingsley’s portrayal of him in Hugo is accurate, his goal in filmmaking was to explore realms of fantasy, to bring dreams to life. And that’s just it: in 1902, the idea of traveling to the moon was pure fantasy. But just 67 years later, people actually walked on the moon for the first time. (And, 70 years later, possibly for the last.) The amount of scientific knowledge humanity gained during those intervening years is hard to comprehend, and as someone who was born after those final moon landings of 1972, it’s something that for me has always been and forever will be in the past. But for those who worked with Méliès on Le voyage dans la lune, it was still the distant future, one most if not all of them never even lived to see.

It is an amazing time to be alive. Not only to immerse ourselves in the technologies of now, but because we have unprecedented access to what it looked and felt like to be alive over 100 years ago, via the motion pictures of pioneers like Méliès. The restoration of the color version of Le voyage dans la lune is amazing, and it’s made even more wondrous by its pairing with some of the best music our era has to offer.

Fearing inefficient code in cms34 may be to blame, I spent a few days trying to optimize every last bit of code that I could, which did make a slight improvement, but didn’t solve the problem.

Then I spent a few more days poring over the Apache configuration, trying to optimize the prefork settings and turning off unnecessary modules. Still, to no avail, although getting those prefork settings optimized, and thus getting Apache under control, did allow me to notice that MySQL was consuming CPU like mad, which I had previously overlooked.

Hmmm… that got me thinking. I fired up phpMyAdmin and took a look at the running processes. Much to my surprise, almost every MySQL process was devoted to an abandoned phpBB forum. Within moments I realized the forum must be the source of the trouble, which was confirmed when I found that it had over 500,000 registered users and several million posts, almost all of which were spam.

As quickly as I discovered the problem, I was back in the Apache configuration, shutting down the forum. Then a quick restart of MySQL (and Apache, for good measure), and the sites were faster than I’ve seen them in months.

The moral of the story: if you have a web server that suddenly seems to be grinding to a halt, don’t spend days optimizing your code before first looking for an abandoned forum that’s been overrun by spammers.

As Grannell points out, there are arguments to the contrary, but I think what it all really comes down to is simple: People want your content. They will make a reasonable effort to obtain it legally, at a reasonable price. But when you build a wall around your content, by charging exorbitant prices, deliberately misunderstanding the concept of fair use by fighting format shifting, or simply making it unavailable altogether, a lot of people are going to find a way around that wall.

I don’t condone torrenting, nor do I participate in it. In that regard, I don’t know if I’m in the minority on the Internet or not. But I can understand why it happens. More importantly, I believe it would not be that difficult for content owners to eliminate, or at least diminsh to irrelevancy. They just need to try.

But trying means change. It means meeting content consumers halfway. First, it means recognizing them as potential customers, not as potential thieves.

Change can be hard to accept. But I just cannot comprehend how “big media” doesn’t recognize the potential here. Instead of fighting desperately to hang onto dwindling DVD and CD sales, there’s a huge potential market for online distribution. But it requires thinking differently. Prices may go down, but so will distribution costs, by a lot. Like, almost zero. Margins may be slimmer, but that can be more than made up for with volume.

Would making everything readily available online, legally, at a modest price, eliminate piracy? Probably not. But that’s not the right way to think about it. Every advancement in technology since the printing press has presented the risk of IP theft (though, granted, that’s a modern concept), but it has also presented far greater opportunity for those who aren’t afraid of it.

So, you can resent and sue your would-be customers. Or, you can respect and engage them. I think we’re all fed up with how things are working right now. Let’s be reasonable.

It’s been easy to forget it’s winter this year. Last winter we had two huge storms bury the area under a couple of feet of snow before Christmas, and we didn’t see grass again until sometime in March. As far as I know, this winter we haven’t even had a single snow emergency, and the few times we have gotten an inch or two of snow, it’s melted within a week.

What’s a snow emergency, you say? I’ll let Wikipedia explain. Suffice to say Minneapolis is the only city specifically mentioned in the article.

I’ve been meaning to find time to head over to that part of town and check this place out for a while, but I just discovered a number of photos of the inside posted on Instagram. It turns out they have their whole game list posted on their website, but just from looking at the pictures I was able to identify the following games:

Rampage, Centipede, Joust, Dig Dug, Donkey Kong, Q-Bert, Ms. Pac-Man, Galaga, Space Invaders, Asteroids, Mario Bros., Donkey Kong Jr., Track and Field, BurgerTime, Defender and Crystal Castles.

Yes… that’s pretty much perfect.

Therefore I’ve kept a healthy distance from Mac app developers’ criticisms of the ongoing “iOS-ification” of the Mac, specifically where the Mac App Store is concerned. I don’t use most of the iOS-like features in Mac OS X Lion, and probably won’t in Mountain Lion either, but I do use the Mac App Store, occasionally. I think it works pretty well. It’s actually gotten me to buy some apps — games mostly (of course), plus a couple of utilities like Space Gremlin (yes, that’s a utility, not a game) — for the Mac that I probably would neither have known about nor bothered to pay money for otherwise.

But there are some things that, as a power user, I recognize as problems with the Mac App Store, specifically concerning the “sandboxing” requirement that will take effect on March 1. Essentially, in order to be carried in the Mac App Store, an app cannot access the Mac’s file system except in very limited ways dictated by the OS. It’s a huge step towards making the Mac behave like iOS, which is mainly beneficial in two ways: it improves security by reining in potentially malicious applications, and it simplifies the user experience for novice computer users in a tried-and-true way.

It may be reasonable to question at least one, if not both, of those benefits however. Regarding the latter, I suspect that most would-be Mac owners who have too much difficulty understanding the Mac interface, and who would be better served by making the Mac more iOS-like, would really be better served by not buying a Mac at all, and just getting an iPad instead. Since Apple sold more iOS devices last year than all of the Macs it has sold, ever, that seems like a no-brainer. For a large and growing majority of its customers, Apple is the company that makes iPhones and iPads, not the company that makes Macs.

But it’s the former issue — the security-enhancing measure known as “sandboxing” — that is more troublesome for established Mac users like me. A lot of Mac apps need unfettered access to the file system to do what they do. Especially for those of us “power users” who write code — for the web or otherwise — we need applications that not only have full access to the file system, but that can even let us see “invisible” files. (I always have Mac OS X set to show invisible files, since I frequently need to work with .htaccess files, for instance. Did you know that any filename that begins with a period is automatically hidden by the OS by default? It’s an old Unix thing, designed to help keep users from accidentally deleting critical system files.)

A real Mac app developer has weighed in on the problems posed by the sandboxing requirement for his company’s app, SourceTree, and how, as a result, Atlassian has had to remove SourceTree from the Mac App Store.

Fortunately, unlike with iOS, the Mac App Store is not the only way to get applications onto your Mac, and I think it’s a reasonable assumption (but by no means guaranteed) that the Mac will always allow power users to do things the “old fashioned way” and install directly applications that do not conform to the App Store’s strict requirements.

But a look at the features of the upcoming Mountain Lion version of OS X gives pause. Clearly Apple wants to move the Mac more and more in an iOS direction, and clearly even beyond the growing sibling relationship between the two platforms, just on the Mac itself, Apple is putting a lot of effort into streamlining and simplifying things, making things on the Mac work, as Grubes said yesterday, “closer to how things should be rather than simply how they always have been.”

But how things “should” be is subjective, especially when it comes to what “real” applications on a “real” computer can reasonbly be expected by “power users” to be “able” to “do.” (Quotation marks indicate uncertainty.)

There’s been a lot of talk over the past few years about how we’re entering into a “post-PC” era. With the proliferation of smartphones and tablets (90-some percent of the latter being iPads, of course), new interaction methods and increasingly mobile-first web experiences, what is to become of the trusty old PC (Mac or Windows)? What surprises me most in all of this is that Apple and Microsoft are leading the charge to turn traditional computers into post-PC devices. Both Mac OS X Mountain Lion and Windows 8 are radically diverging from their traditional interfaces into new directions inspired by their mobile siblings.

In some ways this is an exciting and fascinating time. For about two decades now, Mac OS and Windows have been very similar, presenting nearly identical ways of interacting with computers. But iOS and Windows Phone (which is coming to Windows 8 as the Metro interface) are very different from each other. The next standard UI has not yet been established. We haven’t seen this kind of competition and variety since the early 1980s, before Microsoft’s desktop OS dominance was established.

But it’s not the early 1980s. We’re not living in a time of unprecedented invention and discovery. We have nearly 30 years of GUI-based computing experience under our collective belts, and the conventions of standard GUI interfaces (as represented mainly by Windows and Mac OS X) have become expectations of the “power users” who rely on them not just as an alternative form of entertainment while sitting on the couch in the evening, but to do real work — creative, technical, business-oriented work.

That’s not going to change overnight as February passes into March. And it may not change significantly in our lifetimes. But if Apple aggressively restricts what applications in the Mac App Store can do, in ways that prevents users from getting work done, while simultaneously pushing the Mac App Store as the primary (and eventually only) way to install applications on a Mac, they will effectively kill the Mac as a tool of creative professionals, which is pretty much the only thing that kept Apple alive through the ’90s in the first place. Sure, Apple doesn’t really need us now (and it would still have us anyway… I’m not giving up my iPhone anytime soon), but making the Mac too much like iOS doesn’t necessarily make it better. It just makes it… unnecessary.