POSH: Semantic Markup for Driving Directions

Posted: June 11, 2007 Comments(7)

One of my all time favorite Web apps to use has to be Google Maps. I find myself using it not only because the data provided is that much more accurate than other services such as MapQuest (which has completely let me down repeatedly in the past), but because the service itself is becoming more multipurpose by the day. Unfortunately, when it comes to Google, applications aren’t always implemented with Web standards or graceful degradation in mind. Google apps are quite debilitated — if at all functional — with JavaScript disabled, and downright scary with no CSS.

Moving on, Google is using tables to mark up their driving directions provided via Google maps, but in my opinion, there’s a much better way.

[Image] Screenshot of Google Maps directions

There is actually quite a bit of information provided in simple driving directions. For the purposes of this article, I’d just like to focus on the directions themselves, as opposed to the content offered before and after, as well as the maps that are (usually) included.

Driving directions at their core

At the very least, when providing driving directions, you’re compiling an ordered lists of steps that need to be followed in order to navigate from point A to point B.

<ol class="driving-directions">
  <li>Head southeast on Crossgates Mall Rd - 0.2 mi</li>
  <li>Turn left onto the Washington Ave Ext E ramp
    to I-90 Thruway/I-87 - 407 ft</li>
  <li>Merge onto Washington Ave Ext - 0.9 mi</li>
  <li>Continue on Washington Ave - 3.9 mi</li>
  <li>Turn right at Robin St. - 417 ft></li>
</ol>

While a single ordered list could be considered acceptable, there is quite a bit more information provided that has semantic value. For instance, in each step of the ordered list, there is detail given as to what actions should be taken, as well as a measure of distance. To me, this is a good place to include a definition list. It seems fitting to mark up this pair of data using a definition list as you’re relating both the action and the distance traveled. The distance traveled is a direct result of the action being taken so a definition list would work well.

<ol class="driving-directions">
  <li><dl><dt>Head southeast on Crossgates Mall Rd</dt>
    <dd>0.2 mi</dd></dl></li>
  <li><dl><dt>Turn left onto the Washington Ave Ext E ramp
    to I-90 Thruway/I-87</dt>
    <dd>407 ft</dd></dl></li>
  <li><dl><dt>Merge onto Washington Ave Ext</dt>
    <dd>0.9 mi</dd></dl></li>
  <li><dl><dt>Continue on Washington Ave</dt>
    <dd>3.9 mi</dd></dl></li>
  <li><dl><dt>Turn right at Robin St.</dt>
    <dd>417 ft</dd></dl></li>
</ol>

To me, using a combination of an ordered list as well as integrating a definition list results is a much more semantically rich set of driving directions.

A quick note about address

From time to time, I’ll come upon some markup that uses address incorrectly. address is defined as:

The address element may be used by authors to supply contact information for a document or a major part of a document such as a form. This element often appears at the beginning or end of a document.

Without reading the definition, I can understand why some people may assume that address is used to mark up a segment of data that represents any address, but in reality, it is used to distinguish how to contact those responsible for the document. It isn’t applicable to use the address tag to mark up the street address of each step here.

What about imagery in driving directions?

Many times, driving directions include images which help to classify what information each instruction is providing. There may be an arrow indicating which direction to turn, an interstate sign, or something like a traffic light to indicate a future encounter. How should these images be included? In my opinion, this is one of the times where semantic image use should be looked into. Taking a step back and thinking about it, these images are unique in that they aren’t part of the site design. They’re in place to convey pieces of information to the reader. Making the adjustments to our example:

<ol class="driving-directions">
  <li><dl>
    <dt>Head southeast on Crossgates Mall Rd</dt>
    <dd>0.2 mi</dd></dl></li>
  <li><dl>
    <dt><img src="images/turn-left.jpg" alt="Image signaling
    a left turn" />Turn left onto the Washington Ave Ext E ramp
    to I-90 Thruway/I-87</dt>
    <dd>407 ft</dd></dl></li>
  <li><dl>
    <dt>Merge onto Washington Ave Ext</dt>
    <dd>0.9 mi</dd></dl></li>
  <li><dl>
    <dt>Continue on Washington Ave</dt>
    <dd>3.9 mi</dd></dl></li>
  <li><dl>
    <dt><img src="images/turn-right.jpg" alt="Image signaling a
    right turn" />Turn right at Robin St.</dt>
    <dd>417 ft</dd></dl></li>
</ol>

Alternatively, it would be argued that the dt provides the instruction and the image is merely redundant. I think that is the decision of the developer, but I do feel it is more applicable to include these ‘helper’ images in this way as opposed to being a background-image to the dt. What do you think? Should an element be classed and provided a background-image as opposed to including the image inline? What other ideas do you have to improve the example?

Get my newsletter

Receive periodic updates right in the mail!

  • This field is for validation purposes and should be left unchanged.

Comments

  1. @Colin Devroe: I was hoping someone would bring up microformats, but I didn’t expect it to happen so quick! I think including microformats in this example is the perfect next step. It adds that much more semantic value to the document which is what we’re striving for in the first place. To read more about including microformats in this situation, be sure to check out http://microformats.org/wiki/adr. There’s lots of information provided about adr

    adr (pronounced “adder”[…]) is a simple format for marking up address information, suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. adr is a 1:1 representation of the adr property in the vCard standard (RFC2426 (http://www.ietf.org/rfc/rfc2426.txt)) in XHTML, one of several open microformat standards. It is also a property of hCard.

  2. “To me, using a combination of an ordered list as well as integrating a definition list results is a much more semantically rich set of driving directions.”

    why, exactly? if it looks like a table, smells like a table and tastes like a table, a table is probably an appropriate way to mark something up. imho, of course.

  3. @ patrick h. lauke

    I don’t think the instructions from Google can be described semantically as a table. An ordered list is semantically what it is. It is a list of instructions that must occur in a specific order to be correctly communicated.

  4. I know someone has already mentioned the adr Microformat but I wanted to just add another idea to the process – how about adding geo coordinates as well? Google obviously use the longitude and latitude coordinates to mark points on a map so by including them in the markup, it could easily be extracted for alternative use as well as enhancing the content.

    (As far as the argument between tabular data and ordered lists go, I’d have to lean more towards the latter. Agreed, the data could be represented as tabular data as well and with good use of semantically marked up tables using scope etc.

    Nice write up anyway Jon. It’s good to see the redux of a well-used application.

  5. […] POSH: Semantic Markup for Driving Directions – Monday By Noon kip to main content Secondary content Monday By Noon Home Archive About Contact POSH: Semantic Markup for Driving Directions Tags: accessibility, example, Google Maps, opinion, POSH, semantics, standards One of my all time favorite Web apps to use has to […]

Leave a Reply

Your email address will not be published. Required fields are marked *