I'm in Brussels this week at EuroOSCON, and yesterday I was fortunate enough to give a tutorial session on "Building Better Ajax Applications". The slides are online, but don't try to view them with anything but Firefox 1.5 or later.
For the last year or so I've been occasionally giving a talk like this and this time I decided to overhaul the whole thing. Every time I've done the talk I admonish folks not to use Ajax just because they can, and if at all possible to work with interaction designers. Last week at the "Future of Web Applications" conference in SF, Jeff Veen boiled the key points of the ID problem down into the most coherent set of objectives I've heard. He outlined them as:
Having worked with a wonderful set of interaction designers (and now friends) at Informatica, I've got nothing but the deepest respect and admiration for the questioning eye that good user-centric design brings to the process of building applications. Jeff's description of the problem instantly made sense, and I've tried to put the example code in section 2 of the tutorial into the framework of those points. The distillation of the problem into easily digestible terminology is one of the things that was new with "Ajax". Hopefully Jeff's list of the 4 goals of ID can help developers similarly start to frame the problem better.
Good writing (in contrast with mine) is defined by great verbs. Verbs are the essential component in answering "how?". You can't tell a story without the verbs. The sad little world of nouns and adjectives only tells, it never shows.
Which is why we need to fucking bury the word "utilize".
Maybe it's just that I've been free of the corporate-speak haze for too many moons, but nothing gets the hair on the back of my neck to stand up in empathized embarrassment like hearing a smart person say "utilize" when all they needed was a simple "use". It's as though the accreted mental sludge of sitting in meetings causes some sort of malapropism-Tourettes. To my delight, it seems the dictionary on my MacBook agrees with me; from the "utilize" entry:
Because it is a more formal word than use and is often used in contexts (as in business writing) where the ordinary verb "use" would be simpler and more direct, "utilize" may strike readers as pretentious jargon and should therefore be used sparingly.
See! "Used sparingly"! Not effing "utilized sparingly".
The Dojo Foundation has been very lucky in having had so many supporters (Google, Mozilla, SitePen) and so many interested students and mentors for the summer internships. While some of them aren't yet wrapped up, today's announcement of the linker hitting trunk makes me want to at least give an overview of what's been accomplished so far.
dojo.gfx -- portable 2D graphics with a DOM
<canvas> based solutions,
dojo.gfx.* gives you what you really want when you're building apps: a good way to draw a shape that you can attach event handlers to. It's also not limited to whatever rectangle you've carved out on-screen for the drawing area. Kun Xi, Eugene Lazutkin, and Gavin Doughtie have been cranking on this all summer and in Dojo 0.4, you'll be able to say "give me a circle here" and you won't be constrained by artificial box constraints or incompatible event handling. I can't wait to see what gets built with this by people who can design beautiful things. The sky is, finally, the limit.
Plugins for Editor2
Heng Liu and Paul Sowden have been reworking the already fast Editor2 component to support plugins. In the process, Heng has added image insertion dialogs, find/replace support, and contextual menus. When Editor2 was originally designed, flexibility was lost for speed. Now it's got both, and extensibility to boot.
Other projects are still underway and I don't want to jinx them by talking about them before they've landed, but I think that on the basis of this work alone, we can easily classify this summer a success. Huge thanks, of course, to Brian Skinner for his patient and thoughtful work in shepherding of the entire program.
As usual, Glen is ahead of everyone on this, but yesterday I got an overview of the Processing environment from the guys who wrote it, and it's so freaking HAWT. It runs on the JVM, but it fixes most of the annoying issues of "where's that jar file?" and "why do I need a class for the main loop?" by constraining the environment to a specific problem domain. And the results are both literally and figuratively beautiful. It feels to me like the kind of think that the Chumby guys should have been using instead of Flash.
In the course of life, there are some moments where you are just so damned thankful to be alive that you almost feel guilty for being in your own shoes. Foo Camp was one of those times.
I'm still exhausted from the whole thing, and my brain is full. Entirely full. It's going to take some time to digest all the great stuff I learned, but a couple of things stood out such that I'm terrified of forgetting any of them. First, Avi Bryant's discussion about "pipes for the web" was a discussion of how we build the small, chainable pieces for the current and next generation of things that we're all hacking on. The discussion of feeds as a generic transport type between processing systems (i.e., the Unix pipe) was amazing. With that back-to-back with Tom Coates' talk on "Dirty Semantics", I got the feeling that we're finally organizing an answer to all the things that have bugged me about the semantic web vision of the future. By acknowledging that the web is dirty, and that it's OK, Tom presented a vision of the kinds of apps that I work on that doesn't have an undercurrent of academic condescension about how you should be doing things. It buckets things into "better because the market will say so" and "worse, because the market will ignore it", and those are the kinds of quality metrics I can get behind.
I also got to meet Ed Loper, the guy who did Epydoc, and we got into a discussion about how computational linguistics and machine translation people can fix the problem of having artificial test sets that cause algorithm mutation towards solutions that might not actually be desirable in the real world. What if, instead of some test suite that has a non-human testing the various algorithms, the system were a front-end to bablefish that would allow researchers to submit a web-services call into a queue of potential translators? The system would shunt off some percentage of the overall traffic to each registered system and collect "good" or "bad" rankings (the UI is tricky here) for various translations. By using the scope of the system to test quality and then to perhaps create a leader-board so research teams can compete, it would allow translation research teams to both provide results to sponsors that are trustable enough to fund ongoing work and, eventually, to provide data to support adoption of the resulting systems either through Open Source or commercialization.
Thanks to Foo, I've got a hundred other things rattling around my head right now, and the worst bit of it is that there were so many people that I wanted to meet and things I wanted to see but couldn't. I've never experienced that depth and breadth of experience in one place before. Yesterday morning, I woke up at 9:30 after having gone to sleep at about 4:30 and I was kicking myself for having not been up at 7 because I could have been talking to people instead of sleeping.
It was that awesome.