The team used a lot of the principles from Steve Souders book: High Performance Web Sites and ended up with a nice gain:
According to our latency measurement stats, the user-perceived latency on Google Code dropped quite a bit, anywhere between 30% and 70% depending on the page. This is a huge return for relatively small investments we’ve made along the way, and we hope you’ll find these techniques useful for your own web development as well.
The changes were low hanging fruit that most of the sites could also implement:
Combined and minimized JavaScript and CSS files used throughout the site
Implemented CSS sprites for frequently-used images
Implemented lazy loading of Google AJAX APIs loader module (google.load)
I have seen the huge batches of cell phones that companies keep around to test their applications on. Companies like UI Evolution have come along to try to help out the madness of getting something that works across more than a couple of them.
Not only do you have the problems of handsets, but you also have the network lock-downs and the hoops you have to go through to get an application onto a large set of devices.
Since the iPhone, I have strongly believed that history is going to repeat itself, and the Web is going to win on the mobile.
Today we’re announcing the launch of Google Gears for mobile, a mobile browser extension for creating rich web applications for mobile devices. The first version is now available for Internet Explorer Mobile on Windows Mobile 5 and 6. It’s a fully functional port of Google Gears v0.2 that can be used to develop offline capability into your mobile web applications. You can also create slick and responsive applications by hiding latency issues through controlled caching of data and storage of information between sessions. We’re also working to bring Google Gears for mobile to Android and other mobile platforms with capable web browsers.
There are already a handful of Windows Mobile web apps that use Google Gears for mobile, such as the social payment service Buxfer and online applications provider Zoho. Read more about these applications and how they use Google Gears for mobile on the Google mobile blog.
I got to fly back home to London to talk to members of the mobile team. Below is an interview with a couple of the engineers, and there is also a high level look at the news:
I am really excited about what this means for the future of mobile development. I want to be able to develop applications using Ajax on the phone, and see tools like Gears give me access to native APIs on those devices. I really hope that the iPhone SDK also offers more on the JavaScript API side too (as well as Cocoa). How nice would it be to take your iPhone app and finally get some onPinch goodness, and camera.takePhoto.
Ben Lisbakken, who sits 100 feet away from me, developed gearsAJAXHelper, a library that bridges the AJAX search and feed APIs with Gears, to get a speed improvement:
We decided it would be cool to write a small library to make it easy for you AJAX APIs developers to write quick-loading, always fresh searches/feeds. The gearsAJAXHelper has two main features - it allows you to store and return key/value pairs from the local database, and it allows you to choose whether you want all resources files on the page (images, CSS, Javascript, HTML) to automatically be cached in the Gears cache.
The key/value pair database feature let's you store the query/results as a key/value pair. Then, the next time the query is made, the results can be served from the database while fresh results are being retrieved. This dramatically reduces the latency in queries/feed grabs.
The (optional) automatic cacheing of resource files will make it so that each time the user visits your webpage they will be getting resources served from their Google Gears cache, not new versions from the internet. Be careful when using this feature, as you might not want stale content to be served. There is also a refresh function, to clear the Google Gears cache of old files.
You can take a look at the sample, that saves the content for presidential candidates so if you click back on an area, you get instant loads.
Gears gives you all of the components that you need to take your application offline. If you have the type of application that for now wants to just take some of its content offline, that should be trivial to do right?
That was Brad Neuberg's position, so he created Gears PubTools as a way to make that happen. These tools are for content authors that don't even want to touch JavaScript.
How you use it?
Point to a Gears manifest file (a special file that lists all the pages to take offline) with a simple HTML attribute:
NOTE: This shows the Desktop Shortcut API that you can use in any offline application.
You don't even have to write the manifest file yourself! PubTools includes a simple bookmarklet that developers can drag to their browser's toolbar. Just navigate to the web pages you want offline, press the "Generate Manifest" bookmarklet, and a dialog will appear with the full manifest file generated for you ready to cut and paste into a file.
The core Google Gears gives us the building blocks that we can then build on top of to give users really easy tools and APIs. It has been great to see Brad join the Gears team and see him work on some of these issues. I expect to see much more from him in the future. What would you like to see?
New modules: HttpRequest and Timer. The main reason for these modules was that developers told us they wanted to make HTTP requests and create timers inside Gears workers. But these modules can also be used outside of workers. For example, one advantage to using the Gears HttpRequest module instead of normal XMLHttpRequest is that Gears HttpRequest module addresses a common problem making comet-style applications work on IE.
Improved support for handling errors in workers. This is an area where we received a lot of good feedback. Now, errors from workers are automatically bubbled up to the main page by default so that you can see them in the error console or in Firebug. Or, you can handle them explicitly with the new onerror event.
Ability to load workers from a URL, even cross-domain URLs. We've long wanted the ability to load workers from a URL. We've also wanted to provide a way for different domains to communicate safely. This is useful in the case of mashups, or when an application spans multiple domains. The new createWorkerFromUrl API solves both these problems.
Now 0.2 is in production, the Gears team can look to 0.3 and items such as:
Would you like to be able to make a quick call to get a JSON response that ties together a social graph made up of resources available on the Web?
Brad Fitzpatrick, Kevin Marks, and others at Google have released a new Social Graph API that does just that:
The new Social Graph API makes information about the public connections between people on the Web easily available and useful. You can make it easy for users to bring their existing social connections into a new website and as a result, users will spend less time rebuilding their social networks and more time giving your app the love it deserves.
Here's how it works: we crawl the Web to find publicly declared relationships between people's accounts, just like Google crawls the Web for links between pages. But instead of returning links to HTML documents, the API returns JSON data structures representing the social relationships we discovered from all the XFN and FOAF. When a user signs up for your app, you can use the API to remind them who they've said they're friends with on other sites and ask them if they want to be friends on your new site.
This is exciting to me as:
It actually uses the microformat standards such as XFN
Accessibility is something most developers consider an afterthought but not Chris Heilmann, web architect at Yahoo!. As a member of the Yahoo! Accessibility Stakeholders group he takes issues concerning accessibility very seriously and makes it a top consideration in everything he builds.
Chris Heilmann recently described his technique for making Google Charts more accessible for those who cannot see pie charts. His technique allows for standard accessible data tables to be converted to charts thus ensuring that visitors using screen readers can take advantage of the data while allowing users of traditional browsers to view the actual charts:
Using this script you can take a simple, valid and accessible data table...and it gets automatically converted to a pie chart.
Simply add the script to the end of the body and it’ll convert all tables with a class called “tochartâ€. You can define the size (widthxheight) and the colour as a hexadecimal triplet as shown in this example. If you leave size and colour out, the script will use presets you can alter as variables in the script itself.
To verify his code, Chris enlisted the help of a blind friend, also a member of the Yahoo! Accessibility Stakeholders group, who tested it with JAWS.
The script has also been enhanced to allow the creation of accessible data tables when pulling charts via the APIs verbose mode.
As always, it's best to see it in action in order to truly appreciate it. I commend Chris and the Yahoo! Accessibility Stakeholders group for their efforts in making the web more accessible to all.
Over on my personal blog I kicked off a series of articles on some future APIs that are on the table for Gears, and how in my opinion, Gears is mistakenly seen to be about "offline", when that is just the surface.
I started off by discussing the Image Manipulation API, "is a module to give Javascript a way to resize, crop and compose images together on the client side. This will allow, for example, images to be resized into a web-friendly format before being uploaded to a photo album. Another use is for composition of images together as an efficient alternative to server-side composition or CSS layering. Yet another use is for basic photo editing - a user can edit a photo with instantly applied changes before uploading it to the server."
The Location API provides a means to fetch the location of a device running a Web browser with Gears:
The Location API is an abstraction for the various LBS APIs that currently exist on mobile platforms (GPS-based, network/cellid-based). The API consists of the Location class, which encapsulates various location attributes (latitude, longitude, etc), and also provides the means to query the platform for a location fix. This API also adds a new event type that is fired every time the location changes. Location implementations can be straightforward mappings to native LBS APIs (e.g the S60 Location Acquisition API) or have a more complex design that combines several location providers (e.g a GPS-based provider and a cell id-based provider) and returns the location from the most accurate provider at any given time.
To finish off we have the issue of developer tools. We need to make sure developers have the tools they need to enable successful app development using the APIs, so we want to first add:
Database
List databases per origin
Create new
Delete
Interactive DB command line (can just use existing /sdk/tools/dbquery.html)
LocalServer
List ResourceStores (and ManagedResourceStores) per origin
ResourceStore and ManagedResourceStore status (last error, update history, etc)
command line (like db command line, but pointed at localserver DBs)
I had the pleasure of finally meeting Didier Girard. I seem to run across Didier's work every week or so, but for some reason we haven't had a chance to meet face to face, until JavaPolis.
I had an 11 hour flight from London to SFO. What was I going to do? I had a couple of books with me. The in-flight movies were average, and even in business class they didn't have the on-demand system, so if you missed the start you had to wait for the next go around. I poked around in a DVD store and couldn't find anything to interest me, so I ended up grabbing 'Heroes' since I had never seen it. I was put off by the "Save the cheerleader, save the world" commercials, but figured if it was half decent then there was a lot of material (e.g. time) to cover.
So, I popped in the DVD, and whilst I watched, I opened up Firefox and Textmate.
I have been wanting to play around with the new Ext 2.0 release, and also with the GWT-Ext package. Unfortunately, that module isn't using Ext 2.0 quite yet (almost!), so I decided to do a first rev of the tool with straight Ext 2.
I found the new Google Chart API to be a little addicting, and some people have asked if there was a tool for people to create charts, instead of having to munge with URLs.
A common use case is to dynamically generate the charts on the fly, and then it makes sense to just build the URls and you are done. But, what if you wanted to sit back and just throw out a chart or two?
The tool has you fill out core information about the graph or chart that you want to create (e.g. size and title), you then choose the type of chart in the tabs, and you fill out the data needed for that type of chart. You can click on the "seed data" button to see sample data, and when you are done tweaking it, you click on "GET CHART". That action causes a preview to be loaded below, and you get given the URL in a text box that you can copy and paste.
It is a little rough around the edges in that I wanted to let you tab though fields and have an easy way to add rows of data (instead of just using a crude textarea). I also need to make it so that all of the data can be expressed through the UI (e.g. marker types, colors, fills, etc) which isn't the case now.
I really enjoyed Ext 2. They did a great job, and with more documentation and such to come, I think it is a great library for building these desktop-like environments.
Then each section used the "region" metadata to tell the system where to place it. You are also able to do things like tell the system you can be moved around, collapsible, and more.
So, the result of a few hours with Ext 2 with no access to the online docs and you get this:
Yup, that's RTM in there! Remember The Milk for Gmail is a Firefox extension that lets you do all kinds of crazy cool things with your tasks (and interacts with your mail, contacts, and calendar too).
It goes beyond letting you manage your tasks, as you can connect tasks with your mail, google calendar, and contacts.
I love simple APIs, and this one eats the pie. With the Google Chart API you can build a URL that will dynamically create a chart for you. This service is used internally for Google Finance, Google Video, and beyond. Now, anyone can use it!
Although it is simple to use (just a darn URL after all) you will see that there are many options.
Here is just a few charts to show how broad this is:
, Performance
