Here are the slides from my talk on Mobile Ajax development. I've got a longer-ish blog post in the works about getting a working emulation environment set up, but it's taking much longer than I'd anticipated to try to track down some of these things (if you know anyone at SonyErickson or Obigo, drop me a line). Hopefully next time I give this talk I'll be able to include a demo of the "foldable interface" thing I keep muttering on and on about.
There's some fun data in the slides that the carriers would really rather not have disseminated, not that their collective folly hasn't been laid bare qualitatively already.
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.