Archives

History repeats itself, first as tragedy, second as farce. — Karl Marx

I can remember the day, back in 1994, when I abandoned the Mac for Windows. It was a gloomy, overcast day when I made that bittersweet decision — I was a Mac and Unix nerd all through college — but after my twelfth or thirteenth crash of the day, I had had enough. Photoshop, Netscape, Secure Shell and Word were just not meant to run more than one at a time on Mac OS 7. Had I stayed with Apple through that rough patch I’m sure I would have been slimmer, sexier and happier, but NT 3.51 only crashed twice a day, so my hand was forced. I  ran out and bought a PC that very day.

Now I fear history may be repeating itself. Yesterday, I had Firefox 2 for linux crash 5 times, and IE7 for XP crash 7 times. The cause? Too many fat Ajax applications. Zimbra, the whole Google bestiary of applications, Yahoo Mail, etc.. These are all long running applications that I keep open for most of the day. Then all of a sudden the Browser is gone and I have to relaunch and login all over again.

I’m not alone in this. Colleagues and friends report similar problems with Safari/Mac, IE7/Vista, Firefox/Mac. I’ve even checked with a friend that runs the helpdesk for a large firm: reported problems with browsers are up. The only one who seems blissfully unaffected is the lone Opera nerd in my office. He just keeps chugging along with what seem like 200 open tabs.

The cause should be evident to everyone. We’ve taken what was first called LiveScript — a crufty embedding just good enough to validate a form or two — and we’ve abused it into being the foundation for a whole new kind of application platform. The browsers have just not kept up and the situation will only get worse with the accelerated proliferation of Web 2.0 apps.

Help is on the way, in the form of bytecode interpreters and vm’s for Safari and Mozilla, though the future of IE is still cloudy (still, there is a plan to bring Tamarin to IE). But if the new Browser version don’t arrive quickly enough, or if they don’t fully solve the problem of browsers crashing once an hour, then a mass migration to Opera may be the best we can hope for. At worst, content and application producers will opt for more stable non-Ajax alternatives such as Flash or Silverlight.

Ajax and the browsers it depends on are running out of time. If the notion spreads that it isn’t reliable, it will be as dead as the Java Applet, never to be heard from again.

Occasionally, in-between the latest iPod rumors and stupid top-10 lists from Cracked, Digg coughs up the good stuff. Case in point: today’s post about Firefox 3 Beta 1. So far it’s only available for Mac and Linux, and the download directory includes the following "IMPORTANT NOTE":

These files are not release versions, they are just potential release
versions. Use them at your own risk, without any of the warnings that we
will be putting in the release notes.

To be honest, if you’re here from Digg or something similar, we’d really
rather you waited until 3.0b1 was officially announced, so the servers
don’t get overloaded and we don’t have a bunch of extra work to do.

Because I’m a bad citizen – and because I didn’t see the note till afterward – I downloaded the beta and installed it on my Macbook Pro. All my extensions, of course, got disabled immediately. Still, I’m already impressed with the interface improvements. The Places concept looks promising. The bookmarks manager is VASTLY more useful and intuitive. And the download manager, though a little iffy on usability, has some cool new bells and whistles, especially the ability to interact with your downloaded files from within the manager itself.

Also, strangely, dropdowns and other form elements now have the native Mac OS look-and-feel: rounded corners and all that jazz. Is this is new feature, or just something that was always there but hidden by my extensions?

Technorati Tags

• Firefox

Over the weekend my Gmail finally got upgraded to the new version. (I know, I know, a week is hardly a long time to wait for a slow-rollout Google feature. But I’m impatient.) I have to say, the history and back-button support is AWESOME. It’s funny that Gmail warns you in a huge red banner to disable Firebug. I, of course, kept it enabled and immediately began digging through the DOM of the new UI. As usual, most of the JavaScript is so obfusticated that it’s hard to tell what’s going on. Still, it’s interesting to dig through layers and layers of iframes and nested divs and see how much DOM hackery is involved. Looking behind the scenes at any commercial-grade webapp is like taking a tour of a sausage factory.

Luckily, I have a strong stomach. I’m going to make it a weekend project to really dig in and learn how they’re handling their history support. In a previous post, I wondered why the new Gmail is only available for Firefox 2 and Internet Explorer 7. Given my own experiences with Safari’s history object, I shouldn’t be surprised. With bookmarkable URLs and history management so central to the new Gmail UI, no wonder Safari has been left in the cold; it’s simply too buggy in this regard to receive A-grade support. Safari users have been complaining to Google that it should fix Gmail for Safari even with the old UI. I think those complaints should be lodged at Apple, not Google.

P.S. Sure enough, leave Firebug open in Gmail for any length of time and your Firefox will slow to a crawl. My FF has been crashing a bunch this week, but I’m not sure whether it’s Gmail or Firefox’s own latest updates. Commenters, am I the only one seeing this?

• Gmail
• Google
• Safari
• Firebug

Songbird, the open-source, Mozilla-based media player, received its 0.3 "developer pre-release" on Oct. 30. The UI hasn’t changed much since the 0.2.5 "developer preview," but things continue to evolve under the hood. Better yet, the documentation and demos keep getting better. Check out the developer center for information about using XUL to build add-ons or using the JavaScript API to integrate your webapp with Songbird’s media player.

If you’ve yet to experience Songbird, a little background is in order. The project is run by Pioneers of the Inevitable, a Bay Area company founded by veterans of Winamp and the Yahoo! Music Engine. Building on Mozilla’s XULRunner platform and the VLC media player, Songbird aims to unite a web browser, a media jukebox and an online media player into a skinnable, extensible, open-source application. At this stage, the app is a long way from challenging the likes of Windows Media Player, let alone iTunes. But as it grows, it promises to cultivate the same kind of fervent user and developer communities as Firefox, Thunderbird and other Mozilla projects.

I first became aware of Songbird via a Boing Boing post. I’m surprised it hasn’t generated more noise in the various Ajax feeds and news sources. With all the excitement about specialized browsers and desktop webapps, from Mozilla Prism to Google Gears and Adobe AIR, it seems like Songbird would be earning a lot of buzz. Maybe I’m just not hanging out at the right water coolers.

As an Ajax developer and huge music nerd, I’m looking forward to playing with the JavaScript API. It promises seamless integration between webapps running in the Songbird browser and the media player itself. Imagine iTunes, but instead of a built-in browser that only supports the iTunes store, you’ve got a Firefox clone that plays well with music vendors, P2P networks, MP3 blogs and any other internet music resource. Visit a music mag, for instance, and see all of its featured downloads automatically show up as a playlist in the media player (as in the Hype Machine example above). Visit an online music store and experience an iTunes-esque purchase experience. Indie-music brands such as eMusic and the aforementioned Hype Machine have already gotten on board. To see Songbird’s API in action, compare these sites in Firefox and Songbird.

Songbird’s add-on ecosystem is cool, too, especially for long-time Firefox developers. They can adapt existing add-ons with just a few tweaks. (GreaseMonkey, for instance, has already been ported.) But Songbird’s API allows for more radical innovation than Firefox’s add-ons. Instead of simply adding context menus and pop-up dialogues, you can rewire the entire UI of the media player. One example on the developer site shows how to replace the single play/pause button with individual play, pause and stop buttons. That’s a trivial example, but a telling one.

I’m already salivating about the cool stuff I’ll be able to do with add-ons:

Tag-parsing madness

Imagine Doug’s AppleScripts for iTunes ported to XUL. Like a lot of people, I’m obsessive about my meta tags, and I can’t wait to use JavaScript regexes to bend them to my will en masse. I’m also hoping that Songbird will record all of its meta data in the music files themselves instead of socking some of it away in the music library. With iTunes, if you decide to rebuild your library in another player – or even in a different iTunes installation – you lose things like star ratings and play counts. It’s a real bummer.

Huge libraries

The flat XML database in iTunes scales horribly. Get above about 100 gigs of music and performance slows to a crawl. This problem has only gotten worse with the bloat of Cover Flow, Quicktime integration and all the other features I don’t need. I have 450 gigs, most of it ripped from my huge CD collection, and I’ve had to separate it into four separate libraries (using Libra) just to get decent performance. That sort of defeats the whole "any song at any time" promise of the MP3 era. Enter SQL Lite, which is how Songbird stores its own media library. I’ve got high hopes that a relational-database back end coupled with open-source how-to will make Songbird the media player of choice for folks with enormous libraries.

Interface freedom

iTunes and its Smart Playlists are all about endless, automated mixes. But I’m an old-school mix-tape guy. At the end of each year, all of my friends usually get a four-CD retrospective of the year’s best tracks as compiled by me. But with iTunes, it’s excruciating to build a "source" list of possible tracks for these multi-disc epics, then slot the tracks into individual discs and experiment with sequence. You can only view one playlist at a time, so every time you decide to move a track from one playlist to another, it’s a multi-step operation. Imagine an interface where I could see my "source" list and all of my target lists at once, and where drag-and-drop defaulted to a "move" operation rather than a "copy" operation. With XUL and JavaScript, I’ll be able to build any specialized interface I want and swap it in for Songbird’s default UI.

Sure, most of my needs are pretty specialized, but I hardly think they’re unique. And that’s the point of an extensible, open-source player. You’re free to build the features YOU want to see and share them with others like you. That’s a lot more productive than griping over at the iLounge forums about iTunes’s shortcomings.

I know Songbird isn’t the only open-source, component-based music player out there, but it is the only one that’s drawing on the power of the Mozilla Foundation. Firefox has shown how disruptive the Mozilla community can be in the browser market, which, like the music-player market, is dominated by a single product. Songbird may not topple iTunes any sooner than Firefox topples IE, but it should provide a powerful alternative and perhaps put some competitive pressure on the folks in Cupertino. It was extremely shrewd of Pioneers of the Inevitable to hitch their wagon to Mozilla’s. I’m definitely going along for the ride.

Songbird links

• Songbird site
• Songbird Blog: post on the 0.3 release
• Songbird Wiki
• Wikipedia entry
• Technorati tag

Songbird posts

• Boing Boing interview with Songbird architect Rob Lord
• Ars Technica
• C|Net
• Internetnews.com
• Alpha’s Place
• Blog of the Vicious Beast
• Views of a Discerning Critic
• Current_
• Hardware Beyond the Hype

Technorati Tags

• Songbird
• iTunes
• Mozilla
• Firefox
• XUL
• JavaScript

Late tonight over at Google Code, I’ll be posting a beta of Really Simple History 0.6 for testing. The goal is to elicit help from RSH users in chasing down any bugs I’ve failed to catch, then push out a stable release around Halloween.

I’ve tried to be as ambitious as possible with this release: full support of IE7/Win, Safari/Win, Safari/Mac, Opera/Win, Opera/Mac. I’ve didn’t quite get there, but I got close.

Features in the new version include:

• Full support for IE7/Windows (though my only Windows machines use IE7 Standalone, so I need help testing on "real" IE7 installs).
• Full support for Safari 2/Mac (though I’m still trying to eliminate the "infinite loading" bug before I push out the beta).
• Partial support for Safari 3/Windows (hampered by bugs in the current beta version of the browser).
• Full support for cross-platform Opera 9.22 (though you may need to hard-code an image into your markup).
• A totally revamped test page that allows you to play with the library in your browser of choice and see how it works behind the scenes.

As always, RSH works beautifully in Firefox 2 for Windows and the Mac. I hope to give it a good shakedown on Linux browsers in the next release.

So what is Really Simple History, and why am I updating it?

An Ajax bookmarking and history-management framework originally developed by Brad Neuberg, RSH became my responsibility a little over a month ago. I tinkered with it for a few weeks, then finally camped out with it for most of the past week to get a release out.

This is the first time I’ve ever contributed in this manner to an open-source project. It’s been a lot of fun, but it’s also been maddening, as anybody who’s ever dug into the bowels of cross-browser history management can tell you. Here’s a sampling of what I’ve learned from RSH:

Safari is crazy

Plenty of people who’ve worked on Ajax bookmarking projects have commented about this, but it only becomes clear once you’ve actually seen it in action. Getting this thing to work in Safari 2 for the Mac took a wildly disproportionate amount of time considering its market share. I wouldn’t have been able to do it without Bertrand Le Roy over at Microsoft, whose blog entry on the development of the .Net history manager pointed the way for both Safari and Opera.

As Le Roy and others have noted, the Safari 3 Windows beta is so buggy that history management is hopeless. You can enable the back button for Ajax apps, but once you use it, the forward button becomes disabled. I noticed yet another wrinkle in this behavior (skip ahead if you’re easily bored):

Navigate to a non-RSH site – Google, for instance. Then travel to an RSH site, create some history entries via RSH, and use your back button. The forward button stops working: a known bug. Now keep hitting back until you get back to Google again. Suddenly, your forward button works again. Hit forward and land back in your RSH app. Magically, the forward button continues to work.

If I hadn’t spent so much of the last week lost in Safari-land, this interesting behavior might be worth further investigation. For now, I’m just hoping the Safari 3 team fixes this before the final Windows release.

Don’t try to retire document.write just yet

A couple of different RSH users suggested getting rid of Brad’s original calls to document.write in favor of standard DOM methods for adding elements to your page. That approach worked for some elements, but not for others.

In IE, RSH writes a hidden iframe into the document and uses the location and history of that iframe to help it track application state. Writing the iframe with document.createElement works just great.

But for all browsers, RSH uses a hidden textarea to store the entire history stack behind the scenes. This powers one of RSH’s coolest features: its ability to retain history even if you navigate away to another site and then come back to your RSH application. This works because modern browsers retain form-field values throughout an entire browser session. But they do so only for form fields that exist in the DOM natively – that is, exist in the actual HTML markup or get inserted via document.write get inserted into the DOM before it’s finished loading. 

If you create a form element after your DOM is already loaded, the browser has no way to persist values in that element after you leave the page. Each time the page loads, even from the cache, you essentially create a virgin new form field. I’m therefore using document.write for the hidden textarea – and for the hidden form field I’ve added to RSH for Safari support.

UPDATE: As it turns out, it’s immaterial whether you use DOM methods or document.write. The important thing is to use either method before onload fires. I ended up using document.write in the 0.6 beta because of SSH concerns and the fact that it’s so much more concise. For more on this topic, see this subsequent post. 

Because of the way RSH is structured, these elements actually get written to the head rather than the body of your document. Still, it works, and it should only offend the most anal-retentive of standards geeks. After all, if you’re hacking the browser 10 different ways from Sunday just to enable Ajax bookmarking, then inserting a bit of non-validating markup via JavaScript is hardly the worst of your sins.

RSH won’t be hitching its wagon to [insert name of your favorite framework here]

A few users suggested rewriting RSH in Prototype so it would be more compact. I appreciate the impulse, but I think that defeats one of RSH’s chief virtues: the fact that it’s written in Plain Old JavaScript and doesn’t lock you into any specific Ajax framework. It plays well with any library you want it to: Prototype, jQuery, YUI, whatever. (If it doesn’t, please file a bug so I can find out why.)

A little JSON never hurt anyone

The one library that RSH does require is a JSON parser; it ships with the latest open-source version. RSH 0.4 included an earlier version of the parser in the same file as its native code; I’ve broken it into a separate file under the logic that many users will already be serving a similar library. RSH’s methods don’t actually call toJSONString or parseJSON directly; instead, I’ve provided bridges so that you can hack in your own JSON methods without having to modify the guts of RSH itself.

Future roadmap

I’ve got quite a punch list for the next release:

• Provide minified versions of RSH and JSON for download
• Make use of Crockford’s module pattern for better encapsulation
• Add official support for Linux browsers, Safari 3/Mac and Safari 3/Win

That’s the future. For now, I have to get 0.6 packaged up and ready for testing. Check Google Code late this evening or first thing tomorrow.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

All bookmark sync utilities are not created equal. Plenty of browser add-ons promise to keep your favorites in sync across computers, while Del.icio.us and its ilk host your links up in the cloud. For my money, though, if you’re a Firefox user with a serious bookmark habit, nothing beats the free browser extension Foxmarks.

I’m the first to admit that I’ve got a problem with my bookmarks – all 3,000 of them (and counting). I do tons of research for this site and my other writing gigs. When I come across something useful, I hit Command-D automatically. (I’m just as bad with clippings in my RSS reader.) Every once in a while, I do a clean sweep: reading, filing, purging. But until I’ve extracted whatever piece of knowledge I need from a particular link, I want access to it from all of my workstations and Internet devices.

That’s where Foxmarks comes in. When you set up an account and install this free Firefox extension on multiple computers, it keeps the bookmarks in sync across machines and backs them up to the Foxmarks server. When you bookmark something at home, then want to refer back to it the next day at the office, you’re golden. And when you’re away from your own workstations – say, in an internet cafe or on a mobile device – you can hit My Foxmarks, the webapp version of the service.

The Foxmarks browser add-on gives you some fairly coarse-grained control over how and when syncing occurs. If you set your preferences to sync manually, or only on shutdown, you may get stuck answering a series of dialogs as the server parses your changes. My recommendation: Enable automatic synchronization in the background. In earlier versions of the service, the sync dialogue would hijack your browser and hog your CPU, especially if you were digging around the browser’s "Organize Bookmarks" screen. Such performance problems have now been reduced, if not eliminated.

As for My Foxmarks, it, too, has improved over time. The current interface uses the YUI and Ext libraries for a seamless, desktop-like Ajax experience. The UI offers both a folder-tree view and a paged grid view; you can access individual bookmarks’ details from either view. There’s even an iframed preview pane that can show you the target of a bookmark without leaving the Foxmarks site. And, of course, there’s a scaled-down mobile version. All in all, it’s a slick, well-designed experience.

Of course, there’s always room for improvement. I find the built-in Firefox bookmark manager cumbersome, buggy and annoying. I’d love to see the Foxmarks team position My Foxmarks as a powerful, intuitive web-based replacement. To get there, they’d probably need to add inline editing, a more customizable interface, and perhaps integrated tagging. A trash bin for deleted bookmarks would also be pretty cool, as would the ability to batch-delete bookmarks without constant confirmation dialogs. Most browsers’ internal bookmark managers – and most social bookmarking services – don’t offer a very efficient or useful UI. It would be great to see somebody get it right.

I have no idea whether such features are in the cards, but Foxmarks’s developers aren’t resting on their laurels. Just yesterday, they announced a beta of Foxmarks 2.0, which promises to offer:

• Major changes on the server side, including much more efficient syncing.
• A nice tweak to the syncing process so that it preserves favicons across computers.

Pretty sweet!

Technorati Tags

• Firefox
• bookmarks
• Foxmarks
• YUI
• Ext

I’m excited to announce that I’ve heard the call and volunteered to tackle maintenance and stewardship of Really Simple History, Brad Neuberg’s intuitive, lightweight Ajax history library. Brad developed RSH a couple of years ago, drawing inspiration from the Dojo Toolkit folks to deliver a standalone library that provides back-button and bookmarking support for Ajax apps in IE6 and various Gecko-based browsers. Since, then, many additional Ajax frameworks have implemented back-button and bookmark support, some of them drawing on Brad’s work.

Meanwhile, Brad’s been too busy with other projects to upgrade RSH for a variety of new and existing browsers: IE7, Opera, Safari/Mac and Safari/Windows. I asked Brad to let me take care of his baby for several reasons. For one thing, I’ve been an enthusiastic user of the library. For another, I’ve been wanting to get involved on a more formal basis with open-source JavaScript projects. But most of all, I believe RSH remains a great tool for folks who want a solution to the Ajax history issue without the overhead of a larger Ajax framework.

I’m currently working with Brad to migrate RSH to Google Code, get acquainted with the bug base, and start tackling the thorny issues surrounding Ajax history support in the 2007 browser landscape. I look forward to shamelessly pilfering the many fine solutions uncovered by a large community of developers since Brad’s initial work. (Brad was kind enough to point me to this blog post from Bertrand Le Roy, which lays out many of the aforementioned fine solutions and thorny issues.)

In the meantime, I’d love to hear from RSH users about their hopes for the future of the framework. Comments, please, or ping me directly at bdillard (at) pathf.com. Thanks!

Think of all those annoying step-by-step processes you must learn and memorize to go about your daily online business: logging onto your bank site to check the balance on your savings account; filling out a tedious form; ordering prints of your digital photos. The elements of the UI are easy to understand, but the process itself differs wildly from site to site.

Now imagine a Greasemonkey-esque add-on that not only automates those processes, but shares the automations with everyone else. All you have to do is write the instructions in plain English, let your browser record the steps in real time, or search the existing archive for somebody else’s previously recorded automation. Sold yet? Good, then meet CoScripter, a new Firefox add-on from IBM.

Alex Faaborg over at Mozilla Labs sums up CoScripter thusly:

What do you get when you mix one part automation, one part natural language interpretation, two parts programming by demonstration, and three parts online collaboration? If you stir all of these research areas together and toss in some XUL, you get one of the most innovative extensions for Firefox: CoScripter.

Jon Udell has kicked off a pretty interesting discussion of CoScripter as a mash-up of social networking and domain-specific languages. But I’m most excited about the technology for its grassroots potential. Like microformats, CoScripter has the potential to evolve into an "accidental standard" that proves the enduring power of the Open Web. I can foresee a future in which site owners coach newbies about their interfaces by releasing CoScripts instead of publishing big chunks of step-by-step instructional text. Of course, the technology’s future ecosystem depends on how IBM licenses it. One less-than-promising sign: the onerous registration process and EULA I had to endure before downloading the add-on.

Nevertheless, as of this writing, 190 CoScripts have been submitted. Lots of them seem fairly limited in scope, but I’m sure that will change as the community grows and the technology matures. The add-on’s handy Sidebar interface displays the "editor’s picks" for most useful scripts. I’m particularly fond of Add your phone number to the national do not call list.

I wrote two of those 190 scripts myself, and my experiences highlight the strengths and weaknesses of CoScripter as it’s currently implemented.

First off, I tried to automate the process of logging into popular blogging engine Vox and starting a post. The tutorials
helped me figure out how to parameterize private data such as email
addresses and passwords into a locally stored "personal database." That way, I can write scripts that work for me, then share them with anybody who sets up similar key/value pairs in their datastore.

The plugin did a pretty good job of recording my steps as I interacted with the browser. (Users of the open-source Selenium QA framework will feel right at home.) But the recording engine totally ignored my interactions with Vox’s password field. Even after I manually scripted this step – in CoScripter’s eminently simple natural-language syntax – I couldn’t get the sequence to work. Still, I’ve saved it (Login to Vox and Compose Post) in the shared repository. Perhaps a smarter Vox user than me could get it running? Here’s the source code:

      
       

• go to "http://www.vox.com/"
• enter your "vox login" into the "Member sign in"’s "Email:" textbox
• enter your "vox password" into the "Member sign in"’s "Password:" field
• click the "Sign In" link
• click the "Compose Post" link

      
   

Next, I tackled something much simpler: Read La Dolce Musto. I love this Village Voice column, but I always have to hunt for it on the busy homepage of NYC’s alternative weekly. There’s no landing page for columnist Michael Musto, and the site’s layout changes weekly. My simple, two-step script hits the homepage and activates the first instance of the writer’s name as a link. It worked for this week’s issue, but I’ll have to wait till next Wednesday to make sure it doesn’t bomb out once the homepage rolls over.

Again, the source code:

      
       

• go to "http://www.villagevoice.com/"
• click the "Michael Musto" link

      
   

Given how difficult I found it to get a moderately complex script working, and how trivial my actual working example is, I can’t say that CoScripter is going to set the world on fire immediately. Password fields seem to be a problem, and there’s no ability to use conditional structures. I’d love, for instance, to be able to write a script that goes to Vox, logs me in only if I’m not already authenticated, then begins a post. It would also be great if I could build in timers, such as "wait x seconds," so that Ajax interactions or other slow-moving changes in state could be accommodated. I mentioned Selenium before, and its powerful syntax for writing test scripts seems like a model for future development. If CoScripter’s engineers can expand the power of their DSL without losing its simplicity and ease of use, this add-on seems likely to earn a wide and enthusiastic user base.

[Thanks to the awesome Lamda the Ultimate for the original tip.]

Paul Graham’s much-dissected essay Microsoft is Dead offers some witty and perceptive analysis, but it sidesteps the fact that Microsoft’s rotten corpse will take decades to decompose. In the meantime, we still live in a world where most people trawl the Internet with a Microsoft browser. I’ve already linked to Kevin Hale’s perceptive essay On the Tenacity of Internet Explorer 6, and I’ve already covered Eric Meyer’s useful techniques for taking advantage of IE7′s power while continuing to support IE6. But I’ve got a few more links to add to Dietrich’s and my back-and-forth about the state of JavaScript tooling. I regularly stop by the IEBlog the same way I keep tabs on the neighbors I don’t really like but have to live near. They recently added a more in-depth post about Ajax View, a pretty cool profiler that they’d previously covered along with other IE development tools earlier this summer. In a previous post, I surmised that most front-end developers code for Firefox first, then put off their Safari/Explorer testing till the end. Maybe if IE tooling continues to mature, we’ll see less of that.

Tuesday saw the conclusion of An Event Apart Chicago 2007, the two-day web-development conference from the folks at A List Apart. Here’s my sequel to yesterday’s day-one overview. I’ll be back Friday with analysis and afterthoughts.

Jeremy Keith, author of "Bulletproof Ajax" and "DOM Scripting," led the day. His topic? "Be Pure. Be Vigilant. Behave," wherein he outlined the concepts behind "Hijax," the application of progressive enhancement to Ajax functionality. A staunch proponent of unobtrusive JavaScript, Keith warned against throwing web standards out the door when developing Ajax functionality. His examples demonstrated how to separate behavior from content and presentation by abandoning such outmoded techniques as the javascript: URL pseudo-protocol. His most extensive example showed how to code a graphical widget for the assignment of star ratings so that it would degrade gracefully into a standard HTML select box in less capable browsers. After discussing the difficulty of making XHR functionality play nicely with bookmarks and the back button, Keith acknowledged that his parting message – when in doubt, leave XHR out – was a bit of a copout for the author of an Ajax manual.

Next up was Luke Wroblewski, a Yahoo product designer whose resume includes work on the original Mosaic web browser. Wroblewski covered "Best Practices for Form Design" using exhaustive research from his forthcoming book on the subject. In case study after case study, he demonstrated how simple choices in the design and deployment of HTML forms – from the widths and alignment of inputs and labels to the placement and visual differentiation of cancel and submit buttons – can cut the time it takes to complete them in half. Wroblewski’s most persuasive argument, however, was conceptual rather than technical. He made a powerful case that because forms are barriers between users and the things they want to do – buy your product, join your site or begin creating content – you should make them as easy to get through as possible. This central thesis added considerable weight to his many practical how-tos.

Accessibility advocate Derek Featherstone closed off the morning with "Accessibility: Lost in Translation." Featherstone looked at how markup choices can make a site transparent to assistive devices – or render it totally opaque. Using real-world examples from Amazon and other sites, he demonstrated how screen-reading software actually parses markup. His live examples proved that the lack of semantic markup and the absence of ostensibly optional HTML attributes can render a site worthless for disabled users. Featherstone then went beyond the basics, explaining how source order – the sequence in which nodes appear in your markup – can be used to enhance accessibility. By placing your central content first, then positioning chrome above it with CSS and providing jump navigation to skip past inessential modules, you can achieve the presentation you want for typical users without shortchanging disabled ones. In another example, Featherstone examined the ways in which meaning can be encoded in the color and position of elements on the page – and how to replicate that meta-data in a way that disabled users can understand. As with many of the other speakers, Featherstone’s examples argued persuasively for the continuing relevance of web standards.

After lunch, CSS expert Eric Meyer again took the stage, this time to explore "The State of CSS in an IE7 World." Using the recent release of Microsoft Internet Explorer 7 as a springboard, Meyer illustrated the concepts that have governed the changing of the browser guard for more than a decade. His overall premise was that developers need to use their own server logs to gauge when support for an older browser can safely be dropped for their site. For most of us, IE6 isn’t going away anytime soon, so we need to get creative if we want to harness advanced functionality. To that end, Meyer delved deeply into the details of IE7 techniques, filters and hacks. He praised the browser for the strides it makes over IE6′s CSS engine in such areas as child selectors, adjacent sibling selectors and attribute selectors. His real-world examples demonstrated how such functionality adds power and elegance to our code. To cope with IE6′s continuing market share, Meyer advocated the use of Dean Edwards’s IE7 compatibility script, a JavaScript library that adds IE7 capabilities to older versions of the browser. The take-home message was that older browsers may take a long time to die out, but creative programming techniques can harness the future of CSS now.

The final two sessions for AEA Chicago 2007 were a little offbeat, which was a relief after 10 technical sessions in the previous 32 hours. In the highly anecdotal "Selling Design," ALA publisher Jeffrey Zeldman used stories from his own long career to illustrate best practices for handling difficult clients. His thesis was that collaborative work requires us to deal with a wide range of other people, so we should hone our ability to influence our collaborators – and pick good clients to begin with. Agency owner Jim Coudal closed things off wittily with "Dealing With the Both of You," a slide-free presentation about the crossover between personal projects and professional work-for-hire. Coudal assembled a number of satirical short films to drive home his point: Because most web developers are curious and easily bored, we should strive to marry passion with professionalism whether our clients are external or ourselves.