Web standards: a Win-Win-Win situation

Today is the fourth annual “Blue Beanie Day,” a tradition established by the father of web standards, Jeffrey Zeldman.

What are web standards? Simply put, they’re awesome. But seriously… the goal of web standards is to establish a set of best practices for web designers and developers, and a set of open, shared languages and tools for building websites and displaying them in a consistent manner.

At the heart of the modern web standards movement are a set of three core languages: HTML5, for organizing and structuring content; CSS3, for designing the presentation of that content; and JavaScript, for providing rich interaction with that content.

HTML5, CSS3, and JavaScript are all open standards. The specifications are published for anyone to see; they’re open and evolving, for anyone to contribute to; and they’re freely available for anyone to build an application for rendering content delivered via these languages (in common parlance, a web browser, but we’re starting to see “web” content appearing in all sorts of applications for computers and mobile devices these days).

But why are these three web standards so great? Because they create a win-win-win situation:

A win for web designers/developers. By establishing a common set of tools that are open and free to anyone, web designers and developers can get started with no barriers to entry. Plus, by standardizing these tools, the same skills can be applied anywhere a website is being built. And as web browser makers adopt these standards, the last 15 years’ worth of browser-to-browser inconsistency will fade. Our job is made easier, we can get more done in less time, and, with powerful frameworks like jQuery built on top of these standards, this power to do more with less will grow exponentially.

A win for site owners. If you’re paying to build a website, you want to know you’re spending your money wisely. You want your investment to last, and you want to make sure everyone who wants to access your site, can. Web standards are the key to an accessible, reliable, “future-proof” website. Some Internet technologies may come and go; jumping on the latest trend may make your site seem “with it” today, but tomorrow it will be painfully dated… if it even works at all. But these three core web technologies will always be at the heart of the web. Plus, a site built with web standards will automatically be structured well for search engine listings, without the need for expensive and questionable SEO tactics.

A win for Internet users. Web content that is built and delivered with a diligent adherence to web standards will work reliably with any device, any software, that is used to access the Internet. Plus, no well-formed, standards-compliant HTML page ever crashed a web browser.

Web standards: Win-Win-Win.

A brief rant against “mobile” websites, and in praise of CSS3 media queries

This morning, as I do on most mornings, I eased the transition between my peaceful slumber and the mayhem of conscious life by lying in bed, catching up on the goings-on of humanity on planet Earth with the help of my iPhone and the Internet.

This usually consists of checking Twitter, Facebook, and my Google Reader feeds, but when that isn’t enough, I’ll occasionally search the web for whatever random piece of information crosses my stream of consciousness. Today that happened to be the Tim and Eric comedy tour that’s currently underway, since I’ll be seeing it when it arrives in Minneapolis on Wednesday. So I googled Chrimbus Tour review and one of the first links that came up was a review on BuddyTV.

BuddyTV is not a site I think of often. I believe I was vaguely aware of its existence before today, but I didn’t know what it was all about and I never had any inclination to visit it. But I was certainly happy and willing to click the Google link and read its review of the Chrimbus Tour.

Unfortunately, the site did not reciprocate that happy willingness. Instead of taking me to the desired review, it detected I was arriving via iPhone, so it shunted me off to an annoying splash page imploring me to download the BuddyTV iPhone app. No thanks, I really just want to read the article I came here for in the first place. Oh, great! You’ve provided an “Or continue to BuddyTV.com” link at the bottom. Thanks!

But — and this is so often the case in this scenario — that link did not helpfully take me to the article I wanted. (And as a web developer, I can tell you it is not at all difficult to make it do that.) Instead it just went to the BuddyTV home page. Now what? I’ll tell you now what: I closed Mobile Safari and got out of bed. Not only did I not download their app; I didn’t expose my eyeballs to any of the ads that pay for their website; I didn’t get to read the article I was interested in; and I was left with such a negative impression of the site that it drove me to this public rant.

All of this is not really to single out BuddyTV for its bad behavior, though. BuddyTV is just one site among many I’ve encountered over the past couple of years that all adhere to this same pattern of deplorably ill-conceived UX design. Surely this is not the reaction the owners of these sites hope to elicit. But it’s exactly what happens with me, every time, and I’m sure I’m not alone.

There is a solution.

We frequent users of web browsers on mobile devices just want to see your site. We want to see the same pages we’d see on our computer. The same content. But it doesn’t hurt to have that content optimized for the mobile browsing experience. Resized to the smaller screen. A streamlined layout that’s easier to navigate with a touchscreen. But, fundamentally, the same experience.

While there are some tools out there to help turn a regular website into a mobile website (most notably Mobify), there’s a far easier solution: CSS3 media queries.

CS-what media what now? CSS3 media queries are, simply, a set of stylesheet definitions that are applied to a web page selectively depending on certain characteristics of the media the page is being viewed on, most notably, screen size.

With CSS3 media queries, you can define an entirely separate set of stylesheet attributes to be applied only when the user is visiting the site from a small screen. Or an extra large screen. Or you can describe a bunch of intermediate sizes, so with the exact same HTML content the user will see a perfectly laid-out page, optimized to their screen, whether that’s an iPhone, a netbook, a “standard” computer monitor or a 30-inch Apple Cinema Display.

I’ve begun working more extensively with CSS3 media queries on some of my own projects lately, and I am very excited about the potential. If you’re a web developer or designer, you should learn about CSS3 media queries now. And if you’re a website owner, you should know that “mobile” sites are sooo 2008. Now you can have your cake and eat it too. You can have the best of both worlds. Insert cliché here. Just don’t subject your site visitors to any more obnoxious plugs for your iPhone app, or dump them thoughtlessly on your mobile home page with no way of tracking down the article they were coming for. It’s not fair to your users, it’s not fair to your public image, and if you’re supporting your site with ads — or, for that matter, if you’ve been convinced to drop a ton of extra cash on developing a separate mobile site, or an iPhone app that just displays your site’s content anyway — it’s costing you money.

UoP’s Greatest Hits

In the spirit of “If you can’t say anything nice, don’t say anything at all,” I will refrain from writing about last night’s midterm election results, except to say, “Don’t blame Minneapolis.” Also, to quote Apu Nahasapeemapetilon, “If you survive, please come again.” The next two years will either prove or disprove the merits of the Tea Party movement, and if we’re lucky we’ll still be around in two years to start cleaning up the mess.

OK, I knew I couldn’t avoid saying something snarky about it, but that’s it. No more. Let’s move on to something fun… ME! I’m taking a look back at the top 10 posts on Underdog of Perfection, based on the number of hits they’ve received according to WordPress stats. Without further ado… I present the all-time top 10 Underdog of Perfection posts to date.

OK, just a little further ado: here’s a chart of my hit count over the past month.

And now the list…

10. Mechanically-separated chicken or soft serve ice cream? You be the judge.

January 17, 2009 — When the gross picture of mechanically-separated chicken exploded as a full-fledged meme last month, as part of a factually challenged story hyping the dangers of the stuff (come on… you don’t need to make up stuff like “bathed in ammonia”; the truth is bad enough), I immediately recognized the picture as one I had seen about a year before. As I recalled, I had seen it on TotallyLooksLike.com next to a strawberry soft serve. I had forgotten that I had created that “totally looks like” image, which apparently is no longer available on that site, but is still on mine. Hence, traffic!

9. Best Google Doodle yet

June 6, 2009 — Ah, that would be the Tetris Google Doodle. But I suspect that every time there’s a new Google Doodle, someone googles “Best Google Doodle yet” and finds this post. Traffic!

8. Honda Fit iPod controls: when something is worse than nothing

August 23, 2009 — Rants are always good for some hits, especially when it’s something other people are annoyed by too. The fact is, the Honda Fit iPod controls suck, and Honda doesn’t seem to be doing anything about it, so I suspect as each model year is introduced, this post will generate more… traffic!

7. Migrating from CakePHP 1.2 to 1.3: My Story (Part One of… Possibly More than One)

May 16, 2010 — Writing about technical issues surrounding web development is one of the ostensible purposes of this blog, especially since I went freelance, so it’s gratifying to see my fellow developers relying on me for information, on those rare occasions when I actually have some to share. Thanks for the traffic! (I really didn’t set out to end each of these with the word “traffic” but it seems now that I am destined to do so. Um… traffic.)

6. This is what I wanted all along

October 27, 2010 — Being just a week old, this may be the fastest ascension of any post I’ve written to date. I suspect a lot of that has to do with the timeliness of the topic, but given the vague and keyword-free title (take that, SEO strategists!), the most logical explanation for its popularity is surely the conscious effort I made to promote it. Near the end of the post I make reference to the review of the MacBook Air by Jason Snell for Macworld. I also tweeted an announcement of the post, and stuck in an @jsnell, both in honest appreciation of his review, but also in the somewhat crass hope that he would retweet it. Which he (and several others, most notably Michael Gartenberg) did. Boom! Traffic!

5. Brooks Brothers: what’s up with the sheep?

July 25, 2007 — I’m glad some of these “random observation” posts are generating traffic. I believe I’ve spent a grand total of less than 5 minutes of my life inside Brooks Brothers stores, but I’ve pondered their bizarre logo for much longer, and the fact that others have too has brought my blog significant traffic.

4. Why does Safari 4 Beta take SOOOOO LOOOONG to start up? Am I the only one having this problem?

March 1, 2009 — I kind of wish some of these posts would stay buried. Three of the top four all-time posts on my blog are related to issues with Apple products, specifically, issues with early releases and/or beta software. People continue to visit these posts long after they’ve become irrelevant. Seriously, Safari 4 Beta? It’s currently up to version 5.0.2! Please, this post needs no more traffic!

3. Dog inequality in Walt Disney’s world

November 18, 2008 — And then there are posts like this one. Awesome. I love the fact that this has resonated with so many people. Goofy + Pluto = Traffic.

2. Solution for the iPhone Facebook problem

June 8, 2009 — Here’s another post pertaining to early software, and one that’s way past its sell-by date. Here, from an SEO perspective, we have an interesting case study: a keyword-laden but still generic title. What iPhone Facebook problem? The post was referring to the dilemma of iPhone users who were stuck with the then-crappy iPhone Facebook app or the then-crappy iPhone-optimized Facebook mobile site. The best option at the time, in my opinion, was the non-iPhone mobile site, but Facebook had a redirect built into that site that would automatically take iPhone users to the inferior iPhone mobile site. I found a way around that, and shared it in the post.

This is not really relevant anymore, but now any time there is any kind of problem with iPhones and Facebook, this post sees a surge in traffic.

1. Disabling the pinch-zoom feature on the new MacBook

March 9, 2009 — I’m always a bit annoyed when I look at my stats and see this post near (or at) the top. To me it’s a long-dead issue, but apparently not. I just showed this solution to SLP yesterday, so the problem still persists, and whenever I get a new Mac or reinstall my software, I have to remember to go in and deal with this again.

I don’t know whether or not I’m in the minority of Mac users here, though I suspect not, but I do not like the multitouch features of the MacBook trackpad. The only one I use is two-finger scrolling. That’s nice, but the rest are just an unwanted nuisance. I forget they even exist until I trigger them accidentally when I’m trying to do something else. Then I have to dig into System Preferences again and turn them off. Apple may love multitouch, and it’s great on iOS devices, but clearly there’s some distaste for it on the Mac, which for me means traffic.

P.S. You may notice a logical inconsistency here: the rankings in this list — specifically, the placement within the rankings of #10 and #6 — don’t jibe with the chart I showed at the top. That’s because most of the traffic driven to my site in the wake of the mechanically-separated chicken meme went to the home page, for whatever reason, not directly to the post. In which case those visitors would have completely missed the mark. In short, it’s a failure both for Google and WordPress Stats. Great job!

This is what I wanted all along

Last Tuesday night, I was sitting in a chair upstairs in my house*, with my 15-inch MacBook Pro, my iPad, and my iPhone 3GS all on my lap. And I had a revelation…

I’m a huge nerd!

No, not that revelation. I had that long ago. The revelation was…

This is ridiculous!

Earlier in the evening, I had spent a considerable amount of time hunting, as I had several times before, for a workable iPad app for writing code. I decided to spring for the $6.99 for Gusto, which seems promising. But since it currently doesn’t support SFTP (due to government regulations on encryption software, which the company says it’s working on), it’s completely useless to me in its present state. The bottom line: while there’s plenty I can do with an iPad, I still can’t do my work on one, which limits its usability.

The conclusion I had last Tuesday night was simple and obvious: I need a Mac that’s as small as an iPad.

And then came Wednesday. Steve Jobs must have been reading my mind on Tuesday night, and then he hopped in his Delorean to go back in time* a few months and develop a solution to the problem I had only just realized I had. Because at the Back to the Mac event Apple held that day, Steve Jobs introduced my dream computer: the 11-inch MacBook Air.

The moment I saw it, I knew I needed it. I worried a bit that it might be underpowered, or its storage capacity might be too small. But that’s not important. It would fit in the CaseCrown iPad messenger bag I had recently purchased, and that was all that mattered.

OK, performance mattered too. So before buying one, I wanted to try it out and see if it could handle what I was going to throw at it. I’d call myself a “power user” (if it didn’t sound so stupid), although I don’t usually push my Mac’s limits in terms of processing power: I rarely edit video (unfortunately), and my work in Photoshop is usually limited to small, web-scale graphics. But I do often have a lot of programs open at once: I’ll be coding in Coda; uploading files with Transmit; checking email; previewing sites in Safari, Firefox and Chrome (and occasionally bothering to check them in Internet Explorer too, which means running Parallels Desktop); writing project proposals in Pages; and editing images in Photoshop… all while keeping the music running constantly in iTunes.

My somewhat idiosyncratic suite of applications wasn’t on the demo unit at the Apple Store, of course, but I did the best I could to push the little dynamo to full capacity: I opened all of the iWork and Microsoft Office applications at once, and then simultaneously ran a video preview in iMovie, played back a multitrack audio project in GarageBand, and watched the Close Encounters of the Third Kind trailer in iTunes. All of the video and audio ran perfectly even under these conditions, and at that moment I knew I wouldn’t be walking out of the store without a MacBook Air in my hand. I also picked up the external SuperDrive (for CD/DVD access), and I supplemented the feeble 128 GB of Flash storage with a portable external 1 TB USB drive from Seagate.

I spent most of Saturday afternoon installing applications and transferring files from my MacBook Pro to the MacBook Air. Make no mistake, my goal from the moment I laid eyes on it has been clear: this machine was going to replace both the MacBook Pro and the iPad in my “digital lifestyle.” Which means that I am also doing that thing that so many of the tech bloggers are asking if it’s even possible: I’m using the 11-inch MacBook Air as my only computer. I’m on day three of this experiment, and days one and two were heavy work days. Here’s a summary of my experiences so far.

Screen Size

The MacBook Air’s screen is indeed small, but its high resolution makes up for the lack of physical space. It’s basically like a widescreen iPad: the vertical pixel count is the same (768 pixels), with the horizontal increased substantially (from 1024 to 1366). Its dimensions are comparable to the iPad’s, which means its pixel density is about the same.

The image is very clear and sharp. But it’s also making me realize my eyesight isn’t what it used to be. It’s also not directly comparable to the iPad, because I would typically have the iPad’s screen about a foot from my face, but the MacBook Air is usually at least twice as far away. When I’m working on it directly it’s acceptable. But at my desk I attach the MacBook to a 19-inch LCD and use the MacBook’s own display as a secondary monitor. In this layout the screen is even farther from my face, and I do have a bit of trouble reading it clearly at that distance.

In short, although the screen is small, it has a high pixel count and dense resolution, so it’s a very usable size, albeit a bit challenging for aging eyes.

Tip: I’ve always kept the Dock on the bottom of my screen, but the demo unit had it on the left, which seems to make sense given the widescreen aspect ratio on this screen. I’m trying it out and so far I really like it, even though I do sometimes accidentally go to the Dock when I mean to go to the tool palette in Photoshop.

Storage Capacity

128 GB is not a lot of storage space anymore. My first Mac, back in 1994, had an 80 MB hard drive. Times change. I knew I’d never be able to fit my 250 GB iTunes library on the MacBook Air, but I was worried that I wouldn’t even be able to fit Mac OS X plus all of my applications on it. I’m pleased to say though that I was able to install all of the applications I regularly use, plus all of the iTunes content I keep on my 32 GB iPhone (allowing me to sync the phone), and I still have over 62 GB free. I’m planning to allocate about 20 GB for a Boot Camp Windows 7 set-up, but that will still leave about 40 GB for data files for future projects. The bottom line is that 128 GB is an acceptable bare minimum for my needs, but I would not have been able to get by with the 64 GB base model.

As noted above, I’m supplementing the on-board storage with a 1 TB external drive. It’s an investment I definitely recommend if you’re considering a MacBook Air. Not only is it great for Time Machine backup, but I’ve been able to load all of my iTunes and iPhoto data on it, plus archives of all of my digital crap dating back to 1994. It’s small enough and light enough to go with me in the messenger bag, too, so if I do need to access anything that’s on it, I’ll have it with me.

Tip: In order to make this work, I needed to manage two separate iTunes libraries. This is a lot easier than it might seem. When starting iTunes, hold down the Option key. iTunes will give you the opportunity to select a different library or create a new one. Same goes for iPhoto.

Performance

My old MacBook Pro had a 2.66 GHz Core 2 Duo CPU, almost double the 1.4 GHz unit in the MacBook Air. Processor speed is important for heavy-duty tasks like video editing, but in practice, I find the computer’s speed is far more a factor of its hard drive performance. Read-write operations are so much faster with Flash storage than with a traditional hard drive that with the kinds of day-to-day tasks I do, the MacBook Air seems at least as fast, if not faster, than the old MacBook Pro.

Memory

I knew going into this experiment that the biggest sacrifice I would be making was in giving up half of my RAM. My old MacBook Pro has 4 GB of RAM, and the stock MacBook Air comes with 2 GB. You can get a MacBook Air with 4 GB of RAM, but it has to be installed at the factory (since it’s soldered right onto the logic board), which means you have to special order it. I was too impatient for that, as well as reluctant to drop an extra $100, so I went with the stock 2 GB.

The biggest impact of this limitation for me is that I can’t keep as many applications open at once as before. I had gotten to the point where I never even paid attention to how many applications I had running, and rarely bothered to quit an application when I was done using it.

Tip: In the Mac OS X era, we Mac users no longer have to worry about manually setting memory allocations for our applications, but Parallels Desktop does still need to have its virtual machines’ memory limits set. I copied over my Parallels VMs from the old MacBook Pro, where I had given them each 2 GB of RAM. Doing this on the MacBook Air was not good… the thing ground to a halt when I fired up Parallels. Reducing the VMs’ memory allocation to 768 MB solved the problem.

Battery Life

Apple has touted the battery life of the new MacBook Air line with claims that the 13-inch can last up to 7 hours on a single charge, and the 11-inch 5 hours. I haven’t taken the time to log my actual usage time, but so far I’ve run down the fully charged battery twice. On Monday and Tuesday I had it plugged in all day as I worked, and then went on battery power in the evening while I spent some time organizing my data files, doing a bit more work, and of course always listening to music on iTunes. Anecdotally, I’d estimate I’ve been getting at least 4 hours of battery time under these conditions.

Today’s usage is probably the most relevant yet. I ran on battery at a coffeehouse this morning for about three hours. Now I’ve been running for about another half hour on battery power at MIA, and the battery indicator is saying I have 1:47 remaining. Not bad. This definitely beats the battery life in my old MacBook Pro. Then again, I almost never ran the MBP on battery power. It’s so big it doesn’t really feel like a portable device in the same way as the Air, and whenever I would go anywhere with it, my first instinct was to locate an electrical outlet and plug in. The MacBook Air feels portable and “unplugged” in the way that up to now only the iPad did.

Portability

It’s perfect. Jason Snell has it right: “It’s quite possibly the most desirable laptop Apple has ever made.” Indeed.

Sendmail not working? Maybe your server’s IP is on a block list

This is pretty arcane, even for me, but since I spent several hours troubleshooting this problem this week — and the solution was nowhere to be found on Google — I figured it was worth sharing.

My CMS, cms34, as I’ve mentioned a few times before, is built on CakePHP. Some features of cms34 include automatically generated email messages. CakePHP has a nice email component that facilitates a lot of this work. It can be configured to use an SMTP server, but by default it sends mail directly from the web server using whatever you have installed on the server, either the ubiquitous sendmail or the more powerful (and capitalized) Postfix. Don’t unleash a deluge of flame comments on me, but I’m using sendmail. So be it.

All was working well until a few weeks ago, when suddenly none of the mails were being sent. There were no errors on the website; the messages just wouldn’t go through. What was more confusing was that messages being sent to my own domain did go through, but for those being sent to my clients’ domains, nothing.

Nothing except log entries, that is. Specifically, the mail log was filling up with lines like this:

Sep 13 13:45:56 redacted sm-mta[28158]: o8DIjsx0028156:
to=<redacted@redacted.com>, ctladdr=<redacted@redacted.com>
(33/33), delay=00:00:02, xdelay=00:00:01,
mailer=esmtp, pri=120799, relay=redacted.com.
[123.456.789.000], dsn=5.7.1, stat=Service unavailable

(Note that I’ve removed the real email and IP addresses to protect the innocent, namely myself.)

“Service unavailable,” huh? I researched that error extensively, without finding much. Eventually I was led to believe it may be an issue with my hostname, hosts, hosts.allow and/or hosts.deny files.

A few relevant points: 1) my hosts.allow file only contains one (uncommented) line: sendmail: LOCAL and 2) likewise, the hosts.deny file only contains: ALL: PARANOID. I’ll save you some time right here: the problem I had ended up having nothing whatsoever to do with any of these host-related files. Leave ’em alone.

After following a number of these dead ends, I was inspired to check the mail file on the server for the user Apache runs as, in my case www-data. On Ubuntu Linux (and probably other flavors), these mail files can be found in /var/mail. Indeed, there were some interesting things to be found there, namely, a number of references to this URL:

http://www.spamhaus.org/query/bl?ip=123.456.789.000

(Again, the IP address has been changed… and yes, I know that’s not a valid IP address. That’s the point.)

I was not previously aware of The Spamhaus Project, but perhaps I should have been. The reason my messages weren’t getting through was because my server’s IP address was on the PBL: Policy Block List. Essentially, that is a list of all of the IP addresses (or IP ranges) in the world that, according to a well-defined set of rules, have no business acting like SMTP (Simple Mail Transfer Protocol*) servers — the servers that send mail out.

It stands to reason that my server was on this list; technically it’s not an SMTP server. But it’s perfectly legitimate for a web server to be running sendmail or Postfix or something of that nature, and sending messages out from the web applications it runs. Fortunately, it’s easy to get legitimate servers removed from the PBL. Simply fill out a form, verify your identity (via a code sent to you in an email message), and within about an hour, the changes will propagate worldwide.

Success! So if you’re in the same kind of situation I was in, where everything seems to be configured properly but your messages just aren’t going out for some reason, try checking Spamhaus to see if your IP is on the PBL.

* If you made it this far in the post, I shouldn’t have to explain the acronym. But I will anyway, as is my wont.