Firstly, you're eating up your margin for error. This seems fine when you're scanning with an iPhone 4 from a galley proof in a brightly lit office, or from your calibrated monitor. It becomes a big problem when users are scanning creased newsprint on a poorly lit train, from a dirty TV at the wrong aspect ratio, or with a crappy cameraphone with a scratched lens.
Secondly, you're pissing away the inherent call to action in a QR code. Many of these more styled QR codes are barely recognisable as such. Either you reduce your scan-through rate because people don't know that your multicoloured blob is actually a QR code, or you have to explicitly state "this is a QR code, you can scan it". I hope I don't have to explain why those are bad design outcomes.
If you hire designers, this is a brilliant litmus test. Anyone who thinks that this is a good idea is incompetent, plain and simple. They will make decisions which are pretty, but will annoy your customers and cost you money.
The Disney codes are cool - they are creative in a way that doesn't compromise the readability of the code. The others just seem like gigantically bad ideas.
It's hard enough convincing people to use QR codes - the more you violate the spec the more devices will stop reading it.
The "Barcode Scanner" app in the Android market had trouble with the first one, and the one with the panda in it. Google Goggles had no trouble with any of them.
QR codes use Reed-Solomon error correction which means between 7% and 30% of the image data can be lost but the encoded text will still be readable. Digital TV / radio broadcasts use a similar system.
These examples are taking a slice of that redundancy and replacing it with a design. This is a bit like using typography to make a URL look nicer but harder for a human to read.
All the paperlinks ones scanned almost immediately (redlaser here, could use a better one if anyone knows any). The rest usually took some jiggling and trying for a minute or so. And the Disney ones were just too small.
I'm torn between NFC and QR codes... or at least, I was. I've seen some really spectacular exampled of QR codes recently - while in Korea, and most recently via paperlinks. I was initially skeptical of the user experience with QR codes, but after watching a paperlink demo, it's like magic.
We're about to finalize our logo, and immediately afterwards, they'll have one more happy, paying customer.
We at Paperlinks appreciate the support! With NFC and QR codes, I don't think it has to be either/or. NFC is a fantastic technology that truly makes real world hyperlinking even more seamless. We just need more phones with NFC readers on them. In the meantime, there's QR codes, and companies like Paperlinks are trying to make them as easy and effective to deploy as possible!
There's a lot more cool stuff yet to be done with QR codes!
I'm going to announce this properly sometime this week when we've got a nice demo video, but we just (and I mean JUST) launched a new webapp for people who want to have flexible QR redirects with analytics.
Firstly, you're eating up your margin for error. This seems fine when you're scanning with an iPhone 4 from a galley proof in a brightly lit office, or from your calibrated monitor. It becomes a big problem when users are scanning creased newsprint on a poorly lit train, from a dirty TV at the wrong aspect ratio, or with a crappy cameraphone with a scratched lens.
Secondly, you're pissing away the inherent call to action in a QR code. Many of these more styled QR codes are barely recognisable as such. Either you reduce your scan-through rate because people don't know that your multicoloured blob is actually a QR code, or you have to explicitly state "this is a QR code, you can scan it". I hope I don't have to explain why those are bad design outcomes.
If you hire designers, this is a brilliant litmus test. Anyone who thinks that this is a good idea is incompetent, plain and simple. They will make decisions which are pretty, but will annoy your customers and cost you money.