Looks like google has been using CSS from the YUI javascript library for the google personalized homepage. As Pat Cavit writes, "YUI is so awesome even google uses it".

Now some would be tempted to make a fuss over the fact that google has technically violated the BSD license that YUI ships with by removing the copyright notice from the source code (which was really silly, since it's just in the source code: it doesn't appear on the page at all).

But I think Yahoo should instead take this as a compliment to the awesome work that the YUI team has done over the past year. If the google devs are happy with how the code has worked, maybe they can write a customer testimonial for the YUI marketing folks to put on the YUI web site. Or maybe next year the google team can demo at the YUI party?

OK I'm a few days late with this one. But Yahoo has announced that they will be hosting all current and subsequent versions of their YUI javascript library, for developers to use in applications, free of charge.

Why is this a big deal? Well, let's take a look at some bandwidth stats for slideshare. 12.7% of our hits, and a monstrous 40% of our consumed bandwidth, are js files!

SlideShare don't happen to use YUI (we use prototype and scriptaculous). But if we did, we would snap this up! Yahoo is effectively giving one more piece of distributed infrastructure to entrepreneurs looking to bootstrap a web startup. This is really generous of them.

Thanks, yahoo!

I'll be going to the Real World Ruby on Rails conference in Santa Clara tomorrow. The seminar is co-located with the AJAXWorld conference, so there should be lots of rich client geeks to hang out with. Fun!

I made a little widget for my blog that supports both bookmarking (to popular bookmarking sites like Digg) and subscribing to my site (via popular RSS readers like BlogLines). The widget uses a little javascript to hide the (hideously tacky) icons of the various sites until the user clicks on it. Check out the top right corner of my blog, or the bottom of this article, for a demo.

The cool things about this widget are:
1) It is much less ugly and distracting than current solutions (which embed a gaudy list of icons into your blog).
2) It is independent on any server-side environment: because it's all in javascript, it can run in WordPress, Moveable Type, Drupal, or any other blogging engine or CMS. In fact, it can run in any web page at all.
3) It frames RSS subscription in language the user can understand (e.g. "Add this to Bloglines", rather than "XML").

Laszlo systems has always postitioned OpenLaszlo as a language that frees users from platform lockin. The markup happens to compile down to Flash, but the potential was always there to compile down to another run-time format, such as dot net. But only the potential. Until now. OpenLaszlo will soon support AJAX (a preview of this functionality is being demoed at etech as I write).

Adobe just announced the FLEX-AJAX bridge (FABridge), an open-source component that facilitates communication between AJAX and FLEX code. The meeting where it was announced showed amazing integration between AJAX applications built with Rails / prototype and individual screen components built with FLEX.

Update: here's the blog entry with all the demos and details.

I've noticed another new AJAX convention cropping up in a few places that I though I'd share. It solves a real problem in an elegant fashion: how to handle registration of new users.

Every site that requires a login needs to provide a way for new users to register. The tradeoff between supporting new users and existing users is always tricky: for example, most brokerage sites are oriented towards marketing to new users, and have a little link in the corner where existing clients can log in. Other sites orient towards existing users, and new users are shunted off to a registration page.

Ideally, we’d keep the user on the same page. With a little bit of Javascript trickery, this is possible. The best example of this I've seen so far is in ZohoCRM.

The login widget starts out oriented towards existing users.

I recently added an Accordion widget to the right panel of my blog. The accordion has the last five entries for each blog category, so the reader can preview the contents of a category without leaving the front page.

I used the Accordion Widget from the OpenRico library for this project. It took very little time to implement, and was a fun little "quick win" project. This is the kind of thing that AJAX can be great for: adding a little interactivity to a basically static page.

The best tool for debugging JavaScript on Internet Explorer is the Microsoft Script Editor, a free component of Microsoft Office XP/2003. There are other options, but they are less attractive: Microsoft Script Debugger is not very powerful, and Visual Studio .Net is an expensive purchase if all you need is JavaScript debugging for IE.

Microsoft Script Editor is a powerful debugging tool, but getting it to work takes a bit of doing. The following is a quick guide. I've also included a slideshow (hosted on slideshare.net) that shows the details of how to configure IE.

MacRumors has released the results of their experiment using AJAX to deliver presentation updates from MacWorld. The numbers are simply jaw-dropping, a 6X reduction in bandwidth.

"[We] consumed over 32 GB of bandwidth during the three hours surrounding the event. (For those interested, a non-AJAX version of MacRumorsLive would have required an estimated 196 GB of bandwidth over the same period of time)"

For sites that experience a highly variable load, AJAX can mean fewer servers, lower bandwidth bills, and less risk of failure. This is a huge, public win for AJAX as a bandwidth optimization strategy.

A new AJAX convention cropping up in a few places, one that is easy to implement and has real benefit to end users. I haven't found a description of it anywhere, so I thought I'd write it up here.

The basic idea is that user controls (typically for editing the displayed data) should be hidden from the user until needed. At "rest", an area of the screen displays information in read-only fashion.

On clicking an "edit" button, the div expands to display the widgets for changing the data.

Apache just received a proposal to bring AJAX tooling to the Eclipse IDE. The proposal is sponsored by IBM and Zimbra, and is championed by Sam Ruby. Toolkits that will be incorporated into the intial version include Zimbra AjaxTK and Rico. [via]

A recent survey by Ajaxian (writeup here, raw results here) revealed that the 40% of developers working with AJAX are not using any higher-level APIs or toolkits! This is really disturbing: trying to make javascript work across all browsers is really hard, and developers are buying themselves a great deal of pain by not standing on the shoulders of those who came before them. Why aren't more developers using these frameworks?

Flash gets a bad rep among programmers. The programming model is very different from typical programming languages, and the uses of the technology have typically been annoying (banner adds, skip-intro splash pages). More recently, AJAX has emerged as an extremely popular way of introducing dynamic behavior into web pages. So why do we even need Flash?

LaszloMail, the new email service from LaszloSystems, will be opened to the public in the next week or so. I was lucky enough to get a beta account, and spent some time playing with the application.

The new Yahoo! maps (released just over an hour ago) is amazing. The app is very smooth and slick, and makes heavy use of yahoo yellow-pages data. It's integrated with real-time traffic info as well. The experience of dragging and dropping the map, and zooming in and out, is _nearly_ as smooth as google maps (hey for day one that is terrific. There's lots of room for optimization with this kind of code).

Yahoo! is playing the fast follower game, and playing it well (see also an earlier post on the new Yahoo! email client). And they're obviously thinking hard about using the right technology for the right job, rather than simply copying the google approach.

The google proposal to provide wireless access to all of San Francisco is a bold move by google to increase the mobile use of web-based applications among early adopters.

The major trends in IT today reinforce each other in a powerful way. The two technology trends (Web Services and Rich Clients) are tailor-made for the new business-model trend (On Demand Software). The two technology trends also reinforce each each other, creating a self-reinforcing web of interactions that will accelerate once it gains momentum, and may not stop until it has absorbed most of the software world as we know it!

AJAX Info writes about the network effects that are driving AJAX adoption in the enterprise and consumer space.

Programming languages in general benefit from network effects. To boil this down we could say that as more people use a particular language, the value derrived from using it increases exponentially. An example of this might be that as more people start using Ajax, more resources, information, and 3rd party components become available.

Another key point is that AJAX is a continuous, rather than a discontinuous technology. It builds on existing skillsets that web developers have in a way that some other technologies don't.

Ajax offers something else too. It`s a way for web developers to leverage their current skill sets to achieve the first goal: build better applications. JavaScript and DHTML aren`t new, and more importantly: corporations are loath to acquiring 3rd party software components that use technologies their in house developers have no skills with. It doesn`t make business sense to jump into technologies that have rarified skill sets unless you have to because it`s expensive to be retraining your employees or outsourcing development work to specialized consultants.

He also presents a nice comparison of AJAX to some alternative rich client technologies. The upshot? Vendor Independence and Skill Set Transferrance are the major differentiators. Read the whole thing!

Alex Bosworth articulates a vision of what Flash is good for that matches what I've experienced. Specifically, Bosworth mentions video (one or two-way) / audio (one or two-way), combined with data sockets ("push" instead of "pull) making Flash a crucial component of next-generation web applications. Macromedia recognises this, and is working hard to make Flash and Javascript work and play well together.

Why don't more people think of using Flash in this way? In a word, positioning. Bosworth writes: I do think there's a very distracting red herring here, and that's Flash's rich user interface abilities. Every flash demo I've ever seen focuses on great looking shiny buttons that look like you took a slick win32 app and plopped it down in a browser window.

Just got accepted into the Yahoo! beta. This is the first web-based email I would consider using. If I didn't have multiple email accounts, I would probably switch. Differences from oddpost: 1)doesn't use a popup window, 2)Doesn't seem to have rss integration, which oddpost has (seems like an odd decision, maybe they want to save something for the sequel?).
I won't post screenshots 'cause you can see them here if you're interested.

This NYT article NYT article describes the new AJAX-driven GAP shopping experience (deployment of which apparantly required shutting down gap.com for THREE WEEKS!) More blog coverage here, here and here.

AJAX debuting on the shopping cart actually makes perfect sense. Shopping cart bailouts cost ecommerce companies millions, so the ROI of improving the shopping experience is extremly high.

I hinted in my last post that one consumer company is showing signs of embracing the "just like the desktop" AJAX approach. That company is Yahoo!

There's something very interesting going on right now in the enterprise software world. For the first time since the invention of the personal computer, the UI paradigm being used by coders building business applications is richer and more powerful than the approach being used by coders building consumer applications (which usually get all the glory). There has never been a better time to be in an enterprise UI developer.

Jep Castelein of backbase has written a nice summary of current thinking on AJAX applications and latency. He points out that most AJAX developers are taking the easy way out, having synchronous logic execute when the user performs an action. This causes a delay as the data is fetched from the server, which is exactly what we are trying to avoid by using AJAX!

AJAX and rich clients are indeed intimately related, contrary to what some people say. And it's not just that they sprang up at the same time, in the same companies, and are therefore associated with each other.

Stewart Butterfield brought this point home at the BayCHI Web 2.0 panel. The following is a transcription [via] from the podcast of the event:

A few months ago, in the aftermath of the etech BOF on AJAX/RIAs, I started an email list on AJAX / RIA. I have never publicized the list or even told anyone about it. But every couple of weeks someone joins the group! I've decided to publicize the list so that it has at least a chance of achieving critical mass. If anyone is looking for conversation about AJAX / Rich Internet Applications, the list to join is ajax_and_ria on yahoogroups.

Attention all cars. AJAX is not Web 2.0. In fact, it is in many ways in opposition to web 2.0. AJAX applications create web-pages that are less machine-readable / linkable (try bookmarking a google map). This is a mistake that I have seen some otherwise smart people making, so it's important to clear this matter up.

Clinton agrees with me

Before we get to Web 2.0., it is useful to consider what does not characterize Web 2.0. For instance, for all of the love that rich client-side AJAX applications such as Gmail have earned, that alone does not make them Web 2.0. Simply having a Flash or WML interface or a XHTML+CSS homepage is not enough to qualify. In fact, in some cases these sites actually lock in more control over the data and manage the presentation even further.

Metafilter has a cool new feature. There's just one problem: even the users who like the feature in the abstract find it a little annoying in practice.

Anil dash is less than impressed by the latest hot new ruby on rails startup.

Anything you can do in Flash, you can do in AJAX. But just because you can doesn't mean that you should. Are AJAX developers going to have their own "skip intro"-style backlash?

It's great to see developers starting to think seriously about what kind of best practices to use in javascript development. Developing with a loosy-goosy scripting language like JavaScript or ActionScript requires MORE code discipline, not less. Since the language doesn't force you use best practices, you have to force yourself. Otherwise, someone will be stuck maintaining cruddy old code that nobody quite understands anymore. I've been there, and it's no fun. Here are the highlights:

Sabre Airline Solutions has open-sourced their AJAX API (called Rico. I saw some applications build with this API a couple of months ago, at the AJAX summit. I don't know how easy it is to code with, but I can tell you that it demos _very_ well.

Bigempty's coverage of the AJAX conference has been superb.

Day two of the O'reilly/Adaptive Path AJAX confab in SF started as a continuation of day 1, with a series of presenters showing off their latest AJAX tricks.

More from the AJAX summit

David Heinemeier Hansson just gave a nice overview of the AJAX-related features of the ruby on rails API. It’s impossible to evaluate an API without using it (at least for me), but this stuff looks pretty neat! The basic idea seems to be minimizing the complexity of the code on the client (since cross-platform javascript development is such hell). They use .innerHtml to rewrite the html that displays to the user, and keep html generation server side. Cinematic UI effects (like fading) are baked into the API. David is a funny guy. He REALLY hates DOM-based javascripting!

Many of the morning presenters were presenting little web tweaks: tactical improvements to a site that make it just a little bit faster, easier, or have a clearer workflow. Technorati and Flickr both showed the minor improvements that they have made to their sites. These tweaks sound like they were a LOT of work to do. This is a big problem with AJAX: doing it “right” (for all browsers) means taking on a lot of technical complexity.

I’m at the Oreilly AJAX summit today and tomorrow (speaking later today).

Here’s the speaker list and the wiki.

Right now Jesse James Garrett has just wrapped up the keynote. No surprises so far

Anyone know of a good javascript accordian widget? I may need one for an upcoming project. Treeviews seem plentiful, accordians are a little harder to find...

I am dumbfounded!

Adobe has a dry press release, Mike Chambers provides some thoughtful commentary, and Mark Cantor spews some bile on the proceedings. Om Malik and Genuine VC cover the business angle. Slashdotters and Metafites have various opinions, as usual. Ross Mayfield also has a nice summary.

Update (4/22/05): hilarious translation of the dry Adobe press release.

I have nothing useful to say about this, except that I've worked at companies going through complex buy-outs, acquisitions, mergers, etc: it's ALWAYS a distraction, it always slows things down.

Xamlon has released to beta a new developer product (Xamlon Flash Edition) that will compile a .Net program down to a SWF runtime. Like most good ideas, it seems obvious only in retrospect. News stories , many blog postings, and even tutorials all seem pretty postitive so far. Most criticisms seem focussed on SWF as a deployment technology rather than Xamlon per se. The dubious buzzword AFLAX (AJAX with flash) is used to describe what is really a standard Flash application.

I have never been much of a game player. Apart from the occasional game of Solitaire during college (and a seriously disturbing brush with Grand Theft Auto last year), I managed not to get addicted even while hanging out with game obsessed geeks, and building Tetris for a computer science course. I would look at people addicted to computer games, and congratulate myself on knowing better.

The newest release of the Laszlo Presentation server (version 3.0b2) allows developers to use Laszlo technology (LZX) to develop swf-based applications, without requiring IT department to run the resulting applications using the Laszlo presentation server.

So the RIA BOF at etech was really great. About 45 people showed up, far more than I was expecting, given the short notice. There was a lot of excitement about AJAX at ETech. The term kept on being mentioned by different presenters, and I think that contributed to the number of people who chose to attend the BOF.

The discussion was very free-ranging, with a lot of smart web developers from various companies sharing their tips and tricks. Below are some of the insights that really stuck with me.

The AJAX meme continues to percolate on the internet, with a nice summary article from QuirksBlog that links to some of the more interesting analysis. Geeks everywhere seem fascinated by the fact the XMLHttpRequest can be used to fetch data behind the scenes and serve it up when the user asks for it.

XMLHttpRequest is a handy and mildly interesting bit of plumbing. The fact that it’s a fairly simple API that you can read about and comment on makes it handy blog fodder. But the real differentiator in all of the new google applications is NOT in that they use XMLHttpRequest (they could easily use an iframes hack instead, as an earlier commenter on my site pointed out). They could even have used Flash!

The client-side predictive engine that google has built into their new applications is what really makes them powerful.

I’m organizing a BOF (Birds of a Feather) on Rich Internet Applications at the ETECH conference in San Diego next week. We’re meeting at 7:30 PM next Tuesday at Ball Room C of the Westin Horton Plaza in San Diego. It should be a lot of fun. RIA has been a big theme at previous etechs, so it should be a good bunch of people.

O'Reilly says that evening entrance is unmonitored. Feel free to join in whether you're a conference attendee or not!

Laszlo has been working on this thing for a while now, and I've seen demos of it a number of times. But for it to be actually in production is a big deal. Earthlink and Laszlo should both be proud. Initial reviews seem positive.

The interesting thing, notwithstanding this excellent work by Lazslo, is that Flash RIA development has lagged JavaScript RIA development in this important segment. both oddpost and gmail beat flash technology to the punch, with remarkable JavaScript RIA email clients.

What are the other "obvious" niches that RIA technology will prove itself in? I've heard rumors that the oddpost boys are working on a spreadsheet app (their initial idea before they did the email client). None of the javascript text editors are any good at all, so that's an obvious candidate for some enterprising RIA developer to tackle. Photo-editing is also a pretty obvious one (given that people already are storing their images on sites like Flickr). The interesting thing is that all of these things are re-implementations of software that was first implemented on the client. Look in your "Programs" directory on your PC and you'll probably get a good idea for an RIA.

Javascript RIAs (aka AJAX) don’t come close to the interactivity that developers can implement using technologies like Flash or Java. For example, there is no easy way of integrating with audio and video content, there is no ready-made toolkit of application widgets (tree-views, data-grids, etc). There are undeniable advanatages to the JavaScript RIA approach, however. So how do you decide whether a Javascript RIA (or “AJAX”, if you must) or a Flash RIA is right for the project you’re working on?

Check out this JavaScript RIA! (Via metafilter)

This is exactly the kind of thing the Macromedia is always showing off in their demos. Drag. Drop. Animations happen which guide the user. It’s the kind of stuff that Lazslo talks about with their concept of a “cinematic user experience”.

JavaScript RIAs are coming of age, and as I wrote yesterday, animations and self-modifying html that doesn’t need to go back to the server are playing as important a roll as the XMLHttpRequest API. A nice library for doing drag-and-drop in JavaScript has recently become available that makes this kind of code much easier to write.

A recent article by Jesse James Garrett crystallizes what many in the Rich Internet Application developer community have been saying ever since the gmail beta: Javascript RIAs (which Garrett awkwardly attempts to brand as “AJAX”, for “Asynchronous JavaScript and XML”) seem to be finally coming of age. These techniques have been possible since at least 2002, but have been recently popularized by the never-ending stream of cool javascript RIAs from google (gmail, google suggest, google maps…).

Most major news organizations are using RIAs in their election guides this year. The common factors are: one page design (multiple summary views with drill-down options), animated transitions from one piece of information to the other, and exceptional graphic quality. Anyone working on using RIAs to visualize large data sets should have a look at these various sites and how they approached the problem. What follows is a quick review!

The press release says it all. Additional coverage in the server side and david's blog. The code will live here.

Rich Internet Applications are fast. When you click a button or push a lever, things tend to happen right away. That fast user experience is a primary reason that developers and designers are attracted to RIAs. Latency is reduced (after the initial download) for two reasons
1) Because the UI is inherently preloaded: it is not being shipped back and forth every time the user performs an act of navigation.
2) Because data can potentially be preloaded: the application can download data in the background that it thinks you will use, before you request it.

Geeks spend a lot of time talking about what's possible with a particular technology. We pride ourselves in being able to wring every drop of interactivity out of a platform, of doing things with the tools that the toolmakers never would have thought possible. As a result, any argument about software platforms often falls into the following pattern: Detractor of Platform A will say something like "you can't do drag and drop in Platform A". Supporter of Platform A will respond that you can so drag and drop in Platform A, and will post the code to prove it. Score one for the supporter: the detractor simply wasn't able to use the tool.