Skip to: Navigation | Content | Sidebar | Footer

Full Archives

7 Things

December 29

Well, I suppose if everyone else is doing it, I'd better join the fray with a year-end introspective of my own. Here are 7 randomly-selected things that made me happy in 2005, in no particular order.


New to me this year: the command line. (Or at least, the Unix command line... we won't mention that sordid episode with MS-DOS back in the 80's and 90's.) Without hands-on experience, it's easy to look at keyboard interaction as primitive and outdated, but the simple elegance and power of text-only mode is really growing on me. With tools like rsync and ssh at my disposal, I can do insanely great things like back up my entire web server automatically. And of course, OS X offers the best off both worlds: Unix, with a top-notch GUI and all my design tools in one place.


No really. XHTML, with an intentional X. All debates aside, the fact that as many pages on this site as are humanly possible are stored as valid, well-formed XML meant I was able to use one of the many existing open source XML parsing libraries to extract a bunch of hard-coded information and do something I wasn't entirely sure was possible.


It was the year of the script. Sites like Flickr and Google Maps kicked off a major renewed interest in the humble curly brackets, and folks like Jeremy Keith and the DOM Scripting Task Force have made sure to keep our code in check. If/when a redesign happens around these parts during 2006, it's a safe bet to expect the odd bit of unobtrusive script.

Google Maps

Hey, and speaking of Google Maps, I fell in love in an instant when it first launched earlier this year. I've been interested in maps and satellite imagery since forever, so Google bringing it to the web with such a simple, intuitive interface and an extensible API was a master-stroke. GMaps on a Treo? I'm so there.

And credit where it's due: have you seen Microsoft's answer? Bird's-Eye View is enough to make me forget about Google Maps. If only they covered Canada too... (Goal for all mapping services in 2006: extra-US data, please.)

Digital SLR
Mossy Tree

The difference between a digital SLR and a consumer point and shoot is the difference between Chef Boyardee and a four star Italian restaurant. Though I'm no pro, this camera makes me feel like I'm a way better photographer than I really am. Check out the image linked through the thumbnail—it's straight off the camera. (Careful though, your browser might not like 3504x2336)

CBC Radio 3 & Ricky Gervais Podcasts

This time last year, I'd barely heard of podcasting. This year, it's the New Oxford American Dictionary's word of the year. The only two I've found to be must-listens are the CBC's "best of" Canadian indie music podcast, and the relatively new, short-running Ricky Gervais Show. The former gets me hooked on tunes I can actually feel good about buying, the latter has me on the floor weekly.

Katamari Damacy

I'm glad it's still cool to like this game, because I love it. From the quirky humour to the zany music to the obsessive-compulsive gratification of the game-play to the take-no-crap attitude of the creator, it's Great. End of story. Now get the T-Shirt.

Permalink › | 28 comments

Destructive Strokes

December 22

This is kind of a minor thing, but something that's been a growing irritation for a while. Photoshop's Stroke layer effect actually eats into the layer it's applied to, resulting in an undesired destructive effect if you start doing things like adjusting the layer blending mode or opacity of the stroke.

Stroke effect cutting into the layer to which it's applied.

So, in this image the left window has a black square sitting on its own layer, in the middle I've applied a 3px red stroke on the inside of the layer, and on the right I've reduced the opacity to 20%. Instead of the red stroke blending into the black square—since it's sitting on the inside, remember—the white background behind the square pokes through, which means the stroke is effectively knocking out any pixels of the original square.

Not a permanent loss since you can always discard the layer effect, but it seems counter-intuitive to me. I suppose there are situations where this might be the desired and expected behaviour, but more often than not I'd prefer it if the stroke were simply to fade into the layer.

The simple work-around: Cmd + click (or Ctrl + click on the PC) the object's layer in the layer palette, create a new layer immediately above it, and then use Edit -> Stroke to apply a stroke to this layer. This selects the object's contour, and applies the stroke pretty much the same way as the stroke effect, just on its own layer.

I suppose this would be less of a pain if Photoshop's layer management weren't such a hassle already.

Permalink › | no comments


December 19

You know and love, and now there's a new kid on the block. The Javascript-based FACE aims to "enhance standards-compliant pages without sacrificing important aspects such as accessibility, scalability and flexibility." Simple animation effects are enabled by the script, and then controlled by CSS; in theory, you can now animate any change you might inflict upon an element. Like, animating an element resizing. Or animating a palette cycle. Or growing a border. Or... etc.

A bunch of demonstrations of FACE in action are available in the various sections on creator Faruk Ateş' site, KuraFire. Unfortunately, most are animation of the on-load variety, which you'll likely remember growing sick of during the Flash days. It's pretty hard to love pages that animate on their own accord anymore. Thankfully, FACE is not limited to that. Check out the example Destinations page for some basic hover effects; the interactivity options strike me as much more useful, especially in light of

While it would be premature to rush out and replace your copy of Flash MX with a bit of Javascript, FACE might just grow into an alternative for times when Flash feels like overkill. It should be interesting to see how this one develops. It has potential.

Permalink › | 31 comments

Presentation Mode

December 19

That's it. I'm totally over HTML for slides. Done. Finished. The straw that broke the camel's back: frantic last minute browser testing on a plane under Virtual PC as my computer's battery meter inched ever closer to the red zone because after spending two solid weeks creating material and producing my slides, testing in IE6 just somehow slipped in the list of priorities.

I've tried out a few management methods for making HTML slides easier to create and work with, including PHP for the individual slides, as well as S5. Anything I use keeps coming back to the same problem though: HTML slides, the way I produce them, require far, far more effort than they're worth.

Lately I've been moving well away from bullet points for my slides, and more toward imagery and low-verbage concepts. I also choose to build cohesive, visually unique slides, and as best I can, try to ensure the audience has a reason to load them up after the talk; I've been peppering them with links to external articles as "footnotes" for my presentation, for example.

The theory is nice. Present from the same slides as I hand out, and people can click through the URLs, revisit the examples I gave, etc. etc. Hypertext seems like a good addition to my standard set of slides, from a user's perspective.

But along with that come issues like navigation, screen resolution, production, and testing. It's not enough to rely on non user-facing keyboard shortcuts to flip through the slides, I have to expose them somehow for people viewing the slides later. (S5 has an elegant way of dealing with this, but it's an issue with any other slide management system.) It's not enough to simply design your slide layout and the component slides, I have to then output images from my graphics editor of choice and produce the HTML. It's not enough to simply test in the browser I'll be presenting in, I have to test in the various browsers my audience might be using. Not to mention that if I plan on re-using a presentation more than once, I'll likely have to account for both 800x600 and 1024x768 projectors (and then the user's screen resolution on top of that.) That's about three steps more than I think should be necessary, and there were even more issues that popped up during this last round that I won't even get into here.

Essentially, for the types of slides I build, producing the material for a one hour talk feels like it requires almost the same amount of work as I'd devote to producing a 40 or 50 page web site, which is simply silly. A web site gets continual traffic from numerous visitors over long periods of time; it's worth the effort. A presentation is a short, time-limited event with a few hundred people at most, and the only reason any material is necessary afterward is to remind people of what they viewed, and in some cases to provide them further information if they're interested in following up.

So I bought Keynote. And with the exception of events where I'm forced to present off a computer other than my own, I can't see myself using much else from this point forward. It has its disadvantages (in that providing supporting material seems a weak spot at the moment) but if I can devote more of my time to the material I'll be talking about, and less on stupid redundancies like browser testing and navigation, I think the good easily outweighs the bad.

Update: Okay, let me elaborate a bit since I'm getting a bit of response, and I (purposely) left comments off. Based on how I create slides (key words), this is what I'd have to do to build a presentation in S5 or PHP:

  • Design slide template.
  • Design individual slides.
  • Convert slide template to HTML.
  • Figure out how to implement my template in S5/PHP.
  • Implement it.
  • Create navigation. (optional in S5)
  • Test in various browsers.

Here's my process in Keynote:

  • Design slide template.
  • Design individual slides.
  • Export.

Considering how much extra time and energy are required by the steps that Keynote eliminates, it's a no-brainer. The disadvantage is yes, I realize the post-presentation materials suffer for it a bit (Keynote's export options aren't great) but with all the time I save I can create a few supplementary options that are equal to or better than an HTML version of the slide show. Clickable URL lists, footnotes, etc. etc., which might be better issued in a single-page format, anyway, rather than strewn throughout a slide show.

Permalink › | no comments

Macromedia No More

December 5

It's done. Adobe has officially acquired Macromedia, and the company is now called... Adobe.

On the one hand, no more lawsuit silliness over tabbed palettes. I'd imagine it'll take a few release cycles, but we'll finally have a consistent interface between some of the most popular design applications.

On the other hand, now we start the deathwatch on all former Macromedia applications that aren't Flash or Dreamweaver. From the looks of the new bundles, there will be some shifting as contents settle, but the direction seems pretty clear. Only the web bundle includes any non-Flash Macromedia applications. You can still buy others stand-alone, but how long will that last?

What I'm particularly curious about is what will happen with their newly acquired web and server technologies. Adobe's never had much of a solution for web development beyond the UI portion. Presumably GoLive will die in favour of Dreamweaver, but ColdFusion and Flex don't have equivalents in Adobe's stable. The obvious implication of a combined PDF/Flash platform sometime in the future means there must be back-end technology to back it up.

Which brings us back to the web. AJAX is hot, but Javascript can't do everything. When faced with its limitations, Flash is currently the most practical alternative. From a business standpoint, it's a no-brainer to develop and promote this emerging/existing platform (in whatever form it may take). So I'd expect to see a lot more effort toward making Flash development easier.

Should be interesting to see how all this impacts Macromedia's attention to standards-based web development. Adobe's made some strides in that direction recently with GoLive's increased emphasis on CSS, but it has always seemed that Macromedia was fundamentally more in tune with the technology and the community.

Permalink › | 102 comments


December 4

Public Service Announcement: if you're planning on going to SXSWi in March, book your hotel now. A bunch of them are already sold out, as I learned the hard way this week. No Hampton Inn for me this year.

Permalink › | 23 comments


December 2

Must be something in the air. I just heard from our publisher that The Zen of CSS Design made both Amazon's Editors' picks and Customers' Favorites lists in Computers & Internet for 2005! A big huge thanks to everyone who bought a copy, this is a great early Christmas present.

Permalink › | no comments


December 2

Right, so I can't possibly write anything about a Dan Cederholm book without appearing to have a bias, so let me tell you right off the bat: yep, I think he's a swell guy, and yep, I got a review copy of his latest book for free.

That being said, I've had Bulletproof Web Design sitting on my desk for a few months now, and I just can't bring myself to stick it back in the bookshelf. It's got a special something that most tech books don't, namely cohesiveness.

The overall package feels like the perfect blending of its summary parts. From the book design to the illustration work, the paper texture to the book dimensions, it all adds up to something most books don't offer: a great experience.

The content's good too, as you might expect. "Bulletproofing" a web site means effectively blending liquid and fixed-width techniques, accounting for alternate browsing scenarios, and generally designing web sites in a web-like manner. You may not find anything new if you've been reading SimpleBits for any length of time, but having all these techniques in book form makes for easier explanation when speaking with clients and other designers.

Permalink › | 13 comments