Design Rule #005—Follow the Specifications

Twitter Updates

HashTags

#PKNsf
San Francisco PechaKucha Night
#IXDAsf
San Francisco IxDA

Blogroll

Years ago, when I was the Technical editor of CADENCE magazine, reviewing the latest hardware and software products every month, I came to the conclusion that engineers don’t read specs.

The conclusion was not based on talking with any engineers or product managers about the subject, just on my own observations of comparing product features—especially those relevant to interoperability—against the actual specifications (or excerpts) I could get my hands on.

I have held this conviction ever since, and although I don’t get to test it frequently, I see ample evidence of it, and whenever I do get the chance to talk to engineers about specs, they always uphold my maxim.

The widely practiced alternative is to copy how another few products have implemented the specification. But since none are complete, only parts of the specification get implemented, and not always completely or correctly.

The natural result is that the products are less capable and far less interoperable than the specification authors intended.

This hurts the consumers of the product, and it hurts the company who made it, because they have failed to deliver a complete product that operates well—inevitably leading to disappointment and frustration, and fewer sales.

I was reminded of this yesterday when I had a new batch of personal business cards printed, with a rectangular Data Matrix barcode, holding the URL to my vCard.

But when I fired up my half-dozen iPhone 2D barcode scanners, none of them succeeded.

Perplexed, I tried them on an older card, with a much larger Data Matrix that held the whole vCard. Success! Even though it was blurry and I had forgotten the white space between fields, at least it decoded.

After much experimentation and tweaking the zoom setting of several apps that used the same engine, I failed completely. Trusty-old RedLaser, which I swear had worked on this very code before, failed, too. Worse, when I read their post on supported code types, it was clear they had deliverately disabled all Data Matrix decoding (not just rectangular ones) because they “aren’t associated with store products.” Funny, though, I have a tube of Crest with a Data Matrix, so this isn’t really accurate.

I searched online for references to one that might succeed, and was reminded of NeoReader, which I had once used, then discarded for some reason.

Of the seven 2D barcode scanners now on my iPhone, NeoReader is the only one that can scan my business card. Alas, neither it nor the iPhone can extract the contents of that URL and feed them to the Contacts app, as would seem natural.

A good amount of frustration was caused for me simply because the developers of these apps either didn’t read or read and chose not to fully implement well-known specifications:

  • The international ISO standard for Data Matrix
  • The RFC for vCard
  • The international GSN standards which call for support of Data Matrix on store products

I’m convinced the only way this sorry state of affairs will improve is when universities start teaching engineering students how to find and read specifications.

A whole class on this subject for mechanical, electrical, and software engineers, architects, and other designers would be a great idea (although it alone would not be enough). The first step is for the engineering libraries to keep the more important standards on the shelves. (Many, though not all, are too expensive for students to afford on their own.)

Author: Peter Sheerin

Peter Sheerin is best known for the decade he spent as the Technical Editor of CADENCE magazine, where he was the acknowledged expert in Computer-Aided Design hardware and software. He has a long-standing passion for improving usability of software, hardware, and everyday objects that is always interwoven in his articles. Peter is available for freelance technical writing and product reviews, and is exploring career opportunities in interaction design. His pet personal project is exploring the best ways to harmonize visual, tactile, and audible symbols for improving the effectiveness of alerting systems.

1 thought on “Design Rule #005—Follow the Specifications”

  1. Hi Pete! Just wanted to pop in and say that your memory about RedLaser is a bit off — we’ve never had great Datamatrix scanning. Barcode scanning is actually a pretty tough problem—particularly for codes like Datamatrix—even if you have the specifications! We need to deal with real-world situations like shadow, printing errors, glare, and poor device cameras … and do this across hundreds of devices.

    In RedLaser, we have the code from the best-in-class open source library for Datamatrix … and it just isn’t very good, as you’ve discovered. This is something we want to remedy someday, but relatively low adoption for Datamatrix puts it lower on our list.

    QR codes are vastly more common for uses like the above—that’s what we recommend for business cards.

Leave a Reply