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!

So without further ado and fanboy-ing here’s why I want to do it.

Scala
I first heard of Scala about an year ago in an article in the German Java Magazin. What caught my attention was that it was designed by a) a Swiss researcher (awakening to my national pride ) and b) that Martin Odersky wrote the reference compiler for Java 1.5, and c) that the Twitter (messaging) backend at that time had just moved to Scala.

Scala is a general purpose programming language, statically typed and integrates features of object-oriented and functional languages.

Some properties Scala offers:

• Runs on JVM: Scala is byte code compatible with Java and can therefore be used in combination with existing Java Libraries.
• Combines functional with oo: Scala can take advantage of best of both worlds
• Eases concurrency, scalablility: A certain amount of functional programming is inevitable, if multicore computers should be used efficiently.
• Reduces code size by 2-4 compared to Java: Less code tends to require less work writing and maintaining it and also tends to have fewer defaults.
• Particular use cases include Complex XML Processing, Concurrent programming, DSL

Within the TIOBE index Scala is at #33. There’s a lot of controversy if scala will be the next big thing. Some very well rounded arguments pro and contra. But as an old saying goes in German “Probieren geht über studieren” I choose to set off trying it myself for a private project or two. Stay tuned for the learning scala series.

Ok, so Nuux is about real-time nightlife information. You can checkout live where friends are partying, checkin to locations and events, message your friends for free, see what’s the hottest venues and generally get insider information about a particular town. To get my motivation behind this project maybe I can explain how it all began:

I was going out with some friends and ended up in a place where we had already paid some cover charge but it was not good at all. How would it be to have some network to check-out what other places and events are like, right now? An app to see where your friends are right now, how they like it, see pics, and recommendations from people just like me?

The idea developed into what has become Nuux right now. Currently you can checkout Nuux as a web platform, a mobile site, and the mobile application. Nuux is tightly integrated into Facebook (Single Sign On, Friend Connect, Publish, Pictures Sharing etc.). This means that for example the there is no actual friend building process required you can just use your connections from Facebook if you like, which are sync’ed on a daily basis.

The Mobile App, which is actually the main part is a 2ME Client available for most of the phones from Nokia, Samsung, SE, LG, Moto (other clients are comming, Blackberry the soonest in about a months time, then iPhone, Android). The website currently only shows a small part of the functionality which is available in Nuux. For example you can let your friends know of your Weekend Plans by linking directly to a venue of your city. Venues can all be filled with user generated content – ratings, tags, comments, pics, and weekend plans. So you can find out what is going to be a popular venue in a particular city on all those attributes.

In the near future we will also offer an API, to enable fellow developers developing their own applications on the Nuux network. If you would like to be notified for an early access, please contact us on developers@nuux.net.

If you would like to get more info please check out the Nuux Blog, or follow Nuux on Twitter .

And yes, please let me know what you think about it either in the comments or on uservoice.

Thanks – and I promise this will be the first and only plug for Nuux, really!

Given that this language is very old school, it makes me wonder what would have happended to the Appshop and Apple if they opened the Shop for Java, PHP or Python?

Until about 1 years ago the options for cross-platform mobile development were

• doing platform specific native builds for Symbian, WinMo, Blackberry, UIQ, etc. or
• Java development with specific twists per handset / handset group or
• WAP/XHTML Mobile Web Site

One of the biggest pains faced by mobile developers was – and still is – device fragmentation. However, with the iPhone a lot of developers turned to develop natively for just one platform because of the tremendous ease and improvements it brought to about every aspect of mobile development:
distribution, ui – experience, not treating apps as third class citicents, monetarization options and needed targeting of devices to reach a critical mass. Now, Apple succeed to generate more than 2 billion downloads with less than 2% market share, truly amazing.

In the same year, autom 2007 Android came out with a SDK which promised even a better world for mobile developers. Due to its nature Android had a slower start, but is definitely emerging as one of the big platforms for the future.

Also in the same year Sun open-source released their LWUIT framework for J2ME development. LWUIT is a GUI framework to target not only Smartphones but also Featurephones of the last few years that support J2Me.

And with the iPhone being such a success of course the other players started to move as well and brought along their own SDK to develop compelling UI’s: Flash Lite (Adobe), WebOS (RIM), Bada (Samsung), Memo (Nokia), Widgets (many), JavaFX (Sun). Last but not least the J2ME spec leads finally settled on a MIDP 3.0 spec and the MSA standard which is pretty cool if it would be adapted by many players.

So instead of fragmentation being reduced, over the years, it has actually being increased. What has changed to the good are that some platforms like the iPhone, Android and maybe others offer now a fairly consistent set of handsets that are fairly wide distributed, so that selecting / specializing on one/two platform became an option for the mobile developer.

However also in the last few years mobile browsers have greatly improved and WebKit became a quasi browser standard. Also manufactures are starting to build javascript extensions to expose phone features like location, multimedia etc. One could argue that given this trend and the forces behind (Google, HTML 5, … ) should give the mobile web sites a good chance of a revival pretty soon. The problem however is, that even though with modern browsers those sites will not be that ugly anymore, users expectations for UI’s have increased as well. Another problem is discovery of mobile web sites. Even though there are 100′000 apps in the app shop, this numer is nothing in compare to the number of possible websites out there.

So what are the new possibilites for cross platform development now, 1 year later?

• Widgets. W3C standard (no handsets yet though), or JIL (by Vodafone, Verizon, SoftBank and China Mobile): JIL defines a widget standard and more that 350 APIs to access to phone features, and this will be implemented on a lot of handsets in 2010/2011 (already in the oPhone from China Mobile or in the H1 from Samsung for instance).
• CrossPlatform SDK Frameworks, players include PhoneGap, Rhomobile, and Appcelerator Titanium

The interesting thing about the cross platform SDK’s is that they supposly allow you to create real native looking apps with a uniform technology which is HTML/CSS/JS or Ruby in the case of Rhomobile. So instead of going the long curve of learing Objective-C and then porting the thing to Java for Android you can a) work with a well known web technology and b) have a single code base. Very promising, if they all will live up the promisses the future will show. If anybody has experience  using those SDK’s I would be very interested in opinions and comparisons.

It really did drive me crazy. Bug only appeared in a certain phone model with a certain version of the app. Not in emulator, not in other phones, not with other version of the app and just 2 weeks ago – without major change in the app – all was running good in this certain phone. Of course I did not remember one crucial thing that happended in these 2 weeks: I upgraded my IDE NB from 6.1 to 6.7.1.

Shouldn’t matter you say? Not in J2ME development. In J2ME developmpent as a rule everything matters, I mean every little tiny seemingly irrelevant thingy you can imagine. So also an IDE change *did* matter.

The reason I found after about 2 hours of WTF’s: with 6.7.1 the proguard obfuscator changed and apparently introduced some bugs. Without obfuscating the app was running all smooth on this partucular phone. Fun thing is that I actually already had this problem once with an earier version of proguard, made a note and forgot about it.

I know about the location where the errors occured and am guessing its one of the errors that has been fixed in version 4.4. After I upgraded from proguard 4.2 to 4.4 all good again. I really want to remember this the next time I encounter such a nasty bug. I hope this post helps me with it, and hopefully it is also useful for some of you guys.

When writing iFrame Apps, think of it like a Connect App. It is essentially the same.

I made the long way round trying to find out what are the specifics of a iFrame app in the Facebook Wiki, Forums, and Google. The Facebook Docs is very unclear about the concrete iFrame functionalities from my point of view. Start reading the Facebook docs substituting Connect with IFrame and you find it way easiert to get along, I found.

The only difference between a iFrame and a Facebook app are the size restrictments of 760px and some friend exchange functions, you probably will not be able to use as an app living inside FB. The other things are the same, since as an iFrame app you are technically another site living on a different server so all the cross-channel communication techniques and security models apply just like for an Connect app.

Also I would stay away from using XFBML whenever possible. XFBML works by parsing your HTML at runtime via Javascript and injecting iframes within your iframe when encountering a XFBML tag. When trying to use the XFBML language for display of Friend Selector, Permission dialogs etc. it tore my site apart and was generally unacceptable slow. I found that this architecture is probably not ready yet for production and it makes your site really slow at times.

I started using Jersey back in 2007 when it was at version 0.4. Netbeans however already had a plugin to get you started on the fast track by generating REST Webservices out of Entity Classes, which you can also generate out of an existing db schema. At that time I was only starting learning JPA and was happy that the Netbeans Code Generators took care of most of my Entity Access Code. In retrospective I should have made the effort of learning everything JPA beforehand and not gradually as I worked along. Usually I actually would have done that, but the Code Generators tricked me into not doing it: It just seemed too simple to bother.

Here is what Netbeans generated to get an object by primary key:


Foo result = (Foo )service.createQuery("Select e from Foo e where e.id = :id").setParameter("id", id).getSingleResult();

Compared to:

Foo result = (Foo )service.find(Foo.class, id);


Problem with first approach besides being the obvious bloathed version: this will likely not be an easy cache hit wheras the second method, depending on your persistence provider will likely go a direct way to find the object within an identity map in the second level cache.

No big deal you might say just change the Query to a Finder method. Unfortunately its not just done with this because the getSingleResult also throws an unchecked NotFoundException when the Entity was not found, opposed to returning null in the finder method. In the generated code this exception was catched, wrapped and rethrown as a checked one. Nice so in some parts of my code was building logic upon those rethrown Exceptions when an entity was not found. So changing the way to retrieve an object had a long tail unfortunately.

Besides that the bigger problem is the design of an efficient and effective object domain model. I am speaking about fetch definitions, caching strategies, lazy / eager loading, and all that. At that time I was frankly just overloaded with a lot of other work beside the JPA stuff so I basically thought that the defaults that Netbeans generated might just work out well. Well no no no.

Another example are the Web Services Generators in Netbeans 6.7. As it turned out, the plugin developers have sometimes simplified-out methods as with the Facebook Service: There is no batching. You probably won’t write a Facebook application without using the batching support.

It feels to me that nowadays many IDE’s and tools come out with the message that they will do all the work for you. What you have to do is just some simple plumbing: enter an API key here, connect to your datebase there and you are done. My experience however is, even for a quick learning curve (and not learning by a bad example), it is better not to trust those generators in the first place and only use them if you can easily spot wrong code and correct such pieces yourself.

Despite Sprocket or similar tools I decided to go for the plain old ANT approach. Why? It was the most practical tool, you have full control of what you are doing and the other tools did not quite what I wanted.

One part of this ant solution was to configure production setting in several source files. I rediscovered just how powerful and really simple this great tool is. Once you get used to is configure,combine,pack and deploy your php/js/html/css is a piece of cake:

Here some excerpts
In order to have just one source file I defined some custom preprocessor variables in my various files:

//@@prod@@ $config['base_dir']="";
/*@@dev@@*/ $config['base_dir']="Foo/";

<!--@@js-dev-start@@ -->
<script type="text/javascript" src="assets/js/jquery.plugin1.js"></script>
<script type='text/javascript' src='assets/js/jquery.plugin2.js'></script>
<script type="text/javascript" src="assets/js/jquery.plugin3.js"></script>
<script type="text/javascript" src="assets/js/jquery.plugin4.js"></script>
<script type="text/javascript" src="assets/js/jquery.plugin5.js"></script>
<!-- @@js-dev-end@@ -->
<!-- @@js-prod-start@@ <script type="text/javascript" src="assets/js/jsbuild.js"></script> @@js-prod-end@@ -->

then in ant this looks as follows:

<echo message="Configuring PHP config for production" />
  <replaceregexp byline="true" flags="m">
            <regexp pattern="^.*@@dev@@.*$"/>
            <substitution expression=""/>
            <fileset dir="${build.dir}" >
                <include name="php/config/*.php"/>
            </fileset>
        </replaceregexp> 
        <replaceregexp byline="true" flags="m">
            <regexp pattern="^.*@@prod@@(.*)$"/>
            <substitution expression="\1"/>
            <fileset dir="${build.dir}" >
                <include name="php/config/*.php"/>
            </fileset>
        </replaceregexp>

And for the javascript in my php – view files

<echo message="Configuring referenced Javascript for production" />
<replaceregexp flags="sg">
            <regexp pattern="@@js-dev-start@@[^\@]*@@js-dev-end@@"/>
            <substitution expression=""/>
            <fileset dir="${build.dir}/php/view" >
                <include name="**/*.php"/>
            </fileset>
        </replaceregexp>
        <replaceregexp byline="true"  flags="m">
            <regexp pattern="^.*@@js-prod-start@@(.*)@@js-prod-end@@.*$"/>
            <substitution expression="\1"/>
            <fileset dir="${build.dir}/php/view" >
                <include name="**/*.php"/>
            </fileset>
        </replaceregexp>

Applying the concat task for js and css concatenation and apply java to invoke the yuicompressor and you’re done.

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.