Categories

Authors

Pages

Recent posts

Recent comments

Archives

Code version H.21 released

Tuesday, 19 January 2010 @ 17:00, by Ben Gaines

Those of you who logged in to the Admin Console in SiteCatalyst since this past Thursday afternoon to generate new JavaScript code may have noticed that we released code version H.21. The primary purpose of this update was to add ClickMap support for the <button> element, so that you can see the number of clicks on form buttons using the ClickMap plug-in. If need to be able to report on button clicks immediately, you may want to consider upgrading to this new code version after testing it extensively in a development environment.

Speaking of ClickMap support for the <button> element, we strongly recommend using the s_objectID variable in the onclick event handler of your <button> elements. In our experience, use of <button> almost always involves an onclick event handler which performs the button’s practical function (e.g., submitting a form, launching a pop-up, etc.). They never involve an href (and never should). This leaves ClickMap needing to use the onclick function to identify the page element, and this gets messy—especially when you consider that IE and Firefox report them to ClickMap differently.

Fortunately, there’s an easy solution: put an s_objectID variable—with a value unique to each distinct button—in the onclick for the button. For example:

<button type="submit" onclick="var s_objectID='abcd1234';myFormSubmitFunction();">

<button onclick="var s_objectID='some_unique_value';launchPopup();">

(Also, note that while the “type” attribute is not expressly required, when it is omitted—as in the second example above—IE will assume a type of “button,” and other browsers will assume a type of “submit.” This means that depending on which browser you are running ClickMap in to view the page, you will see a different number of clicks for the button, as it will only be reporting on the portion of the data which matches the implied type for the browser you are using. This limitation is also overcome by using s_objectID.)

  • on  
  • Bookmark at  

respond to post

responses

  1. James Dutton 2010/1/19 @ 6:18 pm

    Hey Ben,

    Quick question - and I think you answered it in your article - for those who are already using the DynamicObjectIDs plugin (which I believe only generates unique id’s for objects in the dom with an href) would you need to do what you’re proposing here? Or is it because the DynamicObjectIDs plugin doesn’t work on these kind of objects you’d need to hardcode an s_objectID?
    If this is the case, do you think the engineering team will take note that increasingly IA’s and developers are linking content with more ‘funky’ code than simply hrefs, so the s_code needs to effectively get smarter - in other words might DynamicObjectIDs (if it doesn’t already) cover more linkable objects?

    As always, great reading!

    Cheers, James.
  2. Henrik Schack 2010/1/20 @ 7:58 am

    Re: IE and Firefox reporting onclick handlers differently to Clickmap, how much of a difference is there ?

    /Henrik Schack
  3. Ben Gaines 2010/1/20 @ 12:47 pm

    Great question, James. I believe the plug-in goes through document.links to get an array of the links on the page, so a element would not be covered. You’d need to implement s_objectID manually on elements, at least based on the current version of dynamicObjectIDs. And I do agree and expect that plug-ins and base code will continue evolve to meet the needs of users in this regard and others. You’ve offered an excellent specific reminder of this, though, and we’ve taken note of it.
  4. Henrik Schack 2010/1/20 @ 2:47 pm

    Hm but couldn’t the Omniture tracking code compensate for these differences, and make sure to track things “right” across different browsers ?