Building Blocks

I just visited a local library. I took the time to pop in around lunch since they have reopened the library just recently (2 years ago?), with some new concepts in place.

What I noticed is that they have a lot of work stations placed around the library. All carrying 28” screens with good resolution. End result, most web sites viewed in the library only cover between 30-50% of the screen.

Right now it seems that screen resolution is taking off, and web sites aren’t following.

This is natural, the few people go back and update their web sites. Especially if it is focused on functionality to begin with. The thought I have is, should web browsers try to optimize for maximum screen utilization or not?

I read a blog post at Three Rivers Institute that lead me to the following presentation.

The presentation is about startups and search engine optimization. How to drive visitors to your website.

Dharmesh discusses how to adapt your webpage to generate visitors, also promoting his hubspot seo grader.

Now this got me thinking of a project I’ve been working on. It’s a highly dynamic JavaScript based page, hosted on Google AppEngine. (currently not in a state I’d like to show it off since its still lacking the basic features).

The page is being designed with a few ideas in mind:

• All dynamic data i served to the page through REST
• All static pages are served with long expiration, most content is static
• The main page never reloads, instead JavaScript does AJAX to update the content
• The JavaScript is designed using SOLID design principles
• The JavaScript is tested
• Back and forwards buttons still work
• Marketing Content is served using Google Sites, to reduce bandwidth but especially to shorten roundtrips when working with Marketing material

Now the idea here is to give a similar feeling as to what GMail feels like. A common trend, in web application development I think. However, after watching the presentation the following thought occurred to me. The GMail application needs to be found by search-engines.

Google has a signup page with content that is searchable, but the main JavaScript client is not designed to be found by Search Engines.

I want my page to be found by search engines, and this means that there are a few of the basic Ideas behind the page that I need to reconsider. Especially the following:

• The main page never reloads, instead JavaScript does AJAX to update the content
  • Meaning that the page looks “empty” to search engine crawlers since all content is loaded using JavaScript
• Marketing Content is served using Google Sites, to reduce bandwidth but especially to shorten roundtrips when working with Marketing material
  • Right now this is implemented using IFrames, which probably cause trouble for search-engines (yeah yeah, I know frames suck especially IFrames… but there were some cross site issues I didn’t want to fix right now),

I need some of my content pages to be searchable, but not the AJAX-driven application in it self. So now I have to rethink some of my decisions which were made from a pure coding view-point, to adapt to marketing viewpoints (and search engine algorithms so its not all bad).

The Google Wave beta program rolled out a bunch of Beta invitations lately. I discussed this with a friend, the marketing value of an invitation model for software.

GMail started as an invitation, most people I know started using GMail as they were invited by others. I my self started with GMail after a friend evangelized the interface.

I believe that Google hopes to apply the same marketing model to Google Wave, and as far as I know they will succeed with it as well.

Now lets consider the benefits.

• They can build hype, but still release the product early for feedback
• They can scale slowly, making sure the system can handle the load as the user base grows
• They can target specific users for invitations, say 20% targets students, 20% targets media, and then som distributions between web browsers and operative systems

Now the targeting of users is interesting. This part is just hypothesis, but in theory they could use search to look up people. For example, they could find people on Facebook and see what kind of friends they have, even interests for example. They can check out whom follows who on twitter. All in all, they can in theory data mine the net to target out specific users whom will fill the role for Marketing, Feedback and Development.

More and more sites are doing it. Keeping their state in the address bar of the browser, enabling AJAX driven dynamic html pages to use the back and forward buttons between javascript driven views.  The most common website that uses this functionality, that I know of, is GMail. If you look at the address bar in GMail when in an message you can see that they added a bookmark hash (#) specifying which message to show. The updated address bar allows the application to keep state in the browser history.

I started working on a solution for this on my own, at the time I couldn’t find any JQuery plug-ins with the desired functionality. Now however there are several. In order to reduce the amount of specific code in my own application I tried out three.

JQuery History, JQuery hashchange and JQuery address .

JQuery address

After looking at JQuery address I can honestly say that it has the best fail-safe of the three I looked at. It uses full page post backs as a fallback. I haven’t been able to get it to work without reloading the entire page. So for that reason I cannot use the plug-in myself.

JQuery hashchange

This is my favourite. I has a nice and clean interface and does only what you tell it to do. However I couldn’t get it to work on Internet explorer 6. Which is also one of the reasons why I’m looking at the plug-ins to begin with.

JQuery History

JQuery history is actually the plug-in that led me to the others. I came in contact with another Mor.ph user who used it on his site. As far as I can tell from the usage of this it needs to interact with the link’s on the page in order to work properly. Catching the click events on the links. This is also a problem for me. I’d prefer just to update the bookmark hash.

Now while I couldn’t use any of these plug-ins I just wanted to give a shout out to people looking for them. They are there. A few things to think about, that I found out. Is that your page needs to be designed for this type of behaviour. If you use any of the plug-ins then your page will most likely be couple to that design. It’s also much easier to add this type of behaviour for the page in the beginning than appending it to already existing Ajax pages. These are my experiences with it.

I also lack a word for the technique of keeping your state in the address-bar.

I found a new tool for testing web-applications in IE today. It’s called IETester, and it allows me to test IE versions 5.5 to 8 in the same application. Which is great, since my Vista machine only runs 8 normally.

I use it to verify my Grails application in IE6. Tonight I managed to create a unit test capturing the issue I was experiencing in IE6, using IETester and QUnit, so now I know where to take off tomorrow.

However it isn’t that stable, I’m running it on a 64-bit machine which might add some extra strain on the application. But for me it needed to be re-started or crashed a few times while I was isolating the bug I am working on.