Archive for the ‘observations’ Category

YouTube SEO Problem

Wednesday, June 11th, 2008

YouTube is a mostly fantastic site, but they’re still in a transition stage to tight integration with search engines. This is still a common result to see for a video search on Google:

YouTube result from a Google search

Usually <noscript> tags aren’t the best search description. I wonder how they’re addressing this, if they are.

Amazon URL Rewrite

Monday, June 9th, 2008

Amazon creates huge URLs with lots of search engine keywords. Take, for instance:

http://www.amazon.com/Nikon-Digital-18-55mm-3-5-5-6G-Zoom-Nikkor/dp/B000KJQ1DG

Oddly, the only part that matters is the /dp/B000KJQ1DG product code.

So you can create URLs that link to products, but insult your friends. Or are a bit more tame:

http://www.amazon.com/dp/this part is irrelevant/B000KJQ1DG

XML Plurality

Tuesday, April 29th, 2008

A few years ago when I was learning XML, I struggled to understand the distinction between tags and attributes. I knew what they were, but couldn’t figure out when to use which one. In some instances, both seem appropriate. For example, take a customer record:

<customer>
  <id>4222</id>
  <name>John A. Doe</name>
  <address>123 Beech St., Anytown, USA</address>
</customer>

This is the type and structure of examples given in XML tutorials. However, one could also mark up the data like this:

<customer id="4222" name="John A. Doe" address="123 Anytown, USA"/>

So what, exactly, is the distinction? I realized the obvious after a day of thinking:

Can you have more than one of the item?

This means the first example is wrong. A customer can’t have more than one id, and this is the fatal flaw of the tutorials.

Depending on the complexity of our application, a customer could possibly have more than one name or address, but for the majority of basic database-structured applications, the all-attribute example above is more appropriate.

Regardless of how you go and write XML, be sure not to commit the mistake of differentiating between tags and attributes purely by how deep, or nested, the tag is.

In an application with multiple names and addresss, here’s how I would structure the XML:

<customer id="4442">
  <name first="John" middle="A" last="Calvin" />
  <address title="Home" street="123 Beech St." city="Anytown" country="USA" />
<customer>

Even while writing this example, I automatically started to break the address into tags for street and city. After a second, I realized: an address can only have one street and city.

It’s a hard habit to break.