At exactly 1:30 PM two years ago I was doing my exit interview at Microsoft.
I told the HR person the reason I was leaving was the lack of innovation and opportunities at Microsoft. To my surprise, she said that was the number one reason most Microsoft employees leave.
That was probably my #2 reson, but that's what she cared about. My #1 reason was to create a successful company. Nope, let me correct that. The #1 reason for me to leave Microsoft was to help people create their own web presence.
About 10 days ago I installed IE 7 at my home. I don't know if it is just my computer, but it takes longer to open the browser, to create new tabs and even to click on links if compared to IE 6.
The only things that I have installed is the Alexa Toolbar and the Google Toolbar.
Firefox is much, much faster.
Have you seen the same slow down when you installed IE 7?
UPDATE: Jamie (comment below) ask if I changed my start page. No I didn't, I always use "about:blank" as my homepage. I can't really confirm, but I'm start to think that Alexa Toolbar makes IE 7 super slow.
Friday we announced a few cool new features for Sampa. You can read more on the Sampa Blog (http://blog.sampa.com), but if you are in a hurry, the abstracts are:
Add Pictures via Email (http://blog.sampa.com/blog/e/Add-pictures-to-your-albums-via.htm) You can also send pictures directly to your photo albums. Each photo album has their own email address. Imagine this: You receive an email with a bunch of pictures from a party that you went to, forward to your site, and they appear on the site.
Post bookmarks via Email (http://blog.sampa.com/blog/e/Add-links-to-Del-icio-us-and-Blu.htm) I never use this word on my blog, but there is no other way to describe this feature than fucking cool. If you integrate Del.icio.us or BlueDot you can send an email to your site and have the links on that email be sent directly to Del.icio.us or BlueDot.
Let me know what you think and what else do you want on Sampa.
Somehow, AJAX became synonymous with great user experience and that is the same thing as saying that HDTV signals will result in better TV content.
Some sites are using AJAX in the wrong place.
IMHO, Ajax works great if you have a dynamic UI that can't load all data to do its job at once, or, the data is dynamic and refreshing the page costs a lot more than the AJAX overhead.
These are a few examples where Ajax makes sense:
Google Suggests: You can't have the client load 60 million query terms, so, as the user types characters, you only fetch from the server the top 10 terms that start with those characters.
List of Cities: If you want to have a rich Address input that suggests countries, states and cities, you might want to do Ajax since loading all countries, all states and all cities of the world it is certainly too much.
Large Lists: Pictures (Flickr, Sampa), Pages, Documents, E-mails (OWA, GMail), etc. If you have a list with 10 items, AJAX is useless. Embed the content on the page and you're good. If you have lists with 100 or more items and each has several attributes, using AJAX allows you to do nice paging, sorting, without the user having to wait an eternity for the content to load.
Here's where AJAX is just plain unnecessary (some are cool, but not necessary):
Subscribe to a site e-news. Instead of sending you to a page to confirm, they just do an AJAX call to register you and give you the OK right there on the page.
Post a comment on a blog: AJAX posting is neat, but not necessary. I would say that it is sometimes confusing, since users are so used to clicking on a Submit button and being sent to a confirmation page.
Now, some dumb examples of AJAX usage:
Loading a page, and firing an AJAX call to load 10 items from a list.
Loading the name of countries.
Why do I say it is dumb to do those things? Four reasons: Latency, overhead, parsing, rendering time.
Latency: Every AJAX call requires at least one HTTP request and one HTTP response. Even on the fastest network that will be several milliseconds, maybe more depending on the state of the network and the load on the server. That can also be aggravated by other calls being done simultaneously to the same server, like other IFrames, Images, JS Files or other AJAX calls.
Overhead: The HTTP Request/Response overhead of an AJAX call can be 1-2K just for the HTTP Header, TCP Header, IP Header, etc. This doesn't include the data that is being sent back. So unless, you are sending a lot more than 2K of data back, just stick it on the page.
Parsing: I know this is so fast that might be insignificant, but you should be aware that every time there is an AJAX response, IE or Firefox needs to parse that content into the XML DOM.
Rendering: Instead of sending plain HTML embedded on a page, you send an HTML+JS to the client that makes an AJAX request, receives a response, you parse the content and now you need to build the HTML on the client and stick it into the current view. This can easily be done the wrong way and make the page/browser unresponsive for several seconds. There is nothing that makes a user angrier than unresponsive UI (ok, maybe there are a few things).
Back to my dumb examples...
Loading a list of 10 items, like for example, tags/categories being used by a blog into an auto-complete box is just stupid. Actually, loading a list of 50 or 100 tags using AJAX continues to be stupid. If the user uses 100 different tags and each has about 10 characters that would be just about 1.5K of data in JS (or 2K in XML). It is much easier to stick on a JS variable on the page. Want to do it really fancy? Generate a JS file on the fly that has some checksum, like mytags357395.js and include all the tags on that file, if tags are added/removed/renamed a new JS is generated, otherwise the content is cached on the client.
The list of countries is also stupid not only because the name of all countries can fit in just 8K of data (assuming all the <SELECT>/<OPTION> is present as well), but also the name of countries don't change (mostly). A third reason for not using AJAX on this case (assuming that you are asking the Country because he/she is subscribing to your site) is because you will prevent users that have JavaScript disabled, or, are using a browser that doesn't support JS (e.g., Mobile phones) from using that page.
Conclusion
If you want to use AJAX, do so for the right reasons and if you are doing a large scale website, make sure to measure different solutions to find out if certain things are really worth using it.
"...It's my hypothesis that users often go hunting for coupon codes after they see the 'Coupon Code' or 'Promotion Code' textbox on a shopping cart checkout form ..."
Fantastic! I do it all the time. Chad is dead on.
Now, here comes the description:
* Simple rectangular box with clear call-to-action and a search box
* Coupon results should return asynchronously as the user types
* Should be portable and scalable in presentation and implementation (center-column feature on some pages, side-column on others, eventually a toolbar or widget)
There are three mistakes on the description, but I'll only talk about item # 2 above: "returned assynchronously as user types", a.k.a., an AJAX-based search.
I worked on Search before. Search-as-you-type is very powerful on client software, if implemented right. Users do get very annoyed if every key that they type takes a half-second for the UI to become responsive again. In the context of web-pages and browser that is very easy to happen. You have to have a server that responds in fantastic amazing time for that to be valuable, otherwsie as the user types as soon as he gets the response from the first AJAX call he already typed a bunch of other characters.
Now, I want to see a web-based search built on top of AJAX that is capable of reading the response and render the content as the user types. It will be very annoying because browsers take time to render content. Imagine if you are typing "sony digital camera" and for each letter there is an AJAX call and re-rendering of the results. Gosh. That would be overkill.
Yes, that can be optimized, but there are many gotchas: If you optimize for waiting a pause between keystrokes, then, users that type fast once have any benefit, because the system will wait them to type the entire phrase. Basically what you did is you saved the user from pressing enter. On the other hand, if you decide to do every 3 keys or every second, whichever is first, you are back at the problem that you'll have up to 7 re-rendering of the results.
The point that I'm trying to make is not that AJAX-search is bad, but that is hard to do, and more importantly, how is that relevant to a "Coupon Finder" embedded inside Judy's Book site?
You know the coupon finder that I want? A browser toolbar/extension that when I'm about to finish my purchase on Best Buy immediately tells me that there is a coupon for that site... "do you want to go to Judy's Book to see more about it"....
Subscribe to this Site
), but if you are in a hurry, the abstracts are:
September, 2007