Dynamically loading Google Analytics

I finally finished the Creative Industries Newswire website. The Creative Industries Newswire is a centralized place where authorized QUT staff members can author and publish news items. It is a place where users can access those news items, leave comments, and subscribe to individual news wires via RSS. It basically runs off WordPress.

Creative Industries newswire homepage.

A few interesting issues that emerged with relation to using Google analytics. The issue with this website is that it is used by both public users and users on an intranet. Intranet users at QUT may be authenticated to access resources on the intranet (such as the newswire website), but not resources on the internet. When an unauthenticated users tries to load a page with the following Google-provided code the browser attempts to load the script but eventually times out. This can take around to 60 odd seconds in Firefox (or something close to that, not sure exactly how long). The implication is that, to the user, the browser looks as if it is still loading content. And in the browser, it does not execute the
<script> tags. Below is the problematic code that Google provides:

<script src="http://www.google-analytics.com/urchin.js"  type="text/javascript">
</script>
<script type="text/javascript">
   _uacct = "UA-XXXXXX-1"; urchinTracker();
</script>

Looking at the code above, what essentially happens is:

  1. urchin.js needs to load synchronously and block the second script tag from running
  2. once loaded, the code inside the second script element must be run
  3. if the code is run without the script first loading, then the urchinTracker() method will be undefined.

So, like I already stated, in the intranet scenario, the urchinTracker() method is never called because urchin.js is never loaded. To make the whole process a bit more “behind-the-scenes” I decided to recode the Google code so that it is run only once the document has executed it “onload” function. The following simply dynamically appends the DOM with a script element AFTER the document has loaded. If the script element can reach its src, then analytics info is sent to Google, otherwise, nothing happens:

window.onload = function(){
   var scriptLoadFunction = function(){
   _uacct = "UA-XXXXX-X";
   urchinTracker();
};
var e = loadScript("https://ssl.google-analytics.com/urchin.js", scriptLoadFunction);
}

function loadScript(url,aFunction){
var e = document.createElement("script");
if(e.addEventListener){
e.addEventListener("load",aFunction,true);
}else{ //try to force IE to work, but alas, it does not.
e.attachEvent("onload",aFunction);
}
e.type="text/javascript";
e.src = url;
document.getElementsByTagName("head")[0].appendChild(e);
return e;
}

The code works great in Firefox 2.0 but does not work in IE6 or IE7 (as IE does not support the addEventListener() function). If anyone has a work around to this problem, I’ll like to hear about it.

Widgets 1.0 responses and thoughts

Responses to the Widgets 1.0 spec on the web have been mixed, but mostly positive with a few negative comments here and there. There have been some positive responses, like the one on Ajaxian. The brief article on Ajaxian seems to clearly capture the point of the spec:

Everyone and their mother have created their own widget specifications, and now as a developer you need to make choices. Do you want it to work on Dashboard? Google? MSN? Yahoo!?
If the big hitters supported this widget standard then we could write once, widget everywhere. Kinda 🙂

And another really good point they make is that…

This standard will live and die by the support that it gets.

Dare Obasanjo wrote a fairly negative blog entry about the Widgets spec seems to kinda miss the point (and Mark Baker points that out in the comments), because he seems to think that Widgets 1.0 is trying to address web page embedded widgets, which it is not.

Arve Bersvendsen, who edited the very first versions of the Widgets 1.0 spec, took time to briefly blog about the widget spec; and so did Anne van Kesteren (currently the other editor of the Widgets spec), stating in his blog entry about Widgets 1.0 that for some time I thought widgets were the latest marketing trick and pretty useless. Now I think they can actually be really useful (and fun) for creating simple applications using HTML, ECMAScript and CSS. The website Musings from Mars also thought that Widgets 1.0 was a good idea, saying let’s hope the world came settle on a standard that would let developers write widgets that would work on all the various platforms (Yahoo, Apple, Opera, Google, and, yes, Microsoft).

It seems that in general people get what Widgets 1.0 is all about. For those who don’t, lets be clear. The purpose of the spec is (IMHO):

  1. stop fragmentation of the Widget development space, particularly in relation to metadata and the APIs.
  2. to provide a standardized way to package, sign, code, and record metadata about widgets. The theory being that, if adopted by vendors, you could write a widget once and run it on any conforming widget engine (Yes! the same as Java applets). Of course, this second point is very complex (or screwed!) because of the API problem, which is the greatest challenge for the standardization of widgets. I return to this massive issue later.

I think the cause of confusion has partly been the name “Widgets 1.0” and the lack of historical context around this spec. I guess this is why the original requirements document I wrote was named “packaging client-side web applications”. Even though the title made sure that very few people knew what the hell i was talking about, the title of my document captured (part) of the problem well… but capturing the problem well doesn’t help if people don’t know what the hell you are talking about. However, the Widget spec is wider in scope and so is the now renamed “Client-Side Web Applications (Widgets) Requirements” document. As I already discussed above, the scope of both documents now covers five issues surrounding widgets:

Continue reading Widgets 1.0 responses and thoughts

Designing Visual Interfaces

Today I am reading Designing Visual Interfaces: communication oriented techniques by Kevin Mullet and Darrell Sano.

Here are some gems

Visual Design attempts to solve communication problems in a way that is at once functionally effective and aesthetically pleasing. (p1)

By communication, we mean the full process by which the behaviour of one goal-seeking entity comes to be affected by that of another through the reciprocal exchange of messages or signs over some mediating physical channel.p1

The goal of communcation-oriented design is to develop a message that can be accuratley transmitted and correctly interpreted, and which will produce the desired bhavioral outcome after it have been understood by its recipient.p2

We refer frequently to a visual language, by which we mean the visual characteristics (shape, size, position, orientation, color, texture, etc.) of a particular set of design elements (point, line, plane, volume, etc.) and the away they are related to one another (balance, thythm, structure, proportion, etc) in solving a particular problem. Any language system defines both a universe of possible signs and a set of rules for using them. Every visual language thus has a formal vocabulary containing the basic design elements from which higher-level representations are assembled, and a visual syntax describing how elements may be combined within that system.
p2

In the context of GUI toolkits, “…most toolkits impose unnecessary design restrictions as a side effect of their own implementation or internal structure.”p4

Basic principles of visual organisation developed through centuries of experience with print media have rarely been applied to the on-screen media, and communication has suffered as a result. p5