A few months ago, I was helping a friend troubleshoot an odd iPhone-related visual error on Hunch. The right side of the buttons weren’t lining up vertically with the top or bottom of the rest of the button. Oddly, the problem only manifested itself when viewing the site at certain zoom levels (non-quantized, to be specific). Pinching in/out or zooming into specific parts of the page made the buttons render correctly.

We’d used a similar technique on Domainr, so were curious to see if there was a way to address it cleanly.

It appeared that WebKit for iPhone uses mipmaps to render minimized background images. This makes sense—it has fast texturemapping hardware, and OS X / Quartz has been using OpenGL to render 2D graphics for some time.

Domainr’s buttons are styled using a sliding-door technique with a single CSS sprite background image. By this time we were starting to test against Safari 4.0 and Firefox 3.5, which also demonstrated similar visual errors when using their full-page zoom features.

The solution ended up being simple:

Vertically align the left and right background images for the button in the sprite.

It’s a palliative fix, but works. We were able to keep the single sprite image, and not introduce iPhone-specific CSS or hack WebKit. In the end, there were other benefits to the fix. Despite redundant image data, aligning the background slices eased the process of updating the sprite image for new button variations.

Last night I had another conversation with my friend John, who’s a director of engineering at a big game compaony.

I was relating has been building an integration test suite for our web application. We put it together in about three days using open-source tools like Cucumber, RSpec, EmailSpec, WWW::Mechanize and assorted home-grown or adapted bits of Ruby and Python. It’s great—we’ve got full black box testing of our APIs, pages and email. It tests the entire stack from HTTP to email.

John really really liked the idea, and expressed (again) how it’d be great if the game industry had the same level of cooperation and diffusion of code & ideas.

Since part of the stack wasn’t written in Ruby, we couldn’t make assertions by hooking into lower-level parts of the code. We had to test entirely via external APIs.

Since the original conversation that spawned OpenID, I’ve observed the rise of real identity versus obscuring it behind a [nonsensical] username @ someservice.com.

The fact is, the OpenID non-pattern has overwhelmingly ignored in favor of standard email + password signup. Hearteningly, the user experience of registration has been largely normalized. There are observable and copyable best practices here, that require neither a spec nor educating the user.

Basically, OpenID—as it is now—is irrelevant.

There were major lessons learned, but they were social rather than technical. The original problem that OpenID was conceived to solve has been supplanted by services like Disqus, Intense Debate and TypePad Connect.

The non-problem that OpenID [2] was intended to solve was putting a user in charge of how (and if) their identity online was centralized.

I say non-problem because it was already solved. Most people overwhelmingly didn’t care, and the people who did—knew how to set up multiple email addresses or use different usernames/passwords.

If email was invented today, it’s not to hard to imagine that we’d grant permission for a service to send us email using a mechanism similar to OAuth. Communicating with someone (or thing) via their preferred channel is just another ACL.

So OpenID won—not because it was the solution, but because it helped us understand the fundamental interaction problems that previous auth systems failed to address.

“Distributing the cash fairly would require knowing how much people actually listen to specific tracks, which means software embedded in players or on users’ machines. And how many consumers are going to be excited about this?”

This software already exists—last.fm’s Audioscrobbler application tracks and reports the listening habits of 5 million people. A small fraction of the population, but strong evidence that users will trade a certain level of privacy in exchange for entertainment value.

Earlier this evening, I received an NDA from a potential client. They’re a big company, so it came with some understandably bulletproof language, and was signed by an exec in their legal department (via a pasted-in scan of their signature).

The instructions that accompanied the NDA said I should sign and print two copies, mail one, and fax or email a copy back to them.

We don’t have a fax machine, let alone a landline, so we typically just paste in our signatures, create a PDF and send it back. Unfortunately, it wasn’t that simple. Fortunately, Adobe’s silly PDF protection was felled quickly by the OS X Print command.

Attempt to open original NDA from client in Adobe Illustrator.

Fail because of PDF password protection.

Open original NDA in Preview.

Print, and Save PDF from within Preview.

Open printed PDF in Adobe Illustrator.

Fail because of character-set mangling.

Open printed PDF in Preview.

Save As generic PDF-X3 or whatever.

Open exported PDF in Adobe Illustrator.

Fail because of charset mangling.

Smoke cigarette, bitch, drink whisky, etc.

Create new multipage document in Adobe Illustrator.

Use the Place command to put each page of exported PDF into new document.

Empathy-based values are opposed to the pure self-interest of a laissez-faire “free market,” which assumes that greed is good and that seeking self-interest will magically maximize everyone’s interests.