Non-relational databases have been available as a cloud service for some time, notably Google’s Big Table (currently available only when coupled with Google App Engine) and Amazon’s own SimpleDB. As a service targeted largely at web developers, however, cloud-based non-relational databases have always had a limited appeal since most web frameworks don’t support them directly. Offering the industry-standard MySQL database as a service may well be something of a game changer.

The latest edition of Mac OS X, Snow Leopard (or 10.6 for those in the know), has changed something that hasn’t changed on Macs since their introduction in 1984: a file’s “creator” code no longer has any role to play in deciding what application will open when that file is double-clicked. This is particular anathema to those few hearty souls who stuck with Apple during the lean years of the ’90s. Back then, those hearty souls often crowed about the Macintosh’s intrinsic superiority over the PCs of the era and the creator/type code regime was often at the top of their list of reasons why Macs were so obviously better.

Creator and Type Codes

For those not steeped in the history of file system metadata, allow me to explain a little. When Apple’s engineers created the Mac’s original file system, they decided to track a certain about of metadata about each file, or in other words to track certain kinds of information about each file in addition to the file itself. Among these metadata were the creator and type codes. The type code identified the contents of the file—i.e. plain text, JPEG image, Word document, etc. The creator code identified the program that had created the file¹. If set, the creator code was used to determine which program would open the file when double-clicked. If the creator code was absent, the type code was matched, if possible, with a system-wide default program for that code.

In many ways, this was an elegant solution to the problem of deciding what should happen when a user double-clicked a file. And certainly from a 1984 perspective, it followed the principle of least surprise: users expected that the program that wrote the file would open the file and that is precisely what happened. It was an obvious choice at that time particularly as nearly every program then in existence saved files in a proprietary format. Microsoft Word, for example, saved files in a format that only Microsoft Word understood. MacWrite saved files in a format that only MacWrite understood. Indeed, in these early days the two codes were almost always redundant: the default program for a given file’s type code was almost always the same program indicated by that file’s creator code.

Modern Needs

Over time, however, standardized file types developed that could be read and written by more than one program. Today, a JPEG image, for example, can be read by Apple Preview, Adobe Photoshop, Microsoft Word, Apple Pages as well as any Internet browser you can think of. Not only are there fundamental differences among these programs as to what they are and what they do, crucially for the user experience there are also vast differences in the load times for each of these programs. Apple Preview is a relatively svelte program that typically loads in a second or two. Adobe Photoshop, by contrast, is a behemoth that can take a minute or more to load. If a user expected Photoshop but got Preview, it is a mistake that is quickly corrected because Preview loads so quickly. If a user expected Preview but got Photoshop, it is a mistake that takes much too long to correct because Photoshop is so slow to load. In addition to surprised, the user is often frustrated.

Ah, but if the creator/type code regime is even half so superior as the Mac fanboys of the ’90s loved to claim, how then is it possible for a user to expect one outcome when double-clicking yet encounter another? The answer lies in the always-present but rarely acknowledged Achilles heel of the creator and type codes: they are now and always have been hidden.² And with good reason. In the first place, since they were invented for the resource-starved original 1984 Macintosh,³ these codes were limited to 4 bytes and were consequently quite cryptic.⁴ Secondly (and more importantly, I think), there is the simple fact that there are two codes. Most users would likely not remember which code did what or what would happen if one of the codes wasn’t set. How, then, was a user to know what would happen when he or she double-clicked on a file? Again, the answer from 1984’s perspective was simple: the file’s icon. Each program that overwrote the creator code would also add an icon for that file which visually tied the document to the program. Double-clicking on that icon produced no surprises as to which program would subsequently launch.

The trouble with the icon approach, however, is that while it does succeed at identifying the associated program for each file, it does nothing to visually indicate the contents of the file. All the Word documents, for example, end up looking the same. Worse, all of the image files look the same as well. Scanning a folder’s icons in the Finder becomes useless if it has a number of files made by the same program. Thus, as icons became more detailed and especially once color became available, icons became previews of the file’s content rather than visual references to the associated program. This trend started with images but Leopard brought pervasive preview icons, even to more humble formats like word processing and plain text documents. In the process, however, the visual tie to the associated program was lost.

So now we are left with a conundrum: how do we let the user know what is going to happen when he or she double-clicks on a file and provide a preview of the file’s contents in said file’s icon? The answer is painful to those loyal fanboys of the past yet perfectly simple: the file’s extension. Long eschewed by the older Mac community as a hideous artifact of “PCness”, file extensions have nevertheless been part of the file-opening-decision-making process since the debut edition of Mac OS X, Cheetah (aka 10.0). File extensions have the advantage of being both visible⁵ and simple. When I see a file ending in “.doc”, I know it will open in Word. When I see a file ending in “.pages”, I know it will open in Pages. No guessing, no surprises. If I prefer that JPEGs open in the quickly launching Preview rather than the slowly launching Photoshop, I merely set the global default for the “.jpeg” extension to Preview. If I need to edit the image in Photoshop, I can always open it in that program manually, in a number of different ways. If there is a particular JPEG image that I want to always open in Photoshop, Snow Leopard retains a per-file override that can be used to persistently associate a given file with a given application. Thankfully, this override data is not programmatically accessible via any of Apple’s public APIs so it is more difficult for Photoshop to hijack my JPEG associations as it always did when the creator code was honored.

Just What is So Surprising

The degree of “surprise” generated by a policy decision—such as no longer honoring the creator code—is, of course, entirely subjective. Long-time Mac users will tend to be surprised by this new behavior and therefore disappointed by it. Switchers from Windows will be more likely to embrace it. Personally, I was infuriated every time I had to wait for Photoshop to launch after double-clicking an image that I realized too late had been edited in Photoshop. I always found association hijacking to be a “surprise” and I gleefully welcome its demise. Moreover, relying on file extensions makes the Mac a better citizen of our connected world as file extensions undeniably represent a de facto industry standard for application association.

Now if only Apple would accept the de facto industry standard behaviors for the Home, End, Page Up and Page Down keys…

The latest milestone in Google’s laudable effort to speed Python is out. The previous milestone, 2009Q2, introduced a massive increase in memory usage when compared to the standard CPython implementation which has been tamed considerably in this milestone (though not eliminated completely). Q2’s ten fold increase is now down to only a two or three fold increase in memory usage. Overall performance has increased 15–70%, depending on the benchmark.

Google has finally released a packaged version of its Chrome browser for the Mac. Of course, it’s been possible for some time to download nightly builds of Chrome’s open source foundation, Chromium, but this is the first time that Chrome itself has been available. Ars Technica calls this release a developer preview although that particular language is absent from the “About” window where it is identified simply as build 4.0.223.11. I haven’t encountered any problems so far in my limited testing.

An interesting take on the evolution of “multi-touch”. It starts out by correctly pointing out that touchscreens like the iPhone’s really aren’t suited to larger desktop and laptop computers. I’m still wondering, however, how the combination keyboard and touchpad design depicted toward the end of the video would work for a laptop.

From the press release:

11 September 2009 —The IEEE today announced that its Standards Board has ratified the IEEE 802.11n™-2009 amendment, defining mechanisms that provide significantly improved data rates and ranges for wireless local area networks (WLANs). This new amendment to the IEEE 802.11 base standard is designed to help the data communications industry address the escalating demands placed on enterprise, home and public WLANs with the rise of higher-bandwidth file transfers and next-generation multimedia applications. WLANs based on IEEE 802.11 are widely deployed, with more than 1 million units shipping per day.

The tortuous process that finally resulted in this approval took ridiculously long. The first feasibility studies began in 2002, with a formal Task Group formed in 2003. Indeed, this approval is so mind-bogglingly overdue that it is unlikely to make any difference whatsoever; wireless hardware vendors started producing devices based on various drafts of 802.11n in 2004—5 years ago. In 2006, the Wi-Fi Alliance finally gave up on the plodding IEEE and started certifying devices for 802.11n before the standard was ratified.

Coincidentally, my personal 802.11g router/access point recently died and I placed an order for an 802.11n replacement before I heard the news. I’ll expect a firmware update if the final version made any incompatible changes with whatever draft my device was certified against.

Luke Wroblewski recently put inline validation—letting a user know if a field on a web form has been filled out correctly before the user clicks the submit button—through a formal usability test. To no one’s surprise (I hope), inline validation resulted in significant usability and satisfaction gains:

When compared to our control version, the inline validation form with the best performance showed compelling improvements across all the data we measured. Specifically, we saw:

• a 22% increase in success rates,
• a 22% decrease in errors made,
• a 31% increase in satisfaction rating,
• a 42% decrease in completion times, and
• a 47% decrease in the number of eye fixations.

Luke’s tests go further to test various details of possible inline validation options. He also rightly warns about the difference between “correct” information (which is generally not tested by web forms) and “valid” information (which generally is tested by web forms). His tests used a green check mark which led to some confusion on that point.

I agree whole-heartedly that inline validation is a big usability winner. I can’t help but wonder, however, what the best way to implement it is. Inline validation is, by definition, a client-side feature. It’s a bad idea, however, to rely on client-side validation as it can easily be bypassed; there must always, therefore, be server-side validation. How, then, does one best implement client- and server-side validation without repeating one’s self on both sides (and thus violating the DRY principle)? The obvious answer is to have the client-side code make asynchronous calls to the server to check validity but that can lead to a lot of otherwise unnecessary server calls and slow validation for the user. Are there any other ideas out there?

Jeff Veen explains why simply trying to copy great stuff—like the Apple iPhone—is doomed to failure while stealing the ideas behind the stuff can lead to great success:

NASA’s unmanned spacecraft Stardust collected material from the tail of comet Wild 2 and brought that material back to Earth. After careful examination of that material, scientists working on the project discovered the amino acid glycine:

“The discovery of glycine in a comet supports the idea that the fundamental building blocks of life are prevalent in space, and strengthens the argument that life in the universe may be common rather than rare,” said Carl Pilcher, director of the NASA Astrobiology Institute, which co-funded the research.

Proteins are the workhorse molecules of life, used in everything from structures like hair to enzymes, the catalysts that speed up or regulate chemical reactions. Just as the 26 letters of the alphabet are arranged in limitless combinations to make words, life uses 20 different amino acids in a huge variety of arrangements to build millions of different proteins.

Campaign Monitor has updated its guide to CSS support in email clients:

Designing an HTML email that renders consistently across the major email clients can be very time consuming. Support for even simple CSS varies considerably between clients, and even different versions of the same client.

With all of the improved standards support in FireFox, Safari, Chrome and even (to some extent) Internet Explorer, it’s easy to forget just how woefully behind email clients can be, especially web-based clients. Chris Clark sums it all up rather neatly:

1. Modern desktop and mobile email clients are practically the same as modern web browsers.
2. Gmail and other webmail clients are practically the same as web browsers circa 1993.
3. Enjoy your fucking <table> tags. And remember most webmail clients don’t load images by default, either.

Of course, I can’t help but think that it was perhaps a mistake to shoehorn HTML into email in the first place. No, that doesn’t mean I think all email messages should be plain text. Rather, I think that email should have its own simpler, saner rich-text format, backed up by some standards organization. Failing that, I think the technology industry needs to at least decide on a standard way to adapt HTML for use in emails.