What to put into your daily Mobile 2D Code

2008/07/16 — 1 Comment

I have been reading many articles about comparisons of different 2D Code formats lately and am always wondering why people make such big waves about pixel-efficiency and so on. Isn’t it much more the content and the accessibility of the content of 2D Codes that matters? And not space-efficiency-differences of a couple percent?

I am assuming that the basic idea of 2D Codes is to make rich content easily accessible to consumers wherever they see a Code. The consumer has a 2D Code reader installed on a mobile device or has to be able to easily install a reader application and can then reach out, with the Code as link, to some predefined information.

The best situation for a consumer would be to download and install a 2D Code reader once and from thereon he would be able to interact with any 2D Code he sees. The content is unique to the Code but accessing the content is done in an easy and defined way.

That sounds pretty straight forward, doesn’t it? Consumer friendly, streamlined, simple. Nobody would have to reinvent the wheel over and over again and the user experience will be in all cases similar and convenient.

This is however not reality and I want to go a little bit into details on how 2D Codes
are used and what could be done better.

What can the content of 2D Codes be?
There are basically three different ways to encode information into 2D Codes and make them accessible for a consumer. The content of a 2D Code can be

  1. The complete information that the consumer can interact with. A whole text for example.
  2. A ‘number’ that can be looked up somewhere. The look-up returns either the content or a link to the content. Similar to the old fashioned 1D-Barcodes on a product in store for example.
  3. A link to information. Just like a link you click on a website. After scanning the Code the contained link is leading to content.

These different approaches have various advantages and disadvantages for the consumer, the information creator, the information host and the whole ecosystem.

Encoding the complete information
The nice thing about most 2D Code formats is that you can basically put any information in it. It can be any kind of text, numbers or even bytes of little images if desired. Use-Cases are texts, vCards etc. The decoding application must however know how to deal with these, in some cases big, amounts of data as it can vary widely. The advantage of this kind of content is that there is no Internet access required to get to the content of a Code as it is directly available. The big disadvantage of this kind of encoding is that the information is simple and plain static. Once you print the code you will not be able to change the containing content. You can also account the fact that the decoding application has to know how to handle the widely varying content as a disadvantage. I call these Codes ‘Static 2D Codes’.

Encoding a ‘number’
A simple number or alphanumeric identifier produces usually the codes with minimal physical size due to the minimal amount of data. There are codes containing simple patterns like ’84236293′ or more advanced ones like a 32bit ID. These Codes provide the ability to act as a link to any information hosted somewhere in the WWW. Of course you have to have net-access and the application uses airtime to exchange data with a centralized service that can lead to the specific content. The content can only be retrieved after telling a Server the unique number, the server then returns the requested information. The content is variable as the information ‘behind the number’ can be exchanged by the provider. The biggest flaw of this kind of encoding is that only one single application knows what to do with decoded number in the Code. The format of the Code might be the ‘open standard’ QR-Code but the application of provider X does not know what to do with the content of provider Y as it is not able to access the information behind the Code. I just had an example where a friend shared an EZcode he found in Europe with me. As the Code was created by an European vendor the decoding application from the vendor of my EZcode scanner returned ‘Invalid barcode‘ after decoding the valid image of the Code. There is simple and plain no compatibility. I would have had to install the application of the European vendor that knows what to do with the Code number. Even though my installed application can decode the Code it doesn’t know how to handle the content. This is the worst case scenario for a consumer. I call these Codes ‘Number 2D Codes’.

Encoding a URL
Encoding a URL into a Code produces relatively small Codes. The content can be something as short as “http://b.domain.net/abc12″ and can point to any dynamic content in the web. URLs are a standardized way of accessing online content and can be interpreted correctly by a almost all 2D-Code readers. The content is interchangeable as the content of the encoded ‘website’ can be changed as desired. If the reader application is designed to just open the mobile browser and load the URL, the phone’s browser handles the display. This allows to deploy rich content easily and fast as today’s mobile browsers can handle content from text over images to videos. The user experience is the same as when surfing the web and the content delivery is handled by the device’s standard interface. This kind of encoded data provides the most easy and user friendly delivery of mobile content. Codes are compatible with other reader applications and short URLs ensure small Code dimensions. I call these codes ‘Mobile 2D Codes’ as I can not only access them with my mobile device but I am also really ‘mobile’ as I am not stuck with a certain vendor.

Different 2D Code formats and their abilities
Of course not all 2D-Codes can contain the same amount and not even the same kind of data. I am not going to evaluate all the details in depth as other people and institutions have done this various times but I want to point out certain items. Please keep in mind that this list is not complete and that I did not do an excessive research on all the different possibilities with the listed Code types.

Proprietary formats for ‘Number 2D Codes’ like ShotCodes
ShotCodes are Codes in a proprietary format that can only be read with a proprietary reader application. They can only contain a very limited amount of data and are ‘Number 2D Codes’. They look cool but they are neither open nor can I read them with open reader applications.

Proprietary formats for ‘Static 2D Codes’ and ‘Mobile 2D Codes’
There are numerous proprietary 2D Codes that can contain a big amount of encoded information and can thereby be used as ‘Static 2D Codes’ and ‘Mobile 2D Codes’. Personally I believe that proprietary formats are almost as hindering for a good user experience as ‘Number 2D Codes’ as they require either a specific proprietary reader application or or sub-licensed application. This generates a walled garden for application developers who would like to interact with these codes but are locked out by licensing issues or simply the costs of a license. On top of this the proprietary formats, such as EZcodes are often used as ‘Number 2D Codes’ which destroys all inter-compatibility.

Open formats and standards for 2D Codes
I like the idea of open standards and open interfaces as it guarantees the highest amount of compatibility and the richest eco system. There are open standards and formats for 2D Codes, like the QR or Aztec Codes, which can be used to encode any kind of information into 2D Codes. As the standards are open and available they can be applied simple and effective with the guarantee to offer a service that can be accessed by anybody who has a reader that supports the same open standard. If you encode a URL with an open format you are generating an open ‘Mobile 2D Code’. This will most likely reach out to the most potential consumers. After all, what does a URL offer if it is encoded in a format that is not readable by the majority of the reader applications? I believe open standards are the way to go. Some people might say that most open 2D Code formats look boring and proprietary formats are stylisher but I count the simplicity and neutrality of QR-Codes for example as an advantage as they can be applied in any environment and will not look misplaced because of non matching colors or design.

Codes and money
Of course the dream of most companies is to have a proprietary system that is used by 100 percent of a target group. This ensures that no competitor will be able to ‘steal’ users and anybody who would like to use the closed system to push content to the world would have to pay license fees etc. This is the situation with the most disadvantages for the end user. There would realistically be no eco system. It would be a monopoly with no prices or offers from other vendors to choose from. The ideal world would be open standards for 2D Codes with a variety of content providers who provide their content in form of ‘Mobile 2D Codes’. Every reader-application could decode any code and the user would always be directed to the correct content. ‘Hassle free’ is the keyword here. Why would anybody use proprietary Code formats or readers if the Codes can not be decoded by anybody outside of the proprietary system without installing yet another reader or creating yet another user account with some service?

A few last words
Of course this whole document reflects only my personal opinion based on facts and personal experience gained during the work with 2D Codes and various researches I made. I encourage you to reflect over the information your read here or anywhere else and decide for yourself what makes sense and what is just gibberish. I also want to disclose that I am personally working on a project that uses open ‘Mobile 2D Codes’. We decided to use this technique after various researches and experiments and of course for the reasons listed here. You can find it at http://www.snappr.net.

Additional information
QR code is trademarked by Denso Wave, Inc.
QR-Codes at Wikipedia
Aztec Codes at Wikipedia
EZcode is developed by ETH Zurich and licensed by ScanLife additional information on their site
EZcode on Wikipedia
ShotCodes were developed by Cambridge University and are used by OP3 B.V. Details here
ShotCode on Wikipedia
Any other product names or descriptions are copyright by the respective owner
Plus many more sites that offer comparisons of 2D Code formats, additional information about the mentioned codes, companies etc. just. Google it! ;)



  • Andrew

    A thorough article.

    I have this suspicion, based purely on hunch, that more pixel efficient code types will produce less errors on phones with poor cameras. Maybe I should do some tests!

    Another thing I’ve found is that mailto: and tel: links work well when encoded into 2d codes.