Why Google Maps wins

It occurs to me that the real winning feature of Google Maps is not its DHTML-goodness, its endless scrolling surfaces, its Ajax underpinnings nor its satellite photo views. Rather, the winning feature is the user types the address into a single input box. No more entering street address, city, state and zip into separate boxes. You don't even need commas, AFAICT.

It seems like such a trivial detail, but to me it's everything. Why can't every address input interface be that simple?

Summer Slump

This is one of those posts to inform readers that blogging will continue to be light over the next few weeks as things get crazy with the music thing the day job is taking away what little time is left. Plus, I've got a backlog of Lost episodes to watch.

Of course, I fully expect to discover a bunch of post-worthy things the moment I click "Save" on this entry :)

In the meantime, behold the wonder that TiddlyWiki has become. It's got some of the cleanest JS code I've seen in a long time, and local load/save options? Heaven. I came up with a hack to add checkboxed list items but it's so ugly and wrong I'm too embarrassed to release it.

Secure IFRAME gotcha

A simple caveat from an anonynmous JS whiz: when you create a new IFRAME element on a secure page, IE sets the default SRC to a non-secure blank page, thus popping a security alert dialog.

var el = document.createElement('iframe');

Since creating IFRAMEs in IE this way is already problematic, the solution might be to insert the IFRAME with innerHTML rather than using createElement. YMMV.

Ajax @ Amazon?

Given that I was one of the lone attendees without a demo to show at the Ajax Summit earlier this week, I wish I had known about Amazon's new Diamond Search, which uses a combo of DHTML and Ajax-style backend communication to allow users to narrow search results in a purely visual way. Move the sliders back and forth and watch as some mysterious process fetches the number of search results in real time.

Full disclosure: I didn't build this and have no idea how it works under the hood. A press release went out last Wednesday and the app has been publically available for at least a week. News to me.

Ajaxed out

For the past two days I've been attending an "Ajax summit" event thrown by O'Reilly and Adaptive Path. I think "summit" is an apt term to describe it, as it included a cool cross-section of individuals from various disciplines — web developers, network engineers, interaction designers and others — and many, many people who've been doing this type of work for a long, long time. I thought this was an important distinction, as the application of Ajax (however you might define it) brings new solutions to old problems while creating new problems that reach outside the scope of what is generally thought of as "webdev."

I'm way tired, so here're some frazzled notes and takeaways.

Ajax, grunge rock and convergence

I found a parallel in the thoughts of Generation X author Douglas Coupland on the hypermarketing of the twentysomethings in the early 90s:

Generation X's tiny, March 1991 printing had no publicity, and received almost no reviews. But that summer a Texan my age named Richard Linklater released the movie "Slacker"...And in Seattle, a new form of music was exploding...As the media goes, two's nothing, but three's a trend. Thus were born the most abused buzzwords of the early 90s: "generation X", "slacker", and "grunge".

Similarly, I felt three things happened to converge, coincidentally: the flattening of the browser landscape; the buzz built around Google's trial-balloon apps like Google Suggest, and the coining of the highly-buzzable term "Ajax."

Thus, Ajax is the GenX of web development: suddenly a movement and a market where before there was just a bunch of neato stuff.

What Ajax is, what Ajax isn't

No attempt was made to define "Ajax" or identify the patterns inherent in an Ajax application. No one was gonna touch that with a twenty-foot pole.

That said, I have my own thoughts on what Ajax is, and I think if we want to effectively communicate to people that Google Maps != Ajax (more on this below) it's important to recognize the larger components:

1. Ajax the methodology - this is the concept, the approach: fetching small pieces of data from the server, without a whole page refresh.
2. Ajax the technology - the libraries and toolkits: JavaScript, Flash, XML, HTML, etc. whatever enables #1 above.
3. Ajax the implementation - it can be as boring (and useful!) as a "smart" HTML form that validates fields as you tab between them, or as sexy as Google Maps.

Gotta keep 'em separated, because we gotta be prepared for the questions: what is Ajax? Is this something we should be doing? I think our energies are better spent on deciding whether the Ajax methodology is an appropriate approach to solving a particular problem.

For it all to work, the methodology must be a win for the business person, the technology must be a win for the IT department, and the implementation must be a win for the user. If cost > value in any of these, don't bother. "You're building a car around a bicycle." (source)

Threats

Skip Intro - we need to avoid a repeat of the "Flash is 99% Bad" debacle that took years for Macromedia to shake. If there's no win in applying an Ajax approach, don't bother.

XML Fairy Dust - for awhile in 2000, it seemed that XML was suddenly the answer to everything, a magical fairy dust that increased ROI and garnered more seat licenses. It wasn't. Neither is Ajax.

Microsoft? Nah, I don't buy this. They gave us XmlHttpRequest and I doubt they care enough to break it.

Is Flash Ajax?

No. Is it capable of enabling an Ajax-style applications? Yes. Dunno what's so hard about this question.

Browser Beefs

Flickr's Eric Costello gave a presentation that was part satisfying rant at the remaining dissimilarities between the browsers, and vented some frustration at long-standing and long-annoying problems like the Back Button Issue, DOM manipulations that aren't cached, CSS-immune FORM elements, etc. It was a high point.

Etc.

Desktop apps are trying to be more like web apps, and web apps like desktop apps. Where do they meet? (Later: who cares?)

Still need a killer app. Everyone points to Google Maps but it feels overblown. I think the real value will come from making boring stuff better, making static interfaces responsive. Anil: making web pages act the way users expect them to act, but who have been trained to expect less.

Derek Powazek: full-page request/response is to email as Ajax is to instant messaging. Smaller chunks of data, in a simplified format, traveling faster.

Saw lots of demos. Not gonna talk about 'em. Suffice to say there's some very cool stuff being built.

Jason Kottke rolled out Ajax-powered blog archives on his website while the sessions were going on. Nice, but I think Dunstan Orchard's live search is equally impressive (and Dunstan's attention to progressive enhancment is admirable).

I'm pretty sure I was the only one (out of about 40 attendees) without a laptop. About 70% of laptops were Macs. At times I felt like I had forgot my duck. At other times, I was glad I didn't have the distraction of email, IM, etc.

Probably more to report once I get some rest.

Have we won yet?

A blast from the past: Why DHTML Will Win, by Steve Champeon in the now-defunct New Architect magazine, June 2002. I especially like this bit here:

DHTML, you say? Tried that, hated it. It didn't work the way you had expected in [insert your favorite browser here], right? Well, it's time to take a second look. What you may think of as DHTML has advanced greatly since the early days of Web design. Back then, Microsoft and Netscape were in a pitched battle over which Document Object Model (DOM) would rule the Web: document.all or document.layers. But that has all changed. In the end, reason and the W3C have prevailed. Even Netscape, the company that created the element, has abandoned it in favor of the standard <div>. Developers no longer have to code for two different APIs.

So why the resistance to DHTML? Perhaps it's time for a new name.

It's been three years. Has DHTML won?

Who needs XML?

Been thinking about the "and XML" part of Ajax and wondering why we need XML at all.

For example, 37 Signals recently rolled out its new Backpack web-based PIM application, and I've read a few complaints about how it doesn't work in browsers like Opera and older versions of Safari, presumably (I haven't looked under Backpack's hood personally so I'm going on word of mouth here, careful!) its heavy reliance on XMLHttpRequest for client-server data transfer.

(BTW, that's not meant to be a negative comment on Backpack on my part. Backpack looks VERY cool, and I intend to play with it extensively.)

So here's my thought: what's wrong with just the "AJ" part of the Ajax equation? Seems to me that there are lots of sturdy JS libraries that can deliver and receive pseudo-asynchronous data to/from the server that don't require the overhead of an XML parser. It's relatively easy to bootstrap a JavaScript message format at the server level, so why do we insist on pushing XML back the browser?

The obvious reason is, I guess, compatibility with other apps that read XML, but that doesn't seem particularly compelling when 99% of the apps I've seen are built to be run in a JS capable-browser. Why wouldn't you optimize your data format to suit the target environment?

As far as XMLHttpRequest is concerned, as one Opera user stated, "shouldn't it just work without it?"