Irvin Wilson

There are advantages and disadvantages that need to be considered if you intend to use shortened URLs with your QR Codes (or other 2D barcode). For anyone unsure of what a shortened URL is think "Twitter". When you enter a URL in twitter they automatically create a new "short" URL that points to your intended target. This is the type of URL I'm referring to here. First let's address a couple of shortcomings of QR Codes that shortURLs can help with.

#1 - QR Codes are permanent. Granted you can change one that's on your website or some other electronic medium but what about the ones you printed on 2,000 brochures? Or a print ad of some sort? A window sticker? These are now "in the wild" and cannot be easily changed. A shortURL however is a pointer of sorts and can be changed. So if your QR Code points to a shortURL and that URL forwards to a web page that changes then all you would need to do is point your shortURL to the new destination location. If you try to do this directly you'd have to forward the actual original destination on to the new address. This might not be so bad but what if the original page should stay? Perhaps your QR code once pointed to 2011 info and should now point to 2012 data. By leaving QR Codes out there that point to outdated information you might appear to be neglecting your site or your commitment to providing up-to-date info to your customers. Obviously this is not good. As you can imagine, a code pointing to outdated information could leave the wrong impression.

#2 - QR codes can get difficult to read. Consider the following two QR Codes:

Right away it's obvious that there is a difference in the complexity of the two codes. The first one points to a URL that is fairly short on its own - "http://iewilson.com". The 2nd code, however, points to a much longer URL - "http://www.easyrentaltools.com/index.cfm?event=article&title=mortgage-insurance-vs-mortgage-life-insurance". While this URL is pretty long it's not unreasonably so. The point is the longer the URL (or other data) encoded into your QR Code the more complex the code becomes. This is important because code readers on smart phones are not perfect. Sometimes it can take a little effort to get a code to work. By using a short URL in the code itself that then forwards to a longer destination URL you can cut down on the frustration of getting your codes to work properly.

On the down side there are a couple of very important things to consider as well. First, does your viewer know what a shortURL is? It's important to remember that most code readers show the person who clicked on the code where it is they're about to be sent. If the user sees your domain then they are probably pretty comfortable allowing the click to go thru. If they see a shortened URL and are not familiar with them then perhaps they'll abort the process. If the user is not confident in the source of the code itself they probably SHOULD abort the transfer. A random QR Code might point to some resource trying to break into the software on their phone for instance.

Secondly some of the software used to read QR Codes might stop the process on its own. There are a lot of readers out there and they don't all work the same. The phone's browser too has to work with the process. There are a lot of "ifs".

QR Codes are powerful tools however. I'm simply recommending that some thought go into their usage. In a nutshell I'd say that if the intended target is both short and permanent (e.g. your home page) then point the code directly there. If the intended target is long or subject to change then use a short URL but one from within your own domain. It's a simple matter to code a page that will take "www.yourdomain.com?e64H5" and forward clicks to "www.yourdomain.com/some_longer_intended_target_page". By doing this the user will see your domain and will have a greater comfort level than if the link is to an unknown domain. Plus, as the site owner, you can retain control over your URL.

Here we'll take a very basic product page and show what schema.org microdata might look like for our product.  First we're going to wrap everything that has to do with our product with an html div tag marked with "itemscope itemtype="http://schema.org/Product".  This tells the visiting search engine that what is contained within this tag has to do with some sort of product.  Adding the itemscope and itemtype markup will not affect what our page looks like to the viewer.  It's there simply for the search engines.  Our very first lines that will wrap around the entire product entry will look like below.

<div itemscope itemtype="http://schema.org/Product">


</div>

Our next section is within the div tag and is simply a span of text that identifies the name of our product. In the above we said that we're using an itemscope within our div with the type of item being "product".  From here we'll use item property markup named "itemprop" which will further identify pieces of our product page. First, the name of our product.  This uses an itemprop of "name".

<div itemscope itemtype="http://schema.org/Product">


<span itemprop="name">XYZ brand camera model 123</span>


</div>

Next on our list is an image of our camera. The added markup here works the same way as above.  In this case we're going to take a standard image tag and add itemprop markup labeled "image". Continuing to build our page now the html looks like:

<div itemscope itemtype="http://schema.org/Product">


<span itemprop="name">XYZ brand camera model 123</span>


<img itemprop="image" src="camera123.jpg"/>


</div>

There are many other item properties we could add but we'll do two more to complete the example.  The first will be a very common "description" itemprop.

<div itemscope itemtype="http://schema.org/Product">


<span itemprop="name">XYZ brand camera model 123</span>


<img itemprop="image" "src="camera123.jpg"/>


Camera description:<span itemprop="description">This camera is auto everything and takes great photos!</span>


</div>

Note here that we did not include the words "Camera Description" in the span that describes our camera.  Keep in mind that the markup itself tells the search engines what is contained in the tag.  We want to keep this enclosed text as "on target" as we can.  Consider that this text might show up in a search result.  Do we want to waste two words with "Camera Description" or do we want to dive right in to the actual meaningful text?  Keep this in mind when building microdata.

In the last section of our simple example we want to show how microdata can be "nested".  In our example so far it may seem like the primary div with itemscope and itemtype are our outer wrapper for everything about this product and that all items within will simply be various property types (itemprop).  Just like standard html however div tags can be nested along with their appropriate schema markup.  To show this we will create a new div, internal to our outer one, that contains an itemtype of "offer".  Offer is placed this way because "offer" has subsets, in this case namely price and whether or not in stock. Our html now expands a bit to include this new div.

<div itemscope itemtype="http://schema.org/Product">


<span itemprop="name">XYZ brand camera model 123</span>


<img itemprop="image" "src="camera123.jpg"/>


Camera description:<span itemprop="description">This camera is auto everything and takes great photos!</span>


 <div itemprop="offers" itemscope itemtype="http://schema.org/Offer">


 <span itemprop="price">$245.00</span>


 <link itemprop="availability" href="http://schema.org/InStock" />In stock


 </div>


</div>

With this last bit we've added a new div within our outer one that declares that it repesents an itemscope and that it has an itemtype of "offer".  Offer has a couple of properties of its own which are added just like we did above with name, image, and description.  Since this new div is nested within our outer one that pertains to the product as a whole we now have a complete description of our camera including our price and whether or not it's in stock.

It's important to note here that these properties and their meaning are not just something to be left up to a development team.  Decisions must be made on how this is going to be implemented from a business point of view. To non-techinical readers the above may look daunting.  It's critical however that the business/marketing team(s) participate in this process.  There's much more to microdata than what I've shown above.  The point here was to not just show a simple example but to display the logic behind schema.org markup.

In this first of two parts we'll go through an example of web site microdata from a non-technical point of view.  In part two we'll show actual schema.org microdata markup.

Let's use a web page that contains product information for our example.  Further, while certainly all of the text on our webpage is important let's say that certain items are "extra important" since they describe some detail of our product, whether it be part number, product description, manufacturer, colors/sizes available, etc.  Using a VERY simple example perhaps our page looks like this:

Widget ABCD blah blah blah blah blah blah blah blah blah blah important item blah blah blah blah blah important item blah  blah blah blah blah blah longer important item blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah important item blah blah blah blah blah blah blah blah blah blah important item blah blah.

We've used bold just to emphasize the text of our "important items".  An actual page may or may not have any bold text. It's placed here just to help with the example. Our "important items" might be descriptions, part numbers, etc. as mentioned in the first paragraph.  The remaining text might be things that are on every page regardless of product like navigation items, ads, etc. For this example we'll just say that it's text that is not directly related to the product on this page.

With microdata what we're going to do is place an invisible "wrapper" around this web page that will allow us to "pick out" these important items and clearly identify them for search engines.  The viewer won't see anything different but the search engine spiders will. Taking our original text let's show in the roughest form what this looks like.

[Begin wrapper - type = product][begin important item]Widget ABCD[end imporant item] blah blah blah blah blah blah blah blah blah blah [begin important item]important item[end imporant item] blah blah blah blah blah [begin important item]important item[end imporant item] blah blah blah blah blah blah [begin important item]longer important item[end imporant item] blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah [begin important item]important item[end imporant item] blah blah blah blah blah blah blah blah blah blah [begin important item]important item[end important item] blah blah.[End Wrapper]

In the above example I've purposely left out any sort of microdata or html and simply used blocks of text as a visual aid to show how we "wrap" around our important items and the page as a whole. It's important to repeat that what our viewer sees has not changed.  If we had used real microdata formatting these wrappers would be invisible unless the viewer looked at the underlying html.  Our visiting search engine spider however now has a very clear roadmap compared to the beginning example of what the important items are for our product(s). Additionally, unlike our example above, on a page that is using real microdata each of these wrappers is identified by type so that the search engines know which is the part number, which is the manufacturer, which the descripton, quantity in stock, etc.  From a "product page" point of view this is precisely what we want. By providing this information in a form the search engines can be confident in we are helping them help us!

In part two we'll take this further with actual code.

Google, Bing and Yahoo! hardly seem like partners and yet working together they have announced schema.org, a common vocabulary for structured data markup of web pages. To a business owner or business unit leader of a large company this should mean something.

Leaving aside competitive formats, schema.org represents a method for a machine to more accurately determine what your web content is all about.  This is important because it is machines (or software) that scour the web gathering and cataloging data to be presented to human viewers in search engine form.  Whereas a human can very quickly determine the subject matter of a web page, machines have a more difficult time.  Certainly they've gotten very good at it over the last decade but there is still a lot of holes and guesswork when it comes to identfying what any given webpage contains.

Enter schema.org.  By taking a standardized identification structure and "wrapping" it around your web content you can make crystal clear to the search engines what it is that is on any given page, whether product data, services offered, specialties, business hours, etc.  This same markup also identifies specifics for an individual, group or organization.  In short it is a very powerful machine readable identification/information system or framework.  And, this is all done "behind the scenes" without affecting the look and feel of your web property from a visual point of view.

The power of this new standard should not be underestimated.  Many of the people reading this already use a competing format on their website(s) and probably aren't really aware of it - the Facebook "like" button.  This ubiquitous button is part of Facebook's Open Graph protocol.  As a business owner you don't really need to know that but it's important that you understand the power of these new tools.

In short, the search engines devised schema.org and microdata to help you help them.  The beauty of that is that it's a complete circle.  By helping them they in turn help you!