The talk was built around the first principle of Googles corporate philosophy “Focus on the user and all else will follow”. Being the first principle it is the most important one, and prioritised in favor of other conflicting aspects when making a product. Among other things, this means that the first thougth when starting with a product is not how to make money but what do users want.

The execution of this philosophy was explained with an outline how the product process works.

Specifically for UX and design there are 4 interation phases Google follows:

1 Define                 4 Validate
2 Research            3 Design

The first thing is the definition of the product, and gathering of ideas. This comes from various sources, like their 20% time, Market Needs, and others.

After there’s a clear product idea the research phase starts. Research here does most importantly mean: Going out to the user, talk to the user and get feedback. So very early in the process of creating a product Google already starts to gather feedback for a rough idea. It is important to get feedback from a representative group of users, the type of users that should use the product in the end. Later in the research phase they create abstract personas. Personas are a way to classify typical user groups with their interest, habits, jobs, daily activities, emotions etc.

The next phase is the Design phase, where the actual design happens in the following sequence: Information Architecture, Layout/Workflow, Interaction Model, Visual Design. The design and research phase is lead by a designer and a researcher which are in tight collaboration. The design and research goes over many interations until feedback from users start to get positive.

Only when the feedback from users is positive detail planning starts. Finally the Design is validated by users and Google employees when the product is first internally launched.

Some tools they use to gather user feedback are: eye tracking, Labs, before and after experience questions.

Quite interesting to me was: no single line of code is written until detail design is finished. However engineers are involved during the design process but it was not so clear to what level and for what tasks. For me it would have been interesting to get some more information on the collaboration between engineers and designers in the process. Other than that, great talk!

Following situation:
- Much Inline Javascript
- Many JS and CSS files referenced
- No Frontend Deployment/Build Process in place
- Some Javascript values are set at page generation time by Server Side code
- Webserver is not configured yet correctly for setting expires & compression headers

Problems with this:
- Maintainability and separation of concerns is an issue with lots of inline JS
- Long Pageload because of many HTTP request
- Webserver takes big hit for all the static content loading
- Network is being stressed as well
- Javascript Logic is unobfuscated/not minimised and visible to the world

Tasks:

• Externalize JS
• Modularisation of JS Dependency Loading vs. all in one
• Configuration of HTTP headers in Webserver
• Identify Scripts / static content for CDN
• Seamless Deployment/Build process from comfortable JS dev to the production code

The “challenge” was to externalise the inline Javascript.

For modularisation there are several tools to handle the dependency combination of Javascript files. Depending on the amount of Javascript and the usage metrics you can as well just pack all in one. Of course there are many other methods for combination and modularisation and you can as well just run your own method. So this is bascially just a matter of choosing the right tool / method and not that difficult. For compressing / minimisation the YUI compressor seems like state of the art.

Configuration of the correct headers is also just a – well – configuration task of setting meanigful caching control and expires headers and deflate compression for Apache2, so that the documents get compressed over the network. As for deploment and build process sprockets, ant or others are a valiable solution.

What I would like to share here is the solution for externalize Javascript that was initialised by server side code.

The basic idea builds upon this post by dustin diaz. So I am not gonna repeat his content instead if you are not familiar with private, public and privileged Objects in Javascript you might read his post first. As a starting point when combining multiple inline Javascript files we have to take care about namespaces.

//just namespacing
 
function registerNS(ns)
{
 var nsParts = ns.split(".");
 var root = window;
 
 for(var i=0; i

Ok so far so good, now we need to have a way initialise those external Javascript files with dynamic server-side variables:

//initialise a namespaced object
 
var MY = function() {
	var private_var;
	function private_method() {
		// do stuff here
	}
	return {
                init : function(var1) {
                    private_var=var1;
                },
		method_1 : function() {
			alert("method 1");
		},
		method_2 : function() {
			alert(private_var);
		}
	};
}();
 
MY.init("hey you!");
MY.method_1();
MY.method_2();

That worked out as well. But there’s a but. Our javascript will be referenced externally and along with the YUI Performance rules the script include tags will be at the bottom of the page. The initialisation code on the other hand is at the top of every page fragment/widget and might be executed at rendering time. To prevent timing problems the initialisation code therfore needs to configure an object that is already live:

//global js config obj
var runcfg = new Array();
 
//within html
var a = runcfg["details"] = new Array();
a["url"]="http://uebersoftware.com";
 
//external js
var MY = function() {
	var private_var;
        var myconfig = runcfg["details"];
	function private_method() {
		// do stuff here
	}
	return {
                init : function(var1) {
                    private_var=var1;
                },
		method_1 : function() {
			alert(myconfig ["url"] );
		}
	};
}();
 
// usage
MY.method_1();

This method allows us easy externalized the Javascript without much refactoring. The script code is namespaced and is still dynamically configurable.