While reading
The Globe and Mail on an iPhone, we noticed a very interrupting behavior: each time when we accidentally touched one of the share buttons, as shown in the screen shot, the button took immediate action. The email screen, for example, takes over when we mean to just scroll up the content. Similarly, the Twitter and Facebook icons redirect the page way before the finger leaves the screen.
Apart from the misinterpretation of touch events, the buttons also respond at an odd time. Normally a button is activated when it is pushed and released. In The Globe and Mail website, the instant activation of buttons come as a surprise. We don't want surprises when it comes to user interface design.
To make the matter even worse, the first instance of the share tool bar is located at a "finger-scrolling blind spot" - the area just below the banner image and text where the user places his finger without obstructing his view. This means that the share buttons are almost guaranteed to be touched, and that reading the news article is almost certainly interrupted.
Once we understood the design flaw, we continued to investigate the implementation of the web site. Modern mobile browsers are more than capable of differentiating clicks and drags. Our suspicion instantly laid on custom JavaScript. As soon as we disabled JavaScript in mobile Safari, the buttons worked perfectly. We dug deeper and found the following code:
$("a.share").touchOrClick(function(e) {
e.preventDefault();
var r = this.getAttribute("rel");
var url = this.getAttribute("href");
var media = (r == "Email" ? "Email Article" : "Social Media");
_gaq.push(['_trackPageview','/SuccessEvents/'+r+'/']);
_gaq.push(['_trackEvent', media , r ]);
s.events='event6';
s.tl(this,'o','Link to Post - ['+r+']');
window.location.href = url;
});
Now we see the author's intent. The share buttons not only redirect to their corresponding share pages, but also track page views and sources. We understand the reason for not using the following pattern:
<a href="targetlink" onclick="track(this);">Share</a>
If the above code is used, the tracking code would fail to complete before the page is redirected. However, The Globe and Mail's implementation has two mistakes:
- The buttons trap the incorrect event
- Tracking takes place at the wrong stage
Instead of intercepting a custom event "touchOrClick", trapping "onclick" should do a much better job. Judging from the reactions of these buttons, we can infer that the touchOrClick event is handled by "ontouchstart". The logically correct event to attach to is ontouchend. But again, onclick is a much cleaner solution. Another faulty line is
e.preventDefault(), as this is not understood by all browsers. Use
return false; to suppress the default handling of an anchor.
Now we have some buttons that correctly react to touch events, track and redirect pages. The page is still not fully fixed. As pointed out earlier, page view and source tracking happens at the wrong stage. What if the user clicks on the share button and then decides not to share? What if the user touches the button by accident, which is, by the way, almost all the time?
In order to accurately track sharing activity, the tracking code needs to be invoked at conversion time. This means the source and current page URL should be recorded only if an email is sent, or twitted or Facebook-shared. Looking at the site's loose integration with these applications, we can tell that conversion-time tracking is not feasible, unless, of course, the site provides its own mail form and forward traffic details to Twitter and Facebook.
In conclusion, the current Globe and Mail website cannot accurately track visitor stats, and the tracking code interferes with user interaction on a mobile device. Our recommendation is to remove the JavaScript handler that we have quoted in this post before conversion-time tracking is in place.