Category Archives: Work

An Owl’s Life


Dan just posted the first public transmission regarding our project, with a slick little banner of my design, and now I’m at a bit more liberty to talk about the work I’m doing at Adaptive Path. is a website dedicated to helping people accomplish goals and learn stuff they want to know, in a supportive and socially collaborative atmosphere. AP just wrapped up a project helping the folks at Cerego clearly define their user experience goals with the site, and now we’re in the process of designing, developing and launching an iPhone application to complement their web-based learning tools. The really cool thing is that these guys are super open about the work they do, and are more than happy to have us share our process as we craft their application.

Alexa and Dan just got back from Tokyo, where they were busy meeting with the brilliant brains behind and scoping out million-dollar cantaloupes in their free time. As we continue our design process we should find ourselves posting regular updates to the Adaptive Path blog, but I’ll try to chime in at this venue however I can.

For now, it’s time to grab some sharpies and start sketching, sketching, sketching!

I can’t wait to tell them about the exploding moon.

I woke up at 6:30 this morning and realized I had to give a 30-minute presentation to the company at noon, introducing myself to the entire gang. I was gunning for a largely visual deck and had flagged a number of photos in Aperture for this purpose, but I hadn’t even started assembling the presentation in Keynote.

It was definitely a cram and I think I pulled it off, but I did learn a thing or two about narration. If you introduce a character, say a car named the “Green Dragon Wagon”, your audience will become confused and uncomfortable when you replace it, unannounced, with a silver Subaru. Then, your audience will become downright hostile if you present a photo of an old pickup truck, unintentionally suggesting that this is your car, with nary a mention as to what happened to the Dragon or the Subaru.

Dog Mountain

You see, people interpret and grow attached to things, be they rhetorical conveyances or characters in a narrative. If you unintentionally toy with their emotions by flippantly dismissing or substituting these characters, they’ll call you on it. If they like you. If they don’t like you they’ll silently judge you for it, for the rest of their lives.

Dane and James' Lost Dreams

Also, in wrapping up my presentation I described to the company our concept work for Dane and James’ Lost Dreams, which is, for those who have forgotten, what you get when you combine a cruise ship with a roller coaster (you get Awesome, with a capital AWE). Yes, Dane and James’ Lost Dreams is a true work of user-centered brilliance, a cruise ship designed for the type of person that is most often attracted to cruise ships in the first place: chiefly, people who wear faded black Harley Davidson shirts with the sleeves cut off. Upon reflection, I wish Andrew could have been there for the “sharing out” of this, given his career history. Even so, we got some largely positive feedback on our work:

“Are you insane?!”

Probably. They’ve got eight more weeks of this, and they don’t even know the half of it yet.


All my mail is being forwarded for the summer, and it’s always shocking how long it takes something to wind up at its desired location. After more than a month in the system a stern letter from the IRS finally wound its way to my disciplined staff of Dutiful Mail Handlers in Minnesota. I’m summarizing the finer points of the memo, but apparently a stained cocktail napkin with some numbers scrawled on it is not a proper format for one’s own federal tax return. Which is funny, because I swear I scanned in that napkin and sent it to them electronically.

I called the IRS, and after assuring their automated phone system that I wasn’t looking for money, that I didn’t think the government owed me anything, that I didn’t care about the stimulus package or tax rebates or “gettin’ mine when the gettin’s good”, I was finally able to connect to a real person.

And he was the kindest, most helpful person in the world. Truly. The IRS employs some classy people, and if you can navigate the labyrinthine phone system and trick it into connecting you to them, you’re going to find yourself in a good place. We talked it through, resolved the issue, and that was it. Done. Consider, too, that it was 8:30 at night, Pacific, which is, like, already tomorrow for you suckers on the east coast. No matter where that dude was, he was workin’ late.

And I appreciated it.

Today was Day Two at the ‘Path. We got to hang with one of the founders for awhile and attend some company meetings, and I started getting oriented within my project. It’s pretty big and complex, but it’s currently moving into a new phase where I’ll be able to flex my elite interaction design skills. Sadly I cannot talk in detail about my work, so instead I will talk about my co-workers. Such as Andrew, who says he maintains a fire under his desk so he can burn all his trash, rather than learn which receptacle in the kitchen corresponds to recycling, trash and compost.

Yes. San Francisco offers curbside composting.

Besides the people who relieve themselves on your front steps.

Fainting Spells

Kate is back from her canoe trip, which proved to be a frigid paddle through the arctic wastes of northern Minnesota. Meanwhile, I’m enjoying the ethereal orange glow of a fogged-in city.

Today was my first day at Adaptive Path, and I’m likin’ what I see so far. There’s a lot of stuff goin’ on in that space, and while we spent most of the day getting settled in with online accounts and paperwork and other necessary features of orientation, I can’t wait to start digging into some work with these fine, talented folk. I’ve been getting caught up on all of the projects going on around me, and tomorrow my own project should finally condense out of the vaporous mists of ambiguity.

Whiteboards and markers, Post-It notes and sharpies, pencil sketches and Photoshop mockups and Keynote presentations, these are all the units of thought at work. Projects take over entire rooms, with ad hoc affinity diagrams and screen printouts for use scenarios covering the walls.

Any sane person would balk at such apparent chaos, but a true interaction designer would no doubt swoon upon entering the AP office. There is indeed a madness to the method, and I can’t wait to completely throw myself into the arms of the process.

Quantum Entanglement – Part II

This is Part II. Read Part I.

As I mentioned earlier, Siskiwit and Rosco were unintentional BFF. When I launched Rosco I wanted to preserve the link structure of Siskiwit, because people were still way into searchin’ for and diggin’ on that stuff.

Siskiwit had a long and colorful history of publishing platforms, but a number of years ago it settled on Movable Type, where it has remained ever since. Recently I tried upgrading its circa-2005 installation to the latest and freshest version, Movable Type 4.1, and I nearly fell out of my chair because it executed so flawlessly. Seriously, nothing went wrong. This made me realize that Siskiwit was far more portable than I gave it credit for, and I began strategizing on how to move it away from and onto its own subdomain.

Transmit Textmate BBEdit

Up until recently, I have done all of my development on my server at DreamHost, hosting them at super-secret subdomains. The majority of my development cycle would involve launching Transmit, opening a file on the server in TextMate (or BBEdit if I need to do some heavy-duty regex), editing that file, saving it, and refreshing my browser window. I don’t know how many web designers work this way, but I’m willing to bet a fair amount of them.

If I’m installing a package of software (say, Movable Type or WordPress) I’ll often FTP into my server to upload the tarball or .zip file, SSH into my server to expand the file, and then return to Transmit to move the expanded folders and files to their proper locations. Ditto for large image directories, or other cases where I have multiple files to upload at once. All the goddamn handshaking that goes on with an FTP transfer makes it a horrible tool for uploading multiple files, and if your connection drops halfway through a transfer, it’s difficult to figure out what got copied successfully and what didn’t. I don’t know how many times I’ve been hosed by a file that appears to have transferred successfully, but turns out later to have been only a 0 KB placeholder.

This, this development process is dumb. I never realized how dumb until I started working with Jason, and we did all of our development in Subversion.

Subversion: Time Machine for Your Project

If you’ve never used a version control system you may have no idea what all the fuss is about. Once you’ve used one, though… no, once you’ve lived in one for a few weeks, you’ll wonder why everything in the world isn’t done this way. Seriously, everywhere I look now I see opportunities for version control. I wish I could rollback the street in front of my house, so I could drive on it at a moderate speed without bottoming out on this year’s crop of potholes. I wish I could form a branch for this day, which has been kind of cloudy and crummy but altogether windy, and see what would have happened if I chose to go kiteboarding instead of writing all afternoon. The planet? Sheesh, talk about something that needs to be loaded into Subversion, like, yesterday.

Subversion is a popular open-source version control system, which stores and tracks every change made to every folder and file that you load into it. Well, not every change, as it only tracks changes that you “commit” to it. Anywho, it’s like Time Machine for code. Your entire Time Machine drive would be called a “repository” in Subversion parlance, and every snapshot of your computer (or project) at a particular moment in time would be considered a “revision”.

Phew! Being a noob myself I’m in no place to teach you everything you need to know about version control with Subversion, but fortunately there’s an excellent book on that very subject. If nothing else you should read chapter one, which covers the fundamental concepts of version control, and shows some examples of Subversion in action.

If you’re used to developing on a web server, applying version control to your development requires a fundamental shift in practice. Fortunately, this shift is one that turns out to be rewarding in many ways, including speed of development, robustness of your code, and ease of deployability. Your Subversion repository lives in the cloud, so to speak, and you download, or “checkout”, the most recent revision to a folder on your local machine to do your work.

OS X Leopard has just about everything you could ever want in a web server already installed on it, including Subversion, Apache 2, mod_rewrite, PHP 5, Ruby, Ruby on Rails, and MySQL, so creating a local web development environment is a pretty straightforward deal. That said, a lot of these fixin’s aren’t enabled out of the box, and they will take a bit of mucking around to get running. You need to turn on mod_rewrite and PHP, you might want to upgrade Rails and other preinstalled Gems, and installing the MySQL preference pane might make your life easier. At a later date I’ll try to outline my experience of getting my own OS X development environment running. For now, just trust me.

A step-by-step manual for setting up your local machine for version-controlled development is outside the scope of this article, but at the very least I want to give you a cursory glance of what my current setup looks like. This all came into being within the last few weeks, but already it hands-down beats the knickers off Ghetto-Ass Subdomain Remote Web Server FTP Development.

Non-Ghetto-Ass Local Development

First off, if you need a Subversion repository look no further than Beanstalk, who definitely put the sexy in version control. Honestly, if my first time had been with anyone but Beanstalk, I would have sworn off the whole thing entirely, given the craptastic nature of most Subversion applications. Most host and client setups assume prior knowledge of Subversion, incredible technical aptitude, and hella-tolerance for lousiness. Beanstalk makes it really easy to import your initial project into Subversion, and offers a free account with up to 20 MB of space, which will be fine out of the gate unless you’re planning on working with tons of images. Or, perhaps, if you’re planning on using the SQL on Rails framework.

The cool thing with Subversion is that every time you commit a revision to your project, it doesn’t need to make new copies of all the files. It hardly even makes a copy of the updated files. Nay, it just tracks and records the changes within the files. Thus, a 2 MB project with 10 revisions will not weigh 20 MB. For instance, I have a current project where my working copy weighs 11.5 MB, but the repository (with 69 revisions already) only weighs 3.4 MB. Wow, that’s a surprise. I have no idea how that works, in that my working copy weighs more than the entire repository. Perhaps there’s some voodoo magic going on, but I’m not gonna argue!

svnXOnce you have a repository, you’ll probably want to install a Subversion client on your local machine to make it easier to interact with the repository. Subversion is built with the command-line in mind, but a lot of us don’t think that way. I’ve been using the svnX client for a number of months now, and while it’s incredibly goofy I believe it’s the best one available for OS X. You can configure it to connect to a repository, and then checkout a revision to make a working copy on your local machine.

HeaddressManaging, hosting and testing multiple web design projects can be a pain, however, especially if you don’t want to muck around inside Apache’s httd.conf file. I use Headdress, a tiny application that helps you manage virtual hosts in OS X, to handle all of my local development websites. The free version of Headdress lets you host two sites simultaneously, and if you want to run more it’s a lousy $14.99.

Ahem. Welcome to your new workflow, where you edit your local working copy while testing it in a browser window. When you feel like you’ve reached a comfortable point in your development, or if you’re about to try something risky, go ahead and commit the changes you’ve made to your working copy to the repository. This is how I do it now. Edit locally, refresh locally. Edit locally, refresh locally. Time to fix another cup of tea? Commit all local changes to the repository as a new revision.

“What about launching? What about deploying? What good is all this work if no one can see it?” I’m glad you asked! I still maintain a number of super-secret subdomains, where I can test my development work directly on the web server that will ultimately host its production version. Remember, the working copy of your website on your local machine is just that: a copy from the repository. So long as you’ve committed all your changes, the exact same site exists inside the repository as the most recent revision of your project.

Deploying your site, whether it’s deploying on a testing domain or deploying for realz realz, is just a matter of “checking out” a fresh copy from the repository. This is pretty easy, so long as you have Subversion installed on your web server. I’ve found the easiest way to do this is to SSH into my server, navigate to the parent directory that holds the folder in which I would like to expand the copy, and using the svn checkout command to checkout the most recent revision from the repository into that folder. After I’ve done that, I can continue to freely edit my working copy on my local machine, and commit those changes to the repository, without worrying about messing up the copy on my web server.

Once I’m happy with some new changes I’ve made, however, it’s easy to bring the version on my web server up to speed. All I do is SSH into my server, navigate to the child directory into which I originally checked out the copy, and type svn update. Bam! Everything that was out-of-date is now up-to-date! It can certainly be a lot more complicated than this, which is why there are services like Capistrano that automate the deployment and updating process, but at its most basic this is what’s going on.

“Dammit, Dane!” you’re saying. “What about my database? What about my needs?” Indeed, to make this work well you need to have a database that your local working copy can connect to. Sometimes you can use a remote server, which is what I did until I found a better solution. Currently I run a few MySQL databases on my local OS X machine, which I connect to via localhost and manage through CocoaMySQL. Getting WordPress to connect to a local MySQL database took a bit of finagling, but a quick search revealed an easy solution.

Disentangling Siskiwit

So. I wanted to move Siskiwit, and each and every part of it, out of Brainside Out and onto its own domain. The fact that I was able to upgrade Movable Type made me realize that Siskiwit was likely more flexible and portable that I had thought. To test this theory, I created a new project on my local machine, did a fresh install of Movable Type on it, and imported its current MySQL database onto my local MySQL server.

After changing a few configuration files to reference the new local database, I told Movable Type to rebuild all the weblogs, which it did flawlessly after only a few initial hiccups. I had a few stray layout, design and container files that I had to bring down from the live server, but the amount of customization necessary to get the site working was minimal.

At this point, the old skool way of doing things would have been to wrap up my local copy of the site in a zip file, FTP it to its corresponding subdomain on the server, and SSH in and expand the file. As if! Instead I created a new Subversion project at Beanstalk and imported my local copy of Siskiwit as a starting revision. From there I SSH’d into my server and ran svn checkout to put a copy at its new subdomain. I changed a few configuration options to make the site reference its live MySQL server, had it rebuild all the weblog files, and it all worked like gravy.

It’s worth noting that I left all the “rebuilt” weblog files out of the Subversion repository, and I left out the actual Movable Type install as well. With the former, Movable Type creates the static rebuilt files based on the content in the database, so they’re completely unnecessary so long as Movable Type has a database to work with and rebuild from. With the latter, since I’m never going to edit the Movable Type system files there’s no need to keep them under version control, so I just uploaded the .zip to the server and expanded it.

Likewise, since my images directory for Siskiwit is pretty huge, and since I don’t plan on making any changes to it, I left it out of the repository as well. This can be some fairly subtle and complicated stuff, and I mention it just to be clear that it doesn’t make sense, nor is it necessarily advantageous, to store everything in version control. Your own mileage may vary.

Before nuking every last trace of Siskiwit from Brainside Out, I wanted to make sure that visitors accessing pages at their old locations (either through search engines or through a crazy-good memory) would be seamlessly redirected to the page’s new location at the site’s new subdomain. I did this by adding the following rule to my .htaccess file in the root of

RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www\.)?brainsideout\.com$
RewriteCond %{REQUEST_URI} ^(/weblog|/photolog|/sundries|/classics|/av)
RewriteRule (.*)$1 [R=Permanent]

I have a few more rules besides this one, but they relate to CodeIgniter and aren’t relevant here. Also, if you want to monkey with .htaccess files on your locally hosted OS X websites you’re going to have to turn on mod_rewrite. It’s a bit of a thing, but you probably won’t die trying to do it. Headdress does have a bad habit of occasionally overwriting changes that you’ve manually implemented in your httpd.conf, especially when you add or remove a site from within Headdress. Yeah. Good luck with that.

With Siskiwit under version control and relocated to its new subdomain, and Rosco versioned and backed up as well for some inexplicable reason, I was finally ready to nuke everything at and deploy the new, CodeIgnited version. I SSH’d into the server, navigated to the corresponding directory, and with cautious fingers typed rm -Rv --preserve-root *.

I then left my computer and fixed myself a drink. Upon returning I checked, double-checked and triple-checked my work, and pressed return. Then, with a haste matched only by the files scurrying up my screen, I deployed the new edition of Brainside Out from the repository.

Spring is here, and comments are open.

That’s right, comments. It’s gonna be that kind of spring.

End Part II. Read Part I.

Quantum Entanglement – Part I

This is Part I. Read Part II.

Over the last few weeks I’ve been working diligently on a few personal web projects, and what you have in front of you now is the most recent incarnation of Daneomatic, which was launched last night. There’s also a new version of Brainside Out, which has already been puttering about the neighborhood for the last week or so.

Brainside Out

The original plan was simply to rebuild Brainside Out, but I was so fancied with the results from that project that I felt compelled to bring it over to Daneomatic. The act of “porting” the design and integrating it into the slapdash theming engine of WordPress took more effort than I expected, but I still figure a three-day turnaround from naked idea to launch isn’t that bad a churn.

The Problem With Supermodels

While it was definitely a fun challenge to piece together, in the end I was never too fond of the previous redesign of Brainside Out, launched in 2006 and codenamed Rosco. It always felt too heavy, confining and noisy. I was aiming for a funky private jet with shag carpeting and a rotating bed, and I feel like I hit a threadbare middle seat in coach. What’s more, the previous site was built to drum up work for an independent business that has since been pushed mostly aside to make room for a full-time job. This particular event happened more than a year ago, and if there’s one thing that supermodels, pets and websites don’t thrive on, it’s neglect. Unless they’re sea monkeys. sea monkeys dig that neglect shit. Kate and I are so gonna get some sea monkeys when we move into our new place.

More insidiously, the files that drove the Rosco edition of Brainside Out were intertwined with those for Siskiwit, the previous-previous version that was a weblog of sorts, a culmination of all the writing and web design I had done since 2001. The two sites existed side-by-side, confusingly wrapped around each other in a suffocating embrace, one stiff and businesslike, and the other bent low with a millstone of archives around its neck.

With the repositioning of Brainside Out as a business it didn’t really make sense, nor would it have been worth the effort, to bring Siskiwit and its thousands of archives forward into the Rosco design. Daneomatic would carry forth the Brainside Out weblogging tradition, but with five years’ worth of blood, sweat and tears put toward its name (or rather names, for those with ancient memories) I wasn’t about to nuke Siskiwit’s archives.

And so it came to be that I erected a crude scaffold around Siskiwit, allowing me to leave it fully intact while supplanting its front-facing views with Rosco. This worked. This worked just fine, and it very well would have continued to work if I hadn’t been born such a wild and restless child.

Bootstrapping in Flip-Flops

For years, up until just recently, all the sites I’ve built have been propped up with a laughably crude, but impossibly handy, PHP bootstrapper of my own devising. Calling it a bootstrapper may be too generous, as it’s nothing more than a glorified include file. Despite its inelegance it filled that void between “static website” and “dynamic template engine” with remarkable effectiveness, to the point that there was never really any incentive to improve upon it.

I’m a control freak when it comes to file structures and resource hierarchies, and as a code snob I am loathe to subject myself to the default outputs (or, gasp, the default layouts) of anyone’s content management system. With my simple bootstrapper I could build and deploy a site extremely quickly, all the while putting everything precisely where I wanted it to be. I wasn’t about to adopt another convention until I discovered something that was remarkably better.

And then I discovered something remarkably better.

Something Remarkably Better

Bixby BaconDuring SXSW I shared my experience with building Bixby Heart Dot Com (that’s B-I-X-B-Y Heart Dot Com) with the EllisLab folk, but unless you were one of the twenty people attending their open panel, this anecdote likely bears repeating.

Jake and I had limited time to work on the Bixby Heart project and we wanted to get it out the door in time for SXSW, so throughout our development process the focus was always on “light is right”. Jake is one of the most talented designers I know, and I’m a great front-end (and lousy back-end) developer. Thus, perhaps inevitably, Jake did all of the design and much of the front-end development, and it somehow fell to me to write the back-end code. Yikes.

I wrote all of Bixby Heart in PHP, and I felt I did a fairly decent job at it. I compartmentalized all my functions and fine-tuned them for robustness. In the interest of simplifying the development process, one of my earliest decisions was to use flat files, rather than a database, to store incoming data. Databases are one of the most fickle, insecure, time-consuming and misunderstood subjects of web design, and I wanted nothing to do with any of it. I figured if I sidestepped the issue it would just go away.

Boy was I wrong.

I set up a buffer flat file that intercepted incoming data, and rotated every few minutes on a cron to dump its contents into the primary flat file. At first it recorded boolean values for “bacon” or “juice”, and soon it recorded timestamps along with them. Then it recorded IDs to prevent writing the same entry multiple times. I’d parse the flat file with string compares, searching for tabs or newlines or what-have-you. I even set it up to increment through the contents of the flat file, in case it became so huge that the entire file couldn’t be held in memory at once.

It was when we actually wanted to do something with the data that it all fell apart. Display the number of bacons? How about the number of juices? Oh dude, how awesome would it be if we could graph the heart rate over time! Say, do we even know how to compute the current heart rate?

SXSW was in two days and I was at an absolute dead end. We were taking in test data but I couldn’t figure out how to work with it in any reasonable fashion. I tried tweaking the flat file setup. I tried setting up a database. I panicked, and even tried installing Pear DB. Before long the entire application was completely fucked up and I didn’t even have a working copy to roll back to. In a single night we went from having a semblance of an application to having an unmanageable rat’s nest of broken code. It could not be saved. I gave up. I gave the fuck up. I cried and screamed and pummeled at my pillow with tiny little fists.

And then I found CodeIgniter.

Code IgniterCodeIgniter is a lightweight MVC framework, brought to you live in PHP by the same guys who gave you ExpressionEngine. I had installed and tinkered with CodeIgniter before, and of all the application frameworks I had experimented with (CakePHP, Symfony, Django, Rails, etc.) it was by far the most clearly documented and easiest to install. It’s worth noting that the upcoming version of ExpressionEngine is written entirely in CodeIgniter, and it’s so hot it will make you cry. With less than 24 hours between us and SXSW, I realized that this was our best, and perhaps only, chance of finding a database class that would suit even our meager purposes.

I decided I would give it a shot, and eight hours later I had completely rewritten Bixby Heart in CodeIgniter. We had a fully-functional application to bring to SXSW. I built all the necessary database hooks, and Jake thusly grabbed them and wrote the front-end hotness. Before long we were soaked in whiskey and vodka, presenting Bixby Heart Dot Com to a private audience as we struggled to keep our balance in an RV lumbering through downtown Austin.

After that experience I decided any application, nay any website, that I built from thenceforth would be written in CodeIgniter or a suitable equivalent. I make a lousy zealot and thus am open to other options, but as an individual I have by far made the most progress working in CodeIgniter. When rebuilding the Big Winds website in Ruby on Rails I worked with Jason Ives, a talented local developer, but without his canny knowledge of server configurations, database schemas and all-around Ruby l33tness, I am but a lost little puppy.

And so it came to pass that the new version of Brainside Out is written in CodeIgniter. In its current state it’s skimpy as far as content goes, and I’m still debating how best to go about resolving that. The site still suffers from a modest identity crisis, especially since the majority of my web activity has moved offsite, but now it is far less confused than it was during the “is a business, is not a business” phase. More than anything, I needed to shrug off the yoke of all its legacy innards, and figure out an elegant way to store that stuff elsewhere.

And that, my friends, is our next story.

End Part I. Read Part II.

Lacking even the sophistication of a Twitter update.

Ironically, I find myself spending so much time with the internet lately that I have no time for the internet.

Gainful Employment

“How’s the shop?” you ask. Yup, it’s been a couple weeks since I sold out and went whole-hog at Big Winds. It’s been great, and while my job suffers from a severe and terminal case of ADD, I’m not so sure that’s a bad thing.

Sometimes I’m working on the website, but much of the time I’m helping customers in the store, or answering kiteboarding questions on the phone, or processing internet orders, or cleaning out the microwave after my coffee exploded. For the next couple days I’m actually in charge of the shipping department, as Joe has taken a few days off to go out to Joseph, Oregon and give a ring to a special person. Sadly, he may return to find both his bachelorhood and his workspace in ruins.

A few days ago Bruce Peterson, the brilliant and kind fellow behind Sailworks, stopped by the shop. While climbing into his van he found me on the sidewalk in front of the shop, covered in dust and shaking the dirt out of a whole stack of rugs.

“Hey Dane, welcome back!”
“Thanks, Bruce!”
“So, web guy, eh?”
“And… rugs, looks like?”
“Uhh, yeah. Either way, I usually just take them all out back and beat them.”

So yeah, I’m all over the map these days and still busy getting reacquainted with the shop, but I’m really enjoying the diversity of it all. In regards to the website there’s a whole lot of changes I want to make, but much of it falls behind my current priority, which is to simply make our online product catalog accurate. There’s a lot of data in there, and even though I’ve nearly rewritten the entire back-end over the years, there’s a lot of legacy code that prevents me from efficiently making large-scale updates. That said, I have managed to eek a bit of coolness out of the deal:

Using this batch of Photoshop Automator Actions, I’ve automated the generation of product images for the website. It took a couple hours of development, but now I’ve got a nearly foolproof system that takes in a batch of original high-res images, and automatically creates large, standard and thumbnail sized images. The whole deal respects aspect ratios, throws in a bit of unsharpen mask and gently compresses each image, all while I microwave yesterday’s coffee for the fourth time.

Thanks to this, I’ve been able to integrate Lightbox with our kite detail pages. It’s still in beta so there aren’t any visual cues, but if you click on the kite picture it’ll bring up a larger version. I really wanted the large images to be much bigger, but our web statistics suggest that most of our visitors are still stuck at 1024×768 resolution, and I didn’t want them to have to scroll to hit the close button.

Hard to believe, eh? I mean, I kicked 1024 to the curb at least five years ago, maybe nine, and my preferred environment these days is a whopping 1900×1200. Apparently there are still a bunch of people out there who want to be miserable in front of their computers, and want blindness to accompany their barroom deafness.

Here’s another interesting discovery. According to our statistics, as well as some off-the-cuff usability studies I’ve conducted (which is just a fancy way of saying that I watched people browse our website), people have no clue that the “Boards”, “Sails”, “Masts”, etc. headings in our primary navigation are clickable.

It appears that even the New York Times website suffers from the same problem, which is probably why they have little » » glyphs next to their category headings. While I definitely have qualms about the improper semantics of using right angle quotes as visual cues rather than as, say, quotes, I figured I’d give them a shot and see if they affect usability at all.

Another kinda neat thing we did to the site is add a couple of QuickTime VR Tours of our shop. A couple months ago we had a guy come in and shoot the whole place with a fisheye lens, and stitch the photos together all right-nice. In the interest of catering to a hideous web browser that is used by a vast majority of our visitors (see my earlier point about how people want to be miserable at their computers), I tried to embed the videos as unobtrusively as possible, using these scripts provided by Apple.

Long story short, by using JavaScript to embed the video code, I am able to circumvent the repercussions of the Eolas lawsuit, and make the videos work in Internet Explorer without requiring visitors to hate their lives and click on it multiple times.

I know, I know. There are better ways to embed content, ways that will validate and are semantically correct. That said, even the most recent article on A List Apart doesn’t arrive at a definitive solution for the issue, and as such I’m willing to leave this one up to bloody pragmatism. My solution above worked in every browser I tested, under nearly all conditions, and I call that good.

In happier news, I did manage to get all of my tiny, disparate onload JavaScripts to fire using the same addEvent() function. Major props go to Dustin Diaz for his rock solid addEvent() function, though I might add we’re still gonna whoop his butt in bowling at SXSW.

And hey, did you know that in a Google search for “camp loo”, camping toilets come up in nearly all of the link ads? I just thought that was funny.