JD on EP

NB: This isn't a report on the event so much as my recollection of what I learned at the event. Quotes are synthesized from paper scribblings. My writing is in no particular order; not chronological, not priority, more based on how I type this the first time through.... a brain dump. Caveat lector fer shure. ;-)

Ben Galbraith and Dion Almaer are solid presenters -- they're relaxed, they know what they want to say, and they definitely engage the audience. I shouldn't admit this -- I was worried that I might feel like I was at a Multi Level Marketing or political-lobbying meeting -- but these folks seem real to me. They seemed sensible and sober, and (most importantly) had a sense of self-deprecating humor. If you bother reading me, then I think you'll like these folks too.

A common theme among speakers: "I write JavaScript, and I'm proud of it." They seem to be facing the same second-class-citizen perceptions that many of us have had to face for so long. Some of them came from strong Java or Microsoft backgrounds, and the idea of a scripting language is not something they may themselves have taken seriously five years ago. Many of these people seem to feel like the underdog too.

The biggest shock for me may have been the discrepancy between the post-keynote speaker panel and the "web standards" crowd. Multiple speakers pointed out that the World Wide Web Consortium was only one of multiple consensus groups. There were calls for greater transparency in its processes. Skepticism was voiced by some when mention was made of a committee to specify ideal XmlHttpRequest behavior. I saw none of the "must validate at all costs" idea that we see on many of the web-design mailing lists. The speakers seemed to take a more pragmatic approach to browser-based work.

There was also a split with the "accessibility" advocates. Fundamentalists on both sides will likely find themselves in opposition someday. It was a shock to hear such strong positions expressed. (At core, though, we've all got that problem of "How do you present a sensible audio translation of a dynamic-data application?", which no one has really figured out yet.)

My best single understanding may be that these advanced JavaScript developers are dealing with the exact same problems Flash-oriented developers had to deal with earlier. Accessibility, search engines, bookmarks, security, audience reach, all of these topics came up from audience questions to the speaker panel. These people are trying to solve the same audience problems that we've been trying to solve. These are hard problems. I really do suspect that we can do more together than apart.

The Flex-Ajax Bridge is very important to this group. Few of them have heard of it yet, but those that have recognize its significance. Some made mention of using headless Flash apps to request cross-domain data or store data locally; others spoke of using the visual capabilities of the Player. These people want abilities; Flash Platform can give it to them, within their current choice of workflow. If their audience can support XmlHttpRequest, then they likely support NPRuntime too... seeing this new set of customer needs gave me new appreciation for FABridge. (Although, we really should get some solid understanding of which browser versions work how reliably with browser/plugin intercommunication... the whole browser-oriented scene has fallen down on seeing what audiences can actually do.)

Microsoft was discussed negatively as not adding enough to IE7, but the greater problem was seen as Microsoft's audience, who may not upgrade to Vista or IE7... multiple speakers made mention of the problems they'll have dealing with IE6 for the long forseeable future. Some went so far as to say that there will be a slowdown in browser innovation for a few years... XmlHttpRequest got popular once enough Firefox supported it, but for natural audiences, IE6 will need to be supported for a number of years yet. Big constraint.

Beneath the Microsoft comments was a sort of semi-accepted understanding that clientside web technologies have multiple adoption flows... one approach is to define how things should work, then wait for implementations, then wait for audience adoption of those implementations ("web standards"). The Flash Platform approach has been to get those abilities out into the world, and to gradually move the creation structures to standards as they arrive (ECMAScript, styling, declarative authoring, etc). But I don't think *everyone* yet sees that there are different approaches to getting stuff to run on Other Peoples' Computers... some still seem to think that multiple engines will evolve as quickly and reliably as single engines will.

Funny note: An audience member asked the speaker panel which development tools they used. Small silence... "vi" raised laughs... "vim" said the next... "emacs" raised the most cheers. I heard no mention of Eclipse, Visual Studio, other IDEs. This reliance on a text-based programming approach gave me good background on how these people approached their work.

An "ideal future browser" would include some level of support for the SVG spec and the CANVAS tag. Firefox, Opera and Safari are working on these now, but from what I've seen, it will take quite awhile until really useful implementations converge across the audience base. I think SWF can help, by eating and rendering SVG/CANVAS instructions in browsers which don't meet the developers' base requirements, but the problem is that no one really has incentive to do the one-time work... I respect and appreciate what Claus Wahlers has done, but wish that more would take advantage of it. For whatever reason these folks like to create in text for various given formats, so if we can find a way to give them the rendering they want in the browsers they want, then that's got to be a good longterm thing to do.

Poignant note: I spoke with one developer on a small team for a large company, which made an intranet app with a solid backend but a bad user experience. He was attending in hopes of improving his interface, to avoid the risk of having his whole project junked and remade by others anew. His company could spring for the conference, but could not expense a usability study on their current web application. I think a good classic web app still has value -- having to refresh the entire page is not as bad a handicap as having users go "WTF!?!?" each time they try to use their app. I wish they could have fixed their current interface while staying within classic web app techniques... I don't think partial text refreshes would solve the underlying problems the same way some good user observation and app modification would. Studying the audience response to the application's interface is key. Features won't help.

Some speakers mentioned Microsoft's WPF/E announcements, but I found it hard to discuss until they actually ship something. I saw the MS demos of partially-transparent triangles moving around over a bitmap, and was distinctly unexcited... make some capability, then get it out in the world, then we might be able to talk realistically of comparing things here.

The first audience question was about accessibility. There was no real answer.

The second audience question was about how many audience members support XmlHttpRequest, and how they handle those who don't. There was no real answer... closest was "graceful degradation", which means creating two audience experiences.

The third audience question was how well browsers could handle memory management, and whether meaningful applications were possible. There was no real answer. There was a discussion of (browser-specific) diagnostic tools, but without any browser-universal diagnostic tools. I thought here of how Dreamweaver 1.0 handled browser-specific JavaScript behaviors by filtering, but we still didn't render as each browser, didn't allow debugging and profiling for each browser.

One speaker noted that the browsing audience may soon split, between those in Firefox or Safari or Opera, and those in either IE7 or IE6. There were implications that "looks best in X" badges may return, this time for browser applications rather than documents.

Loose paraphrase here: "Don't write XmlHttpRequest calls yourself. The books about Ajax are to give you the background. Choose one of the frameworks instead. You don't want to have test things in each browser. Nobody should be writing XHR calls themselves these days; you should choose a framework instead." There was then greater discussion about which frameworks will win, how to combine frameworks, how to handle JavaScript namespace collisions, and so on.

One feeling I got from some of the comments was that many people seemed attracted by bright shiny details... digressions were easy. This may be a failing across all tech communities, however.

One of the later audience questions was about security. There was, again, no real answer... many of these questions seemed to stump the panel. I don't think there's much of an issue here, however... "Ajax" isn't an engine, it's just a workflow atop the varied browser engines. If there's a security problem it's really the browser-maker's responsibility rather than a framework-developer's responsibility... any security problem has to be fixed quickly or else bad people will abuse it, framework or no.

One potential problem among all Ajax frameworks is that they may run into the same "greedy developer" problem Flash has... just as some people want their SWF to run at very high framerates, some JavaScript developers may want to refresh all their data very frequently. (See Tinic Uro for how greedy framerates manifest themselves in the Flash world.) Some types of enforcement of best practices may be needed in architectures which are in it for the long haul.

The Nokia folks posed an interesting problem at the end. Their new phones include a little WWW browser. But they find problems in user-agent identification... if they include the word "nokia" in their UA string then some sites shunt them off to WML versions... if they say they're a Microsoft browser then they get a whole bunch of web content they may not be able to render. The mobile folks are being stung by over-ambitious (and under-capable) browser-detection scripts on the world's websites. The question went out for how many of the audience were thinking of mobile delivery, and a few hands went up, not many.

Je fais do-do... I'm not sure when I'll be able to post tomorrow, but I anticipate reporting on the day's sessions by end of day.