Web Standards DO Save, Then and Now

It's been known in the Web-development community for several years now that well-designed, semantic, standards-compliant Websites use dramatically less resources (such as bandwidth) than 1997-era tangles of nested tables and invalid HTML. But it's still refreshing to read confirmation that that truth is pretty universally applicable - especially when that reading doesn't depend on what we now know as the "latest and greatest" Web browsers.

Take, for example, this five-year-old article by Jim Ramsey, then-Webmaster of the San Francisco Examiner newspaper's Website. In the section titled Simplify, Man!, he writes:

This is what a basic link in our navigation looked like late last year, before standards:

<tr>
<td class="navmenu" height="18"
  onClick="javascript:rolloutNav(this);document.location='/home/index.cfm'"
  onMouseOver="javascript:rolloverNav(this);"
  onMouseOut="javascript:rolloutNav(this); " colspan="2">
<a href="/home/index.cfm" class="nav">HOME</a></td> </tr><tr>
<td bgcolor="#EEEEEE" class="navmenuspacer" colspan="2">
<img src="../site_images/spacer.gif" width="1" height="2"></td> </tr>

Now take a look at what an Examiner navigation link looks like now:

<li><a href="/home/">Home</a></li>

That’s a big difference. In fact, the first one is so bad, I’m almost embarrassed to include it here. And what did I get for all that extra stuff? Basically, nothing. The JavaScript triggers the rollover effect and the table cells control the spacing. All of that can be done using styles.

Let’s take another example. Here’s how a link to a story in the Arts section looked before standards:

<img src="../site_images/sfex/homekickerarrow.gif" width="6" height="8">
<span class="kicker">Movie Review: Dickie Roberts<br></span>
<a href="../templates/story.cfm?displaystory=1&storyname=090503a_dickie"
    class="headlinesm">Problem 'Child'</a>
<hr noshade size="1" color="#EEEEEE">

Here’s the same thing following standards:

<h5>Movie Review: Hero</h5>
<h4><a href="/article/index.cfm/i/082704a_hero">Holding out for a 'Hero'</a></h4>

Again, once it is styled, the second version can be made to look identical to the first. When you can simplify markup in this way, it starts to make a big difference in bandwidth.

Comparing last year’s table-based site to our new standards-based one, the amount of information on our homepage is strikingly similar. Both contain basically the same elements and yet the HTML is 13K smaller on the CSS-version at 19.6K.

As a result, even though our traffic was about 40% higher in July 2004 than in September 2003, our bandwidth was almost exactly the same for those two months.

"[E]ven though our traffic was about 40% higher...our bandwidth was almost exactly the same..." What other development practice allows you to simultaneously:

• boost your traffic by nearly half without similar increases in bandwidth costs;
• improve your search-engine results without expensive, error-prone twiddling;
• open your site to a potentially much wider audience, by not limiting what platform or browser your audience uses; and
• significantly reduce the cost and complexity of maintaining your site?

As one colleague put it in an IM discussion, "people who develop like it's 1997 shouldn't be surprised if their revenues and page views don't exceed 1997 levels. Especially if they weren't around in 1997."

I'm not (quite) to the point of some of the more, um, evangelical developers out there in equating broken, invalid sites with actionable incompetence — but if our craft has serious hopes of making it out of "hobbyist" status in the eyes of non-technical business people, to where they treat practitioners as members of a profession, then we need to get some meaningful, practical, well-defined standards. This (standard-compliant, semantic development) is at or very near the top of my list of such standards.

Final note: I find it deeply ironic that Google have apparently redesigned the posting interface for Blogger. Whereas previously I have been able to post from any Linux, Mac or iPhone browser, switch between HTML editing and WYSIWYG view, and use all the other goodness...the new CSS and JavaScript seem to fail in any of the half-dozen Mac browsers I've tested today. One step forward, two steps back is especially painful when one started by walking directly away from the very edge of a cliff.

Tools, Continued

UPDATED 2 November 2010; see last paragraph.

---

This blog, fairly obviously, is published on blogger.com, which is now owned by Google. Blogger.com is geared primarily towards people who want to write but don't want to have to worry about the nitty-gritty technical details involved (such as HTML, CSS and so on). Sign up, click the 'New Post' button, and off you go...almost easier than falling out of your chair.

For the Web wizards among you, you can get into the guts of how your blog and posts are laid out and formatted; there are several in-the-tin and numerous third-party templates that can be used to style your blog any way you like it, and those can then be hand-tweaked by you to get things just so.

As with any click-and-go interface, the Blogger new-post window (what I'm typing in right now) has a "Preview" button (or actually, link); click on it and you'll see a more-or-less-reasonable facsimile of what your breathless prose will look like to the next visitor who stumbles across your blog. I did say "more-or-less-reasonable"...

One thing the preview area doesn't do — sensibly in hindsight — is to apply your template's formatting to the post being previewed. So that, for instance, if your template specifies that you want 9-point Gentium Book Basic, Times New Roman or Times (in that order) for your body, you won't see it that way in the preview.

What you also won't see — and this is what tripped me up for the longest time — is other styling for the post body, particularly justification. You may notice that all my posts are displayed with justified left and right margins; the default, and most commonly used setting, is for a justified left and ragged right margin, which I find unattractive. I've tweaked the template I use several times over the years to try and get the effect I was looking for. Each time, the post-preview showed no changes to the text formatting, and so I undid the change without viewing the entire blog normally. I have been instead hand-wrapping the content of an entire post in a <div>...</div> element pair whose only reason for existence was to set text-align: justify;.

This isn't the first time I've blogged about my learning-experiences-that-shouldn't-have-been, and just to be perfectly clear about this, I'm not trying to dis Blogger.com about this. The preview-while-composing feature is merely to let you see the content of the post you're working on without all the editing framework around it. It won't, and arguably shouldn't try to render that content in its final form. You do, after all, have the ability to go back and edit posts you've already published.

This is, at its heart, a cautionary tale for those of us tasked with making the Web easier to use for a wide variety of users. Be careful especially with interface design. Recognise that, barring explicit cues to the contrary, people's assumptions about How Things Work on your site may have only a nodding acquaintance with your own — but if you have some appropriate description in the right place, users are often happy to adjust. But there has to be a balance, or your 'power users' will feel like they're being stifled. How you achieve that balance is, of course, up to you to find out. Good luck.

UPDATE: Blogger have, since I wrote the original post, changed their preview feature (at least for "Blogger in Draft," their next-gen interface, which I use and recommend.) When you click the Preview button now, Blogger opens a new tab (or window, if you're old-school enough not to use tabs) with the preview of your draft post. This preview is exactly as a visitor to the published post would see it, with the exception of a great big Preview stripe in the upper-left corner. A wonderful improvement; thanks, guys!

Misadventures with Customer "Service": With Service like This, Why Bother?

Doing a job search using various Websites became really popular about ten years ago as an easy way for candidates and companies to find each other without any (visibly obvious) middlemen directly involved. I understand that in some geographic and employment areas, it's still a useful tool. I've had myself registered on fewer than half a dozen for several years, even though my last 6 jobs were all found through other means.

Job sites aren't typical consumer Websites in that they're really trying to target two distinct groups of customers: companies with jobs on offer (who generally pay the bills) and jobseekers (who generally don't). Even though jobseekers don't have any up-front money dangling in front of the site operator, wise (or experienced) operators of such systems know that they should "take care" of these site users well, since:

• Companies will be less likely to pay to advertise on general-audience sites with few users, and
• Users who have negative experiences (on any site) are often motivated to "spread the word".

Any business which is heavily dependent on its Website for revenue or for customer service knows (or quickly learns) that locking actual or potential customers out of their site through defective, easily-correctable site implementation has a direct and negative impact. The pathologically clueless operators don't seem to know or care why this happens; they just notice their monthly traffic figures dwindling over time, with revenues to match.

This even applies, although to a lesser extent, when the market being served by the site encourages a lack of competition. This is the case quite often here in South Asia, and notably in Singapore. Only two media companies serve the English-language market here, both with apparent Government ties. Broadcast television and radio are similarly throttled. This becomes apparent to anyone who spends more than a few days here. Individuals are engaged in frenetic, all-consuming competition with each other, while favoured companies and industries don't (visibly) engage in such grubbiness.

All of this went through my mind again over the last few days, after I'd had a series of consistently unpleasant experiences with one particular Website operator. Necessary background: I have been essentially Windows-free (and thus virus-free and botnet-free) for some five years now, initially using Linux systems like Ubuntu and then the Apple Mac. What has made this change practical, for me and for tens of millions of other people, has been the emergence of open standards in desktop computing, particularly with regard to open data formats. A classic example with which anyone reading this is familiar is HTTP. Any device, from large mainframes to appliances to mobile phones, can be used to produce or access information via HTTP, most commonly in the form of Web pages. Other "standards", like MP3 for audio or Microsoft Office document formats, are proprietary to a company or organisation but widely implemented by competing or collaborating systems. This reliance on actual or de facto standards, as much as any other single factor, is what has enabled much of modern technology, particularly the Internet (which many think of as synonymous with the World Wide Web).

Not everybody has always "played fair" with these standards, however. Microsoft, in particular, have been infamous for their commonly-used practice of "embrace, extend and extinguish" has led to several instances where they support an existing standard (such as HTML for Web pages or Kerberos for network authentication) and either introduce incompatible features or defective versions of standard features into their implementation. This has the effect of "locking in" users who support Microsoft's implementation rather than the actual standard. These usees, as they are often called, face significant actual or perceived costs and difficulties were they to switch away from their now-Microsoft-specific infrastructure. Microsoft have by no means been the only ones to do this sort of thing; they are, however, often quite brazen about it — and their usees don't always have an accurate understanding of the true costs of their "investment."

In particular, during the "dark ages" of Web development in the mid- to late 1990s, it was common for sites to have text on each page proclaiming "Best viewed with Microsoft Internet Explorer"; the tools which they were using to create the Web pages (often Microsoft FrontPage), did not always (or easily) generate valid HTML, CSS or standard JavaScript — all of which are needed to make interactive, "dynamic" Web sites work. As the relevant standards have become better-known to amateur and semiprofessional Web developers, the tools used by professional developers mature, and those using Web browsers become more aware of the importance of these standards, we have seen an increasing Web "Enlightenment", where once again, anybody (or anything, like a Google search crawler) can access all content for a site.

There are exceptions to this, however, just as there are trailing-edge sluggards in any social or technical change. These can give excuses about lack of resources, perceived lack of need ("We're doing fine the way things are") and so on — which quite often attempt to mask either ignorance of the issues involved or, at a fundamental level, disrespect for their current and actual customers. When a well-equipped, motivated (outside) organisation is in a position to gain from that ignorance or contempt — as Microsoft for so long was with regard to Web development and standards — those "sluggards" will continue to pat themselves on the back for their "prudence" and "conservatism" — right up to and often past the point at which the business dies.

One such organization appears to be the company which owns and operates the JobsDB.com group of employment Web sites. With "specialised" sites for Singapore, Thailand, the Philippines, Australia and other countries, and an apparently large advertising and promotion budget, it's safe to speculate that millions of people have at least seen their advertisements, if not actually made use of their site. Those who actually do try to browse for a job there, however, can face significant problems — if they're using anything other than Internet Explorer on Windows as their browser. (And the message seems to be finally getting through to many users — Microsoft Internet Explorer and Windows itself cause numerous security and stability problems that are comparatively unheard of on any other system.)

I browsed jobsdb.com.sg, the Singapore-themed version of their online job service. I got as far as entering my details in an application form for a position, when I ran into insurmountable difficulties. Numerous pages display poorly in any of the browsers I tried. "Obviously using archaic design," I thought, "but as long as the function isn't too badly broken, I can still deal with this." I eventually got to the a page with a form to be filled in by those wishing to apply for a specific job (at SingTel) and ran into fatal problems. I clicked on the link to report a problem with the site, and included the following description:

SingTel application page misbehaves horribly with Safari 4.0.2/Mac. An ASP alert box, (URL omitted for this blog post), is displayed in a new tab, taking the entire browser window; the message "Please correct the field(s) with red exclamation mark(s) (!). You can click on the exclamation mark for instruction and input relevant information." indicates that there was an error on the initial page (which is still open in its original tab), but no red exclamation marks appear.

Very 1998ish.

Sixteen hours after filing the initial report, and getting an auto-generated email indicating that it had been received and entered into their ticketing system, I get the following email from "sg-cshelpdesk@jobsdb.com.sg"):

Dear Sir / Madam,

Please clear the cache of your browser by deleting the cookies and temporary internet files, enable the java and javascript, disable the popup blocker, open a new browser and try from there.

Otherwise, please try other browsers like firefox or Internet Explorer 6.0 & above to access the Career Portal and verify that your Internet Settings are configured correctly against http://sg.career.jobsdb.com/faq/documents/Internet_Explorer_Settings.pdf. Then open a new browser and submit from there.

Best Regards, Customer Service

Absolutely no problem-specific content whatsoever. This could easily have been (and in my opinion probably was) an automatically-generated message that was sent when no relevant response would be forthcoming within 24 hours after filing the problem (the '16:44' in the timestamp, or 4:45 PM local time, sounds suspiciously like "it's the end of the day, nobody got to this, blow him off and hope he goes away.") There continues to be an explicit assumption within the fluff mail that I'm using Internet Exploder; even though the second paragraph mentions "firefox" (sic), the PDF link supplied says that it relates to IE.

I'm getting used to companies, particularly the all-pervasive oligopolies, here in Singapore treating the customer with contempt. Knowing that no living human would probably ever read it, however, I did send one last complaint email.

Dear Customer “Service”,

Did you actually read the report I filed? Here are a few Statistically Improbable Phrases to clue you in:

• “standards-compliant (non-IE) browsers”. I tested your site with ten different browsers on four different operating systems. In no case did it operate correctly. By the way, Microsoft does not make a version of Internet Exploder for non-Windows systems.
• “Safari” — Safari is the standard, comes-with-the-system browser for Macs and iPhones, and is available for those wishing to upgrade their Internet experience on Windows as well.
• “an ASP alert box...is displayed in a new tab” — obviously not what was intended by the coder; however, competent JS wouldn’t do this.

I am a Web developer with nearly 15 years experience. I have been teaching Web development for ten years. If a student of mine from my very first class, back in 1999, had submitted work with such grossly defective JavaScript, he would have been required to redo it. You see, even since the early days of the World Wide Web, there have been standards that even Microsoft can comply with – though they also “support” their own proprietary, non-standard version of HTML and JavaScript and have encouraged careless or inexperienced “developers” to lock themselves in, breaking sites for anyone using a non-IE browser. That includes half the smartphones on the planet, every single non-Windows desktop or laptop system, and search engines like Google.

You should take http://www.amazon.com/Novelty-Sign-Brain-before-engaging/dp/B000K62V92 as a gentle but firm recommendation.

Sincerely,

No, I don't expect a relevant reply. Yes, I do feel better. No, I won't be using JobsDB or any related site, and will happily explain to any who ask my opinion precisely why.

A final note: There is a nice little site called yougetsignal.com which offers a nice set of network (Internet) diagnostic and information tools. One page on the site, http://www.yougetsignal.com/tools/web-sites-on-web-server/, does what's called a "reverse IP address lookup". I used this page to find out what other sites are hosted by the same server as jobsdb.com.sg. Try it yourself; the results included apparently all "country-specific" jobsdb.com sites — as well as the site for Target, an American retailer. Interesting.

Not that I expect it, but if any of the parties mentioned here were to reply to what I've written here, I'd be happy to publish their response.

Expanding the Omniverse

Anybody who's worked with me in about the last 25 years knows that I've been preaching the idea that software craftfolk should never stop learning. Further, I've always believed that learning new languages or tools is one of the easiest ways to accomplish this, keeping the mind supple and open to new ways of doing things. And by and large, I've kept this up, learning enough of a new or long-neglected language to at least be able to read and patch code every two or three months. (You do the math.)

One of the languages that I learned rather early on in its lifecycle is Ruby. (Wikipedia has a rather good article summarizing the history, if you're unfamiliar with it.) Early 1.0-1.4 or thereabouts releases were interesting — they showed the power and promise of the concepts that Ruby is built on, without the bloated inscrutability of, say, perl. As so often has happened, I'd learned just enough to be dangerous, and then got sucked back into the charnel house that is Microsoft Windows development. By the time I had the time and inclination to start messing with Ruby again, an unfortunate thing happened.

Ruby on Rails.

Not that Rails isn't a great tool for building 37signals-type Websites; it clearly is. But it became a victim of its own hype and started being used for everything imaginable — famously including Twitter (a hype explosion in its own right.) Rails was enough to push me — and apparently a good number of other folks — away from Ruby and onto other languages, notably Python. And so I spent the bulk of the next couple of years in PHP, Python, C++, Objective-C, D (another bit of unsung genius), and managed to keep busy.

We developers have a well-known cliché for what drives us to do new things or participate in development projects; "scratching an itch". To scratch an itch in this context is to solve a problem that we ourselves are facing, or to do something that otherwise interests us. What got me motivated to get back up to speed in Ruby wasn't the Rails hype, or even seeing all the nice APIs that Twitter and Repertoire had made available. My problem was a bit simpler and more immediate.

Apple's Mail app started crashing under the load I was giving it. For about a year, I'd had a mail store that averaged about 2 GB and I was getting on the order of 600 to 800 emails a day. I don't mean to be critical of the app; it just wasn't designed to do what I was asking it to, certainly not when sharing 2 GB of RAM with the rest of the system. By the time I migrated away from Mail, I had over 400 filtering rules defined, to slice and dice incoming emails into appropriate folders where I could deal with them as I chose.

In late May, 2009, I up and migrated my email from Apple Mail to Microsoft Entourage. For those of you whose only exposure to Microsoft email software has been Exchange or Lookout! ("Outlook") Express, you're in for a pleasant shock. Entourage runs quite happily in the system as it is (even if I can't run certain other apps at the same time without upgrading RAM), and doesn't give me the maddening ten-minute freezes that were common with Apple Mail as it tried to figure out what to do next. Importing my existing mail store was a breeze. The filtering rules even came along for the ride, and Microsoft's rules editor is a real treat. There was, however, one small problem.

Somehow, the ordering of rules had become scrambled during the import, and after a few weeks of hand-editing to fix the biggest problems, I started looking for a program that would let me import, export, reorder and bulk-edit Entourage's rules. So far, I haven't been able to find one. (If anybody knows of anything useful, please add a comment or email me.) OK, I thought, no problem; nearly everything on the Mac is scriptable. I should just need to learn how to access Entourage's rule set from AppleScript or something similar, then I can write the tool I want. Not trivial, but certainly something that seemed conceptually quite practical.

So I started learning AppleScript, and casting about for tools and sample code that talked to Entourage from AppleScript. While searching, I ran across Matt Neuberg's site. Dr. Neuberg wrote the definitive guide on AppleScript — and then found something that worked better for him: rb-appscript. He's written an online book about it (eventually to be published on dead trees). At this point, I said "ok, let's get started with Ruby again and see what we can do."

If anybody has any pointers or suggestions, please comment. Thanks for reading.

"You can have my...when you pry it out of my cold, dead hands"

One of the, shall we say, unusual things about being in this line of work is that you develop stronger-than-is-healthy bonds to particular bits and pieces of technology, both hardware and software. For example, I think that anybody who's worked on a Mac as their main system for a year or so would take a catastrophic productivity hit if they were required to work in a Windows-only environment. Further, I assert, based on experience and observation, that this hit would actually increase in severity commensurate with previous Windows experience, as the nature of the problems and hassles encountered on a continuous basis would be that much more familiar.

But, believe it or not, this isn't a hit piece on Windows. If anything, Mac OS X takes the brunt here, in more or less a continuation of a previous post.

Don't get me wrong. The Mac itself is still one of the very few things I'd plug into that quote in the title. But the differences between it and the BSD Unix heritage it's based on, at an architecture-implementation level, sometimes drive me up the wall; it's as though I'm caught in the old Saturday Night Live "It's a floor wax AND a dessert topping!" skit.

Case in point: the Web developer's Swiss Army Ginsu Knife, PHP. On Unix and Linux systems, it's very straightforward to build a scripting engine that contains just the features and extensions needed, with security and debugging features added in to taste. The last few releases have even made that process humanly feasible for Windows usees. On Mac OS X, however, it's a different story entirely. (Item: As of Friday 11 July, the search "mac php configuration" returned some 5.22 million hits. Applying Sturgeon's Second Law to this leaves us with at least half a million pleas for and/or offers of help.)

The practical result is that, on Mac OS X, one uses one of the various prebuilt binaries for PHP (from Apple, MacPorts, MAMP or similar — or goes without. If you're interested enough in PHP to want it to work on a Mac, you probably have some urgent deadline breathing down your neck; you don't have time to figure out how/why there are unique runes and incantations involved in making it work. This is the dark flip side of "almost everything Just Works"; the things that don't Just Work tend to average the entire experience out.

So, what's the most efficient solution for the reasonably serious Mac-loving Web developer? Simple: max out the memory in your Mac (and I do mean "as much as Steve&Co let you put in and not one byte less, blastit!"). Then, add one of the software tools that's going to be on that Mac somebody pries out of my "cold, dead hands"; VMWare Fusion. Once you have Fusion installed, grab an ISO image of your BSD version or Linux distro of choice, install it, and use that for your PHP and other web-dev activities.

Better still, you can still use your fave Mac editor, browser and so on during development in the VM; you'll want to set up ssh on your VM, and then use sshfs to mount your Linux/BSD filesystem as a disk volume in your Mac. From that point — a file is a file is a file; you're just taking advantage of the *ix VM's tools. This is how I do my PHP 5.3 and PHP 6 testing now.

And, after going through all this extra effort, you may well pray that the new version of Mac OS X enables a better native solution. I know I do.

Nothing is perfect in this world, and all technologies have speed bumps in some fashion. The good bad thing about OS X is that there aren't nearly as many as in some other systems I could name — but when you hit the ones that are there, you hit them hard.

---

EDITED 2010/11/03: At the time this was originally written, there was a prerelease bit of software that lots of people, including the vendor and the opportunistic authors and publisher of at least one programming book, thought was going to eventually become PHP version 6. Not quite; one of the long-promised features for PHP 6 went down a rabbit hole and ultimately killed the whole thing. Most of the usable "PHP 6" features were incorporated into version 5.3.2.

The Best Tool for the Job

One of the nice things about growing up around (almost exclusively) men who were master mechanics, carpenters or other such highly skilled tradesmen was that I developed an appreciation both for "the best tool for the job at hand" and "making do with what's available" — and whichever of these applied, accomplishing the task at hand to the best of anyone's ability.

As I've progressed through my software and Web career, I've become highly opinionated about the tools I use, just like any other experienced software craftsperson I've ever known. You and I might use different tools to accomplish what functionally is the same task, but so long as we each have practical, experiential bases for those preferences, we should just go ahead and get what needs doing done. (There's an argument in there for open standards as a requisite for that to happen, but that's another post.)

Too many people who should know better have religious-level devotion to or hostility towards certain companies and/or products. Yes, that includes me; I know I've said some pretty inflammatory things, usually when I felt someone was expressing a religious belief masked as a technical opinion. No doubt they've felt the same about me and any others who were incautious enough to oppose their evangelism (or reactionism, depending on the circumstances). In general, it should be pretty evident to everyone with a personal or professional involvement in IT or personal electronics that trends are driven as much by "what I say three times is true!" as what actually can be shown to be true. That's how mediocre-at-best products become "industry Leaders"; inertia and close-mindedness set in, reinforced by a well-funded, continuous and strident marketing/branding campaign.

I was having a discussion about this online recently, with a former associate who's long had me pegged as an ABMer ("Anything but Microsoft"). I can understand how he formed that opinion; I've long complained about the (innumerable) defects in the "market-leading" operating system, and about how slowly progress has been made in cleaning up the most egregious faults (such as security). But I've also worked at Microsoft in Redmond — three different times — and I've always been impressed by the number of truly gifted people working there. They've had their triumphs and tragedies (anyone used Microsoft Bob lately?). They've had to deal with widely differing process and management effectiveness as they transfer between or liaise with different groups. They've ignored a lot of what has been done outside the company, but they've also created some amazing things inside; too many of which unfortunately never make it into public products.

And the quality of their work product varies as much as any of the factors that go into it. Cases in point: compare, say, Windows Vista with Windows Mobile or the XBox; compare Microsoft Outlook (forever known as "Lookout!" to security/admin people) with Entourage; compare Word for Windows to Word for the Mac — what I understand is a completely different code base (and visibly so) that "just happens" to be able to flawlessly read and write documents shared with Word for Windows.

I also reread a blog post I wrote last December where I detailed the issues I was starting to have with Apple's own Mail app for the Mac. I have a mail store that's hovered somewhere above 2 GB for the last year. I receive 100-200 legitimate emails per day (and up to 700 spams). I presently have over 230 filtering rules defined for how to handle all that mail. Those rules have been built up over the last five years or so — first using Mozilla Thunderbird, then Apple's Mail.app, and now a new system; a progression that also speaks eloquently about the value of open standards. I have never, to my knowledge, lost a saved message whilst transferring from one package to its successor. The few hiccups each transition has had with filtering rules have all been relatively easy to find and fix, with the newest app making that process breathtakingly simple.

The new mail app? As you've no doubt guessed, Microsoft Entourage. It, like every other Mac app I've ever used, Just Works as expected (at least until you get out to the far, bleeding edges). If Microsoft made Windows and Office for Windows as well as they make Entourage (and the rest of their Office:Mac products), they really wouldn't have to worry about competition — and they'd richly deserve that. The market-friendly price for their Mac product (where their major, worthy competitor sells for US$79) is just icing on the cake.

I don't hate Microsoft. I just wish they would stick to what they do as well or better than anyone else, and leave the crappy products that can never be anything but hypersonic train wrecks — like Windows and Internet Exploder. I wish that ever more fervently every time I'm asked to help some hapless Windows usee fix "why my computer doesn't work". That would also make Microsoft's long-suffering stockholders — including current employees, former employees and myself, among others — feel a lot better.