GMail and Yahoo! Mail
June 17th, 2004Last night I got an account on GMail through a friendly offer from Vinny Carpenter. It is very minimalistic and fast. I really find those 2 qualities to be the top features a web application should have. I have also been using Yahoo! Mail for a long time and it was nice of them to bump me up to 100mb the other day in response to GMail. I have found the GMail interface to be rather smart in the way it takes advantage of modern web browser functionally....
The interface makes use of access keys as shortcuts. It is a nifty feature that is included in both IE 6 and recent Mozilla versions. There is also a clever trick of clicking on the star image to select/deselect it without reloading the entire page. It seems to just send a signal back to the server, possibly just reloading the image.
I have been making use the option to set the "Reply To" address in both GMail and Yahoo! Mail. I run my own SMTP server so I can alias an email address to another address pretty easily. For both I use my offwhite.net domain with a unique name to both mail services. This way if someone replies to one of my emails it will go to that aliased address and not the GMail or Yahoo! Mail account. This could be useful if I eventually decide to bail on my Yahoo! Mail account and alter my alias to send all future mail to my large capacity GMail account.
I was trying to see how the GMail pages work, but they are wrapped up in a whole lot of dynamically generated code using Javascript. The page is also made up of frames, which I did not realize at first. It makes use of the fact that the Javascript is cached and held in the parent frame so that page loads are extremely fast. Google has really gone crazy with page optimization ever since they started their search service, but they have carried it over into the web mail interface. Notice the size highlighted in red. It shows the page size is under 1kb. That is a pretty impressive feat.
I cannot wait to see others try to emulate the techniques that Google is using.
June 23rd, 2004 at 11:29 pm
Hey, you actually are believing firefox's filesize reporting where you shouldn't be. I think that is the size of the parent document, but all the data is in the frames.
The main body of the program is a 220KB javascript.
But you are correct that this part probably caches, and that overall they did a super-impressive job writing cross-browser compatible javascript to push all the load off on the clients. When you view source on the frame with the list of messages, or with a message body, you will see that they have a series of calls to a function D(); Which I think stands for "Data". Each call to D() sends along some data to that main js program for processing, markup, and display. So while they incur a bit of overhead escaping special characters within the datastrings, they really are keeping the data transfers to a minimal size because there is very little html markup being sent. My inbox view with 6 messages is a svelte 2.1KB. Using some fancy javascript I determined that the marked-up version of the same data is over 11KB.
Because the javascript caches, they have to be careful about versioning, because any change to the data structure might not be understood by the cached js program. That's probably why the first call to D() is always with the parameters "v", and then a unique id. If the javascript doesn't know about this data version, it probably goes and reloads itself.
Overall I'm mighty impressed.
p.s. if you're interested, the fancy javascript I mentioned is as follows:
javascript:(function(){alert(document.getElementsByTagName("FRAME")[0].contentDocument.getElementById('tlist2').contentDocument.body.innerHTML.length);})();
Pasting that into the urlbar of Firefox when you have your inbox open will report back the size of the messagelist html.
June 24th, 2004 at 10:40 am
Yeah, I did not trust it so much as assume that the Javascript was doing most of the work in the parent frame. So I assume that when it gets a refresh it does not transfer web pages, just data which the Javascript can parse and tell each page fragment to redisplay.
Making it work in many browsers is nice, but I am sure they have the resources to test it and make any necessary workarounds. But these days it is much easier to write standard Javascript against the DOM standard. Both the current MSIE and Mozilla versions support it pretty well, and it seems Safari keeps up pretty well. I do not care much about Opera since they are a weak minority and they should ensure they keep up with everyone else. I would personally do little more than just test in their browser occasionally. But I really do not bother.
I mainly avoid Javascript, but now I am finding there are better tools to help write Javascript and when I know I have the syntax right, the browsers actually work right. It is not like when I ran stuff in Netscape 4 and while my code was right, the browser would choke on it. I was forced to massage it into working.
The cool tricks are when you can combine a CSS and JS solution to cause useful page effects, like causing a floating div to show/hide based on other events.
January 19th, 2005 at 10:59 am
Do you know how to do the floating div effect in GMAIL?..i would like to implement... thanks
M. Flores
January 19th, 2005 at 11:19 am
I have a basic example of a floating box.
http://brennan.offwhite.net/floatingbox/
You can review the Javascript in box.js to see how it is done.