A few days ago, the web development community exploded into an uproar concerning the IE team’s plan to introduce a new method of triggering standards compliance mode in Internet Explorer 8. Web developers, with justifiable but thinly veiled vitriol, ripped into Microsoft and the Web Standards Project for going along with this scheme.

In essence, what the IE team wants is web developers to “opt-in” to new renderer features using a custom meta tag or HTTP header. Pages will then be frozen at that renderer, ensuring they remain consistently rendered from now until the end of time (or at least, until Microsoft stops supporting that rendering model or breaks it accidentally). We went down this path once before, using the Doctype declaration to differentiate between “quirks” mode and “standards” mode. IE7 is, unfortunately, also quirky in standards mode, so apparently we need a new “super-standards” mode for the next version (and so forth).

From the perspective of the IE team, this solution makes sense. They can effectively freeze HTML rendering at today’s IE7 baseline and proceed with enhanced features in later releases. Maybe I’m looking at this the wrong way, but I never considered HTML content to perfect screenshots that should remain immutable. Well designed HTML is flexible — it can be rendered by a desktop browser, or stripped to it’s barest essentials by a mobile parser. (Note that I’m drawing a clear line between web content and web applications — web apps are by their very nature a snapshot of the present). The IE team should be encouraged to fix their mistakes at the expense of breaking badly developed content, just as users should be encouraged to update their rendering engines as frequently as possible. Notice that the IE team is the only browser developer that seems to have this problem.

As a web designer and developer, apparently I’m supposed to help Microsoft maintain their dominance in the web browser market by tagging my pages for their benefit. But what do I get out of the bargain?

Let’s assume for a moment that IE8 has been released with a spectacular new rendering engine, on par with Firefox or Safari or Opera in terms of “write once, render anywhere”. Let’s also assume I have a pretty good idea of what my target audience’s browser technology will be: 50% “IE8 compatible” (meaning IE8/FF/Safari etc), 30% IE7, and 20% IE6. None of these markets are small enough to ignore or deliver reduced functionality to. I would still need to optimize for three different version of Internet Explorer. IE7 doesn’t go away, and neither does IE6. I can’t just freeze the renderer at the IE7 level — I want to use all those fancy new features in IE8 that have been available in alternate browsers for years now.

So where does this leave me, the web developer? Still coding for multiple releases of IE. In fact, the problem gets worse as Microsoft accelerates it’s release schedule — people simply don’t update quickly enough. IE6 is still estimated to have a 35% market share — over a year after IE7’s release. How do we solve the problem of supporting multiple renderers?

Simple. We deprecate IE6. We no longer support it. And we provide a clear, direct upgrade path that involves little to no effort on the part of the user. Maybe this involves just swapping out the rendering engine, leaving the browser’s UI intact (to minimize the impact on the user’s day-to-day experience interacting with their browser). I’m certain part of the resistance to upgrading to IE7 today is the horrendous overhaul to the UI that occurred between versions.

Apple doesn’t seem to have any problems keeping it’s Safari users (or iTunes users) on the latest release through an effective software update system. Firefox also has a fairly effective system, although it could be improved. But web developers don’t complain about supporting multiple, ancient versions of those browsers because the system, and the users, are proactive about updates.

We need to get over the idea of preserving out-of-date content as a snapshot of the day it was released. We need to stop worrying about breaking 5-year-old browsers and just get on with it.

Update: After further reflection, there is another (possibly better) approach Microsoft could take. They could include the IE6 and IE7 rendering engines in each new update, and provide a user-accessible toggle for enabling it on specific sites. Using the info bar, much in the same way they do when blocking popups or enabling ActiveX downloads, a message could be displayed along the lines of “This page may not be compatible with the Internet Explorer 8 display system. Would you like to switch to Internet Explorer 6 compatibility mode for this site?” IE would remember the setting and use it on subsequent visits. The compatibility message could be triggered by detecting known CSS hacks, or even based on the Last-Modified date of the document.

One of the questions I hate to answer is “what do you do for a living?” It’s not that I don’t know what I do, it’s just that there isn’t a commonly used term that I can use to describe it. Most people don’t want to hear an extended diatribe concerning the exact position that’s occupied somewhere between graphic designer and web programmer. So usually I just tell people that I design websites, although there’s an aching part of my brain that assumes my fellow conversee now sees me as some kind of FrontPage doodling monkey.

I think the best term I’ve found is Interaction Designer, although it’s a term that means different things to different people. I like the word Interaction, because it makes my work feel so much more dynamic. I don’t build brochureware, I build web applications, you insensitive clod! It implies action, which is basically true because client-side code is all about making things move around on the screen in a predictable and consistent manner. I’m also appreciative of the word Designer because I work with image and color (and spend at least a third of my time in Photoshop). It makes me feel like a graphic designer (now with more future!), even though I have little formal education in it.

So what’s my point? And what does this have to do with drugs and programming languages? Well, as an Interaction Designer I get to experience plenty of web development platforms from the socket side in. That way, I get to form all kinds of uneducated opinions about the language and the people who write in it… and go to battle for it. And since I’m technically a Computer Scientist (note the capital letters), I know just enough about the topic to get myself into trouble when I post my opinions on the internet.

Over the past several years, I’ve written client side code in Flash and AJAX that talk to servers running a variety of frameworks — Struts, Spring, JSF, PHP, some custom XSLT (shudder) and JSP jobby, and a variety of others. I tend to learn enough about these frameworks to understand their architecture and templating system, but rarely need to go any deeper. But my latest gig has me looking at things from the other side… literally. It seems that Interaction, as defined by this job, also includes slinging PHP code and writing SQL queries. It’s not that I’m incapable (in fact, sometimes it’s nice to exercise those server side brain muscles), but ultimately it’s not what I really enjoy doing. Especially since I’ve apparently inherited the frankenplatform, a heinous mishmash of PHP libraries built on no framework in particular (unless you consider Joomla a web application framework… yeah, me neither). The problem with frankenplatforms is they are really hard to bring back into line with some established pattern or system. Which, I promise, brings me almost to my point.

In my attempt to understand and hopefully improve the frankenplatform, I’ve been doing a lot of research into alternative PHP frameworks, as well as popular alternatives such as Ruby on Rails or Django. And this has brought me into close contact with the various religious groups that preach their benefits.

In Nathan Rabin’s excellent review of New York, New York (part of his always hilarious My Year of Flops series), he writes about 70s “coke movies” and “pot movies”, revealing the unique characteristics of films powered by their respective drugs (and drug addled crew). I think this same concept can be applied to programming languages.

The “coke movie” of development platforms is clearly Perl – all twitchy and ego-fuelled, operating at hyper speed and totally incoherent to the sober kids down the hall. Ruby is most likely the pot platform – mellow and creative, beloved of indie kids and legal for medicinal purposes in California. If The Shins were a web framework, they’d be Ruby on Rails.

PHP is, I think, crystal meth. Sketchy and unpredictable, with bad teeth and a hideous grin, it still manages to accomplish a heck of a lot in a short amount of time. It steals the best ideas from it’s friends, but takes them to the street and abuses them until they’re almost unrecognizable. It’s also cheap and readily available.

Which leaves us with Java. Java is the beer of our drug metaphor. Cheap, ubiquitous, it gets the job done in the least sexy possible way. You can fuel a whole party on beer, but it’s a heck of a lot of work and you find yourself staring at a urinal more often than you’d planned. Still, you can get it pretty much anywhere and it’s been popular since the beginning of recorded history.

You’ll notice I left out .Net. It’s easy to take cheap shots at .Net, like making it the wine cooler or the Bacardi Breezer. So I will. .Net is the Bacardi Breezer, last refuge of the undergrad and technical school dropout, attractive only because it comes in the shiniest box.

Which is why I’m actively trying to recruit someone to take over the server side. Clearly, I’m not qualified.

A few days ago I posted about using Spanning Sync and Proximity to synchronize iCal, Google Calendar and my cell phone (a k790, although any phone supported by iSync should work).

It turns out there is a free alternative to Spanning Sync called GCALDaemon, which is a bit more work to get running but a decent alternative if you don’t want to pay for Spanning Sync.

Read the rest of this post… »

There was a time when I could keep my entire schedule in my head. Years of university test times and due dates were dutifully tracked by my brain. In the intervening years, however, I seem to have killed most of my long and short term memory with booze — or maybe I’m just a whole lot busier.

In any case, I’ve been facing an increased sense of panic every time I try to book an appointment. What if I have a conflict? Krista keeps her entire life in the pages of a daily calendar, so I’ve attempted to follow suit, digital style.

This isn’t the first time I’ve tried, but every previous attempt failed for one reason or another:

• Google Calendar: I love having my schedule available from pretty much any machine with an internet connection, but launching it seems horribly slow and the whole experience is oddly divorced from everything else on my Mac. I could write a whole other post (and maybe I will) about my migration from Windows native apps to Web Applications, and back to native Mac apps. I think it says a lot about how good OS X’s integrated tools are, though, that I’ve taken that path.
• iCal: really, a beautiful calendar, but I missed the “everywhere-ness” of Google Calendar. I can do a one-way sync from Google to iCal using iCal’s Subscriptions, but anything I add to my local calendar won’t get reflected back. This is critical, as I’d like to be able to check the calendar from any other machine, including my cell.
• Sony Ericsson k790’s built-in Calendar application: a surprisingly full-featured little calendar tool. For my process to work, I need to be able to quickly add events on the go. iSync takes care of synchronizing iCal and the k790, but I’m too forgetful (and lazy) to sync it myself whenever changes are made.

On certain models, mainly MacBook Pros, this seems to be the case. I’ve been having trouble staying online recently, mostly on my home network. Connections are maintained, but it’s increasingly hard to create new ones. DNS lookups can be painfully slow, and Google Talk conversation (through Adium) die midstream, with nary an error message in sight. My problems date to around the time of the 10.4.10 Update, although they’ve been getting much worse in the past week as I spend more time on my home WiFi connection. Some users are reporting frequent kernel panics, others are having stability if outlet power is used instead of battery. In my case, it’s just very frequent poor connectivity.

I’ve just installed the fix recommended by user IamNobody in the Apple forums. Let’s hope it works. Look for the post dated Jun 30, 2007 5:01 AM.

Update: looks like I’m late to the party. Apple released a fix within minutes of this post. Yay?

One of my favourite ways to get introduced to new music, and to introduce others, is through a simple game called “revolving DJ”. It can be played at parties, in your office, or anywhere you can hook an iPod up to a set of speakers. The rules are simple: each participant plays a 3 song set in turn until the party ends and everyone goes home. By trying to choose music you think everyone else will enjoy, or is unfamiliar with, you pick up all kinds of new influences.

It was during a lazy Friday afternoon of Revolving DJ and beer than an idea was sparked in my head, regarding the iPhone and the lack of 3rd party native applications. It doesn’t take too many songs before you long for a method to effortlessly transfer tracks directly from one iPod to the next. A few moments later, someone will inevitably realize “hmmm, the Zune could actually do that“. Unfortunately, it’s implementation was so hopelessly crippled by the marketdroids and RIAA-fearing managers at Microsoft that the device was essentially stillborn.

Apple has also built an iPod with WiFi — it’s called the iPhone, and while most people are rightfully focusing on the new features of the device (phone, web browser, email client), it’s also considered one of the best iPods ever built (ignoring the anemic storage for now). The device runs a version of OS X, meaning the only preventing a mobile p2p application that can share music with friends or strangers is a smart programmer and a way to load the application onto the iPhone — conveniently left out. The Zune crippled it’s WiFi in firmware, but an open SDK on the iPhone would mean anyone could easily install such an app on their phone. Even better, if you didn’t already have the p2p app, you could easily jump on the web and download it the moment you needed it. It’s the viral-social, the dream application for music-heads everywhere, and Apple can’t stop it without throwing the baby out with the bathwater, which is pretty much what they did by not shipping an SDK for the phone.