With its first four episodes the 361 degrees podcast has already established itself as my current favourite tech podcast. Free-flowing discussions, but at the same time very concise, with very different opinions, and always with things that get me thinking.
While I would appreciate a bit more of a “nerd-factor” (Ewan McLeod), NFC, the topic of epsiode 4 (the best one so far) is something that should affect all of us in the mid-term, including the normob majority out there. And I’m sure they’ll get around to topics eventuall where I appreciate the focus on the essential questions over technical terminology.
A lot of essential questions were raised in the podcast. I strongly urge you to spend the 20some minutes it takes to listen to it.
Here are just a few thoughts I had while listening:
I was first of all disappointed that the discussion didn’t start with the explanation that NFC stands for “Near Field Communication”. With the current focus on mobile wallets, it helps to remember this to not lose sight of the bigger picture.
Regarding mobile wallets: If my credit card or debit card is integrated into my smartphone, then there needs to be a backup option for handling payments when the battery has run out. Not being able to pay e.g. for the last taxi, train ticket or tank of gas at the end of a long trip? Simply not an option. The first time this happens to a customer, he’s back to plastic. Plastic card in addition to the mobile phone? Not for having it with me at all times. Maybe a chip that allows being read by an active reader in addition to active communication, replacing the magnet strip/chip in the credit card. Would mean that the dual infrastructure of readers for mobile phones with verification, authorization in the phone and for dumb cards would need to be there perpetually, though.
When authorization for payments is done on the phone, any application for this would need to be auto-started by the phone OS upon receiving a request by a payment terminal. Digging around in the menus for the correct app is not an option. There are a lot of open questions about payment via mobile.
The term ‘mobile wallte’ should already be an indicator that there are more obvious candidate for integration into smart phones in connection with the payment process. Loyalty cards, discount cards etc. are, by their very nature, low-security, simple things. All that’s stored on them today are a few numbers. There’s no need for anything in the way of authentication or application integration there for them to work in principle, and integration into mobiles would provide the very real benefit of freeing up space in the wallet. People could carry dozens or even hundreds of loyalty cards. Sure, this would reduce the stickiness per retailer a little, but on the other hand most retailers would jump at the opportunity to adding customers to their reward programs (and getting data to mine). Adding things like the possibility to check awarded points on the mobile, cashing these in for rewards etc. would be easy extensions.
The most interesting applications for the time being, to me, are all non-payment related: things mentioned in the podcast such as smart posters that transfer information about the advertised item, or “tappable” customer feedback (tap your phone to a picture of a happy, neutral or sad face at the door when leaving a shop) and, more generally, other tappable objects. Lots of really interesting possibilities there, ones that don’t need to manouver through the thicket of banking standards, security of POS devices etc.
And how about a NFC/RFD label on the next piece of electronics I buy that, when tapped by my smartphone, transmits the web address of the manual and the warranty conditions? For warranty cases and customer care questions? How about if the address already contained all the necessary information for the contact, like device type, serial number, possibly even (with more active integration), a device fail state? There are great possibilities there for easing the life of the customer, and for initiating additional interaction.
And lastly a short note on QR codes: Rafe Blandford mentioned in the podcast that these are a fail in his eyes because the user needs to first start an application to read them. He’s right that the need for special applications in the first place (how many users are going to install them?) and the need to start these separately are great hurdles. Why then don’t the manufacturers include automatic QR code scanning in the camera application? The camera on my phone has face recognition, so clearly there’s already an infrastructure for background scanning of the camera data. QR codes can’t possibly be harder to recognize than faces. This would bring the workflow down to: see QR code, start camera (hardware button on my phone, but with others it’s at least a more practiced thing than starting up a special app), point at QR code. There’s nothing wrong wit the codes themselves: they are both a valid container for information and a nice visual indicator for the fact that information is there.