I encourage every architect in the world to design custom light switches for every building and position them in locations unique to each building. That way, everyone who enters any building has to first figure out how to identify and operate the light switches.

Sorry I'm so crabby about this. But, by golly, Google's new "button" really calls out for the question "Why?" And to think on top of it all, Google has to go through a lot of trouble (probably Javascript trouble, though I haven't studied the code) to make these silly "buttons" tabbable. Pretty soon, every Web 7.0 kiddie will try to replicate Google's "buttons" and fail to make them tabbable.

Agree: "Desktop clients still have a bright future thanks to stuff like this."

"Really, you find this impressive? I find it sad. 20 years of GUI evolution leads to faking round buttons and color gradient with a ton of CSS and HTML?"

Google is pioneering in the UI design area here, and they have a track record of supporting standards, sharing their technology and being developer friendly. To improve the usability of the web they are introducing controls that unleash the capability of the web. After trying out these buttons, I found that they are bliss for a keyboarder. Labeling and archiving before was abysmal, and different across browsers. Now it is a pleasure to use.

LIghtweight multi-platform XUL is something I think may be the answer. I'd like to take browser's connectivity and JavaScript VM, but non of HTML/CSS nonsense. XUL seems to work, and can be served from the cloud, but it's not easy to program for.

One positive thing about XUL is that it makes the GWT/pyjamas (pyjs.org) approach seem reasonable if not downright natural.

I strongly disagree that desktop clients have a bright future.

1. If you've ever tried to do cross-platform desktop client GUI work you'd know that getting it to look good on every platform is a nightmare. It's really no different from where we are with RIA.

2. Right now there's a large amount of work going into js frameworks that means that we'll see these techniques become standardized over time.

3. If you look at desktop clients there's actually a lot of innovation in terms of small UI components (see most things that Apple is doing) and so desktop clients are by no means static.

4. As js and the frameworks improve we'll see more and more applications move into the browser. At my current startup we are working on a very rich application and there was no question of doing a native desktop client, there was just no point tying ourselves to a specific OS.

I do find it impressive. I've tried it before and not gotten it too look that nice. I just didn't use enough divs, apparently. It's about 6, nested. BTW, the buttons aren't round.

I agree with you that web design with HTML is pretty sad in comparison to just about any purpose designed desktop client library. You get about 1/10 of the form controls you get out of the box with, let's say, VB6, and it's tough to extend.

Why? Creating cross-platform non-native custom widgets on the desktop isn't much easier.

If a desktop client is an option, so is "use [Firefox|Safari|IE7+] is access this app, or live with slightly less polished UI. kthxbye."