She states exactly what I have maintained for a long time: QR codes are great if they are transparently integrated into the phone, as they are in japan where they are immensely popular and rightly successful. If the reader is separate from the handset's camera function requiring the user to learn a new set of behaviour to use it, it will fail - particularly when that path is longer than the path to the camera.
I see three possible ways to present a QR reading application:
- The best - you take a photo as normal, the phone tells you there's a link embedded in it, done.
- Second best - press whatever button(s) you need to get to the camera function, one of the options (next to 'take a pic' and 'record a video') is 'read a QR code', click it, done.
- Won't get used - any function that does not sit on the camera menu. This includes, sadly, Java apps.
If the app is awkward to use, or it is not stored where the user expects it, the user won't use it. If the app is easy to use and is stored where the user would logically expect it, the user might use it, if they remember it's there and it offers sufficient value.
Sadly today, that means 3rd parties can only offer this functionality on some smartphones, ie. well under 10% of the market. For all other phones, the manufacturer must put it in the firmware - at the operator's behest (pioneered by DoCoMo in Japan) or their own.
I'd love to see a world where Java could be used for this type of phone extension effectively, but it isn't an area even being addressed currently as far as I can see and certainly it isn't practical with today's phones. VCs should perhaps bear this in mind before pouring cash into the latest bandwagon.