I’d be happy to share the jQuery work. I have a very basic reference to it on my blog @ http://bit.ly/6r5UXU . The post references Omniture, but could be applied to any tool.

I’ll put together a more detailed post on it soon!

-Rudi

First. Very Merry Christmas. AND thank you so much for taking the time to read my book – really happy it time well spent.

I like your jQuery idea, which is not far from what I am talking about – which is essentially stressing that the vendors execute in full on what you have started. Would love to see what you have done, if you would like to share..

cheers
d. :-)

Great read and great comments above as well! I really like the idea of letting the clients outline the elements through the methods you suggest. I’ve done something similar with using jQuery to check for a specific class/id and add tagging on the fly. While this is not a universal tag solution it could be expanded.

BTW. I’m enjoying your book that I got for Christmas!

-Rudi

I agree, even basic and traditional HTML tags could be utilized in a more automated fashion, traversing the DOM and concluding /suggesting on behalf of the client would not be a bad idea. I am however still a bit of a fan of letting the clients outline the semantic elements through Microformats – must be the nerd in me, who looks for structure. :-)

Merry Christmas
d.

Great Omniture story, thanks for sharing, but also one which I honestly hope we’ll see repeated in an even more coordinated environment – AND I certainly agree that we (the web deployment engineers) ended up with a more rigorous install process that the CMS deployment engineers.

>>The more the production processes are automated, the easier this will be…
Agree. It would be somewhere in between great and fantastic if the Content Creators and the systems / processes they use did most, if not all, the tagging needed as they publish. This is not a utopia though.

>>Have a happy snowy NY Christmas from hot ‘n humid Singapore!
Damn you! I am knee deep in slush :-)

Cheers
d.

You’re right – this doubling up of information does cause a lot of pain in deployment.

As Eric mentioned above, any page tagging can suffer from inconsistency. One example of the extra work caused by a lack of pedantry in HTML content is the page title tag. As you know, we (Yahoo! Web Analytics) use the HTML page title as the page name in reports in the UI. However, if that is missing/incorrect/generic etc, users implement the setDocumentName() method which is used instead. Seems like needless hassle really.

Merry Holidays! :)

E

Interesting article. Reminds me of when I worked (many years ago back in 2004) with HP Asia where we decided to minimise the custom Omniture tagging requirements and leverage scripts that pulled meta data published by the cms into the SC code. This was back in the day when tags were the most sophisticated published data available, outside of a rigorous custom implementation.

This concept is still in play for many clients I work with. The caveat, of course, is that very few web publishing systems (correct me if I am wrong) have been correctly implemented… that would enable this.

Typical example: Client invests in Teamsite, but has yet to implement in a governed and structured manner – ergo despite the aspirations of simplified data collection, the measurement team is forced into a custom tagging scenario. Folks will tell me ‘oh, get the cms correctly installed’ – right, ok – doesn’t work this way. Same thing would apply – as you say – that microformats or custom meta / dom data isn’t coded by developers in a well architected semantic manner. The more the production processes are automated, the easier this will be…

Have a happy snowy NY Christmas from hot ‘n humid Singapore!

Cheers, J