Robby Macdonell

Uber is pretty rad.

robby — Mon, 15 Aug 2011 02:08:02 +0000

I find the need to take cabs about once or twice a month. I've had a couple not-so-great experiences, but it's generally ok. Certainly nothing I particularly look forward to, though. Last night I splurged and got a ride from Uber, a new towncar service that just launched in Seattle. It ended up being about ten bucks more expensive than a cab, but it was a way better experience. They've done a really nice job of smoothing over a lot of the clunky or awkward aspects of normal car services.

First, I didn't have to call a dispatch, just a one-click "come get me" button on the Android app. I could then see details about the driver that was coming to pick me up. I could also see a map of how far away he was, so I knew right when he'd arrive. He knew my info too, so from the moment I walked out to the car we were on a first-name basis with each other (that's a tiny detail, but it was a nice feeling). The car was really nice and there was free bottled water waiting for us in the back seat. The driver was really friendly and explained to us that once we got to where we were going, we could review the route he took us on to make sure he wasn't trying to boost the fare by driving us the long way. Here's what it looked like:

It was pretty great. The quality of the experience was totally worth the extra cost. Would I use it over a taxi every time? Probably not, but it's nice to have another transportation option for those times when I want to fancy it up a little bit.

Check it out.

Smashvillians.com. A little project I've been working on.

robby — Mon, 07 Feb 2011 08:29:47 +0000

Lately there are a few things I haven't gotten to do quite as much as I'd like:

Design
Code with Ruby
Go to hockey games

In an attempt to deal with all three at once, I've been messing around with building smashvillians.com, a fan-content aggregator for my favorite NHL team, The Nashville Predators. It gave me a chance to dig into Rails 3 (which I've learned that I really like). It's also a fun opportunity to play around, UX-wise, with content aggregation and curation. There's a few concepts in that area that I think are really interesting and I'm looking forward to doing some more stuff with. Also, I get to really nerd out about the Preds, and when I'm done actually have something to show for it.

Reflecting on recruiting.com

robby — Tue, 07 Sep 2010 07:26:16 +0000

Last Friday was my last day at Recruiting.com. Although I'm extremely excited about the new job I'm moving on to, I find myself looking back on the last four years with a lot of fondness. I figured I'd get all nostalgic and reflect for a bit. It was a fantastic experience that I've grown tremendously from.

I met the most awesome people:

So many amazing people have cycled through that place during my time there. My mind was constantly being blown by how much talent I was sitting right in the middle of. It was a fantastic learning experience. Whenever I talk to other people in the Seattle tech scene, they all bring up how many smart people that place churned out. Hopefully I don't bring the reputation down too much!

In addition to being smart and amazingly talented, a lot of them were just plain awesome. I have some amazing friendships with ex-Jobster's. One of them even introduced me to my girlfriend who I just got engaged to, so the whole experience was worth it just for that alone.

I learned what a start-up feels like, for better or worse:

Three weeks after Jobster hired me (and moved me out to Seattle from Boston) we laid off 70 people. That blew my mind, and made me wonder what I had gotten myself into. I saw scrambling business models, pressure from VCs, more layoffs, bad press, worse press, god-awful press, and a slow steady attrition by the survivors of layoffs.

I also saw people who believed so much in what they were doing and loved coming to work because of the impact they felt they could make. I saw a culture where it was expected that you'd question everything and challenge your assumptions constantly. It was somehow pulled off in a way where pretty much everyone grew from it. We learned what worked, and what didn't. More importantly, I learned that it was possible to do something about it when things weren't working. I had multiple "holy shit!" moments where we realized we had just stumbled onto something awesome in a way that no one else had thought of, and we could build things, and they'd solve people's problems in a real, meaningful way.

I built something I was proud of, and learned how to do it in a WAY I was proud of:

Things floundered for a while the first couple years that I was there, but in the last 18 months, we really nailed down a strong opinion about what we were there to do for people. We had a really clear objective and we stuck to it, even when it wasn't easy to do so. We had lots of really passionate arguments about whether this feature or that feature complimented or distracted from the core vision. We watched things that we built and felt really good about completely fail in user-studies, but we learned to do it quickly enough that it ended up becoming a good thing when it happened. I learned how to get deeper into the heads of people that I was trying to help (something that was particularly hard for me since I had never met a recruiter in my life before starting there). The deeper I got into it, the more exciting it became.

I learned that I really like doing this shit, after all

Building software is fun. I thought it would be at first, but I wasn't so sure about it during the first couple years out here. I thought maybe I had an idealized vision of it that was really far from reality. It sounded good on paper, but I got to thinking that maybe it's all just a lot of hard work that ultimately leaves you spending years on a single product that you weren't all that passionate about to begin with. I'm glad it all came full-circle. It could've EASILY ended up different.

Anyone who's at all familiar with the Jobster saga knows that a lot of craziness went down over the years. But now that it's all behind me, none of that stuff really matters. It makes for some amusing memories, but what's really important to me is that I got to work with awesome people, build something awesome, and do it in a way that I feel really good about. I even made a few recruiters' lives a teeny bit better in the process. :) I have a much better sense of myself and what I find fulfilling as a result of it, and I can't wait to take the things I've learned to the next level.

Successful infographic: World Cup matches by Michael Deal

robby — Tue, 06 Jul 2010 17:31:54 +0000

I feel like there are WAY too many infographics that fall down because they pack way too much data into the presentation. The ones that succeed tend to pick a single data-point (or a very small set of related data points), and use it to illustrate a single concept. It's so tempting to try to show off everything you learned from the data-set, but it can also get overwhelming, really quick. It's an easy trap to fall into, especially for the infographic designer that probably enjoys getting completely lost in data.

Over the weekend, I came across this visualization by designer Michael Deal, which I think is fantastic. He explores the matches in the World Cup by visualizing passes, shots on goal, and goals scored across an entire game. It's a lot of information, but it's insanely digestible. I'm an utter noob when it comes to soccer, and I'm kind of frustrated that I don't have my head wrapped around the game enough to enjoy watching it. But by spending just a couple minutes with this visualization, I can see a picture of the games that not only makes sense to me, it makes me want to learn more.

For example: (click the images for the full infographic)

This must have been a really frustrating game for Spain. They dominated on passes and shots for the entire game, but Switzerland ended up taking the match.

This shows how Italy was dominant in the game in a way that the 1-1 tie doesn't illustrate.

Michael has some other awesome infographics on his site.

Tony Hsieh from Zappos has SPIES EVERYWHERE!!!

robby — Fri, 02 Jul 2010 18:20:18 +0000

Ok, maybe they're not spies, maybe he has an army of fantastic little elves, or ninjas. happiness ninjas. Regardless of how he did it, Tony from @zappos made my day yesterday, in a way that completely fits into his personal narrative of 'Delivering Happiness'. The thing is, there's no way he could have possibly done it on purpose.

I'll explain:

I'm currently right in the middle of trying to make some pretty heavy life-decisions. I'm at a bit of a crossroads, both personally and professionally, and I'm trying to figure out what's next.

Do I move, or stay in Seattle?
What kind of work situation would I enjoy the most?
Do I take some time off work, or do I dive right in to something new? (there's a fair bit of opportunity out there for UX designers at the moment)
What kinds of changes will make me the happiest? How do I start to figure out what that even means?

So many questions! I was a kinda frozen, with no clue where to start, and it was really starting to stress me out.

So bad, in fact, that I ended up with a migraine yesterday. The way my migraines work, the headache is annoying, but it's not that bad. The part that really gets me is that I go FREAKIN' BLIND for about 30-45 minutes. Then I get my sight back and I have a kinda nasty headache for the rest of the day. (Silver lining, It's a fantastic way of making me take a break from whatever I'm doing that's stressed me out in the first place.)

Anyways, I bailed out of work early to go sleep it off. I half-blindedly stumbled home, and as I'm walking in the front-door, I literally trip over a copy of Tony Hsieh's book, Delivering Happiness. I had requested a copy 2 months ago in response to this tweet, and kinda felt bad about it afterwords, because I figured I probably wasn't going to like it that much. If he's gonna be giving them away to anyone, it should probably be to people that are psyched about it. See, I'm not a big fan of "business-y" books. I find the vast majority of them to be fairly smarmy. But, I had seen Tony Hsieh speak at SXSW a couple years ago, and he was pretty entertaining. Plus, when I saw that tweet, it was a really slow day at work, and what else was I gonna do?

It ended up being the best possible timing for a book delivery in history.

It's pretty hilarious that a book about happiness in the professional context shows up on my door at the exact moment that I'm thinking about it so much that it's making my brain hurt. I figured I could use something to take my mind off things, I started flipping through it. I figured it's the least I could do for a guy who sent me a copy of his book that I didn't pay for, and only sorta, half-heartedly, asked for.

Fast forward 24 hours later, and I've read it cover-to-cover.

Well, mostly. I ended up skimming a little bit in the middle. (Sorry, Tony. There's only so much of a big company's core-values document that I can take at 1am, given my general aversion to big companies.) But it was pretty good, as far as those type of books go. I feel like way too many business / personal development books are written from a slant of "follow your passion and profit Profit PROFIT!!!", and that just feels sorta gross to me. Delivering Happiness, on the other hand, seems to come from a much more personal place. Tony Hsieh seems like a guy who, while obviously very financially-successful, is more psyched because he learned along the way that there are, in fact, much more meaningful things than money, and he just wants to share.

Also, I really appreciate that he spends two pages breaking down his loving relationship with Red Bull, and that he thinks pickles make him happy because "they are obviously delicious and I enjoy saying 'Pickles'."

I'll spare the book report, other than to say I got a lot out of it. You should check it out, if that sort of thing sounds at all interesting to you. The main point of this post is that it was EXACTLY what I needed at that point in time. I totally got lost in it, and that got my mind off all the hemming and hawing I was doing that wasn't helping anyway. It also gave me some nuggets to think about that help put some stuff in perspective. And, dude is just a pretty good storyteller. You can tell he's stoked to be talking about the stuff that he does (something I noticed when I saw him at the SXSW 09 keynote, too).

So, Tony, however you did it, be it by pure serendipity (most likely what happened), or some skynet-esque computer that monitors the entire world's tweets and foursquare checkins (what I'd like to think happened), you nailed the timing on that one.

Good job, sir.

Man vs. Food: A ridiculous visualization for a ridiculous tv show

robby — Sat, 19 Jun 2010 01:32:37 +0000

Here's another HTML5 exploration. This time, it's the Travel Channel show Man vs. Food.

I shouldn't like this show as much as I do, but I can't help it.

Here's the data-driven look at the first two seasons, click the image for the full infographic. (Sorry IE users, this one is Firefox / Chrome / Safari only)

Commands in TextMate are awesome.

robby — Thu, 17 Jun 2010 20:59:53 +0000

I've used Textmate to write code for the past year or so. I always thought it was a fantastic editor, but I stumbled on something new (to me) about it the other day that makes me like it 1000 times more. You can write commands to automate tedious tasks in Textmate, and you can do it in just about ANY language that you already know. For me, that's Ruby. Writing commands with it is super easy.

Lately, as I've been doing more CSS3 stuff, I've gotten more and more frustrated by having to type all the browser-specific extensions for properties that haven't been quite finalized yet. It's annoying, and I'll inevitably start leaving stuff out because I don't want to mess with it (Sorry, Opera). But once I figured out that I could write commands in Ruby, I was able to whip this up in just a couple minutes:

#!/usr/bin/env ruby
s = STDIN.read

s.gsub!(/([[:blank:]]*)border-radius: (\d+px);/) do 
  "#{$1}border-radius: #{$2};\n#{$1}-moz-border-radius: #{$2};\n#{$1}-webkit-border-radius: #{$2};\n"
end

s.gsub!(/([[:blank:]]*)box-shadow: (\d.+);/) do
  "#{$1}box-shadow: #{$2};\n#{$1}-webkit-box-shadow: #{$2};\n#{$1}-moz-box-shadow: #{$2};\n"
end

s.gsub!(/([[:blank:]]*)transition: (\S.+);/) do
  "#{$1}transition: #{$2};\n#{$1}-webkit-transition: #{$2};\n#{$1}-moz-transition: #{$2};\n#{$1}-o-transition: #{$2};\n"
end

print s

Then I saved it as a command (Menu > Bundles > Bundle Editor > Edit Commands), and set the input to "Selected Text" or "Line", so I wouldn't accidentally run the command over and over again on different parts of the document.

It's nothing crazy, but it makes my day WAY easier. Now I can just type the non-browser-specific CSS declarations, then run the command (from the Bundles menu), and all the CSS declarations I've selected get expanded out to their browser-specific versions. For example:

#foo {
  border-radius: 5px;
  box-shadow: 2px 2px 4px #ccc;
  transition: width 0.3s linear;
}

becomes:

#foo {
  border-radius: 5px;
  -moz-border-radius: 5px;
  -webkit-border-radius: 5px;

  box-shadow: 2px 2px 4px #ccc;
  -webkit-box-shadow: 2px 2px 4px #ccc;
  -moz-box-shadow: 2px 2px 4px #ccc;

  transition: width 0.3s linear;
  -webkit-transition: width 0.3s linear;
  -moz-transition: width 0.3s linear;
  -o-transition: width 0.3s linear;

}

It's pretty rad. I wish I had known about that earlier. I'll probably expand on it as needed, but these three rules are already saving me a lot of time. For example, figuring out an easy way to do CSS gradients would be cool, but seems like it'd be an really ugly regular expression.

Visualizing Lord Stanley's Cup: an HTML5 experiment.

robby — Sun, 06 Jun 2010 07:52:23 +0000

Here's a little something I whipped up over the past week. It's an interactive visualization of the winners and losers of the Stanley Cup finals since 1927. I was trying to accomplish two things: 1. learn how to use some new stuff in HTML5 (canvas, css transistions, etc), and 2. teach myself a little bit about hockey. I'm pretty psyched at how it turned out.

Click here to see it.

By the way, Internet Explorer completely barfs on this, so it's really only worth looking at if you're using Chrome, Safari, or Firefox.

How I did it

1. Start with simple HTML markup.

It seemed like the right way to start was to put all the data into something simple that would display fine on it's own, in any browser, then transform it into something more interesting with javascript and css. I came up with a simple HTML structure that showed the wins and losses for each team, and allowed for some notes for context.

<section id="sc-timeline">
  <ul id="timeline-data">
    <li id="calgary">
      <h3 class="team-name">Calgary Flames</h3>
      <div class="timeline">
        <h4>Stanley Cup Wins:</h4>
        <span class="win" title="1989/05/30">1989</span>,
           
        <h4>Stanley Cup Losses:</h4>
        <span class="lose" title="1986/05/30">1986</span>,
        <span class="lose" title="2004/05/30">2004</span>
           
        <h4>Notes:</h4>
        <span class="note" title="1972/10/01">Founded in 1972</span>
      </div>
    </li>
  </ul>
</section>

... then repeat the list-items for each team in the data set.

2. Build a timeline with Javascript.

Now that the raw data is on the page, I need to add some stuff to it so it will actually be interesting. I stored all the javascript to control the visualization in an class called 'timeline'

var timeline = function() {
  this.init = function(el) { ... setup stuff goes here ... }
  ... more logic goes here ...
}

Then I created an instance of the class, and run an initialize function that adds in the extra HTML we need for the visualization.

var sc_timeline = new timeline();
sc_timeline.init($('SECTION#sc-timeline'));

Rather than paste in all the code here, which would be overwhelming, have a look at the source.

In the init function, three bits of extra markup are added to the existing html, so the structure now looks like this:

<section style="width: 1010px;">
  <ul id="timeline-data">
    <li>...</li>
  </ul>

  <!-- this stuff below is added by the timeline.init() function. -->
  <canvas class="timeline-canvas" height="270" width="1010">
  <ul class="timeline-bar">
    <li>1927</li>
    <li>1928</li>
    ... etc.
  </ul>
  <div class="timeline-titles"></div>
  <div class="timeline-notes"></div>
<section>

All of that is super easy with jQuery.

3. Add some CSS

Now, all the markup is there, but it's pretty ugly. In a CSS file, I floated all the list items so they displayed horizontally, hid the raw data (wins, losses, notes), positioned the new timeline-title and timeline-notes DIVs on top of the CANVAS element, and added team logos to each LI in the timeline-data list (using the team_logo_nav.jpg sprite)

check out the css file.

It's all really straightforward CSS, but there's one thing I want to point out. When you hover over the team logo, I used a CSS transition to give some animation to the background position. It's the first time I've ever used that, and I like it a lot. I can imagine some really cool stuff that can be done with it. (too bad it only works in Safari and Chrome, currently)

-webkit-transition: background-position 0.3s linear;

4. Add interactivity

There are two bits of interactivity I want on this thing. First, you should be able to mouse over the team logos and display the years they were in the finals, along with any notes. Second, and inversely, you should be able to mouse over the years in the timeline and see which teams played on any given year.

In the timeline setup, I attach the actions to the list items:

this.setup_timeline_actions = function() {
  public_instance = this.public_instance; // this is a reference to this instance that we can attach to HTML elements that need to refer back to it.
  this.teams.find('LI').hover(function() {
    public_instance.draw_timeline_links(this);
  });
  this.years.find('LI').hover(function() {
    public_instance.draw_matchup(this);
  });
}

I won't go through the ins and outs of how I did the highlighting of the corresponding list items. It's basically finding the matching years or teams by filtering the list for an ID or title attribute, then adding a 'selected' class to them and writing the team name to the timeline-titles DIV element.

Oh, and then I got to the fun part...

5. Drawing with CANVAS.

I think the most interesting part of the visualization is the bars that link the teams to their win or loss years. I did it with the HTML5 CANVAS element, which is basically a scriptable image tag that you draw on programmatically. It's not difficult, but it's way different than basic DOM scripting like I'm used to.

To make it work the way I wanted, I sized the canvas to be exactly as wide as the list items. Then I could easily to draw links between the two rows, just by finding how far the corresponding elements were from the left edge.

this.draw_connection = function(team,year,color) {
  // this.ctx() is a reference to the context object of the canvas. 
  this.ctx().globalAlpha = 0.2;  
  this.ctx().fillStyle = color;

  // get the coordinates
  var l1 = team.position().left;
  var l2 = year.position().left
  var r1 = l1 + team.width();
  var r2 = year.width() + year.position().left;
  var h = $(this.stage.canvas).height();

  // draw the connection
  this.ctx().beginPath();
  this.ctx().moveTo(l1,0);
  this.ctx().lineTo(r1,0);
  this.ctx().lineTo(r2,h);  
  this.ctx().lineTo(l2,h);
  this.ctx().fill();
}

When I loop through all the teams and draw their connections, with blue bars for wins, and red bars for losses, it creates a pretty neat effect:

Drawing notes is pretty simlar, I drew a line on the canvas, then positioned the note text on top of it, left-aligned to the line:

var year_pos = this.stage.years.find('LI#y' + year).position().left;
var h = $(this.stage.canvas).height();
this.ctx().strokeStyle = '#00ff00';
this.ctx().globalAlpha = 1;
this.ctx().beginPath();
this.ctx().moveTo(year_pos, 0);
this.ctx().lineTo(year_pos,h);
this.ctx().stroke();
this.stage.notes.append(''+ note.note + '');

Creating a note layout that looks like:

From there, it's just a matter of clearing the canvas whenever a year or team is hovered, then drawing the connections all over again, but just with the selected year.

Again, here's the finished product. View the source to see the details of the javascript.

Learn more about working with the CANVAS tag.

Learn more about CSS transitions.

Update: The guys at FanSnap had me build a timeline for the NBA finals. I made some design refinements with this one and made it work in IE. By "made it work in IE", I mean "made myself feel really dirty while making it look only halfway-passable in IE".

Infographic: Epic US Floods in the last 100 years, Damages and Casualties

robby — Sat, 22 May 2010 07:02:23 +0000

I've been thinking about floods a lot lately. A few weeks ago my hometown, Nashville, TN was hit with the worst flooding it's had in at least 80 years. Seeing all the images of the damage was pretty mind-blowing. I'm still having a hard time wrapping my head around the extent of it all.

To make at least a little sense of it, I started diving into as much of the raw data as I could find. In the process, I realized a sad truth about floods. It's really easy to underestimate how big of a deal they are, provided they don't happen near to a place you have a particular attachment to. In the past decade, there have been a few floods that were at least as destructive as the Tennessee floods, but I don't really remember them. Or, I do remember them, but didn't think they were that big of a deal. Just a whole lot of rain. Add that to the fact that the Tennessee floods went down on a weekend where there was an environmental crisis, and a failed terrorist attack in NYC, and it's easy to see how the severity of the situation was lost on a lot of people outside of the South.

Here's an infographic I pulled together exploring the damages and lives lost in several of the largest floods over the past 100 years. Click through for a larger version.

And please, if you're feeling at all generous, there's a lot of folks in Nashville that could use a hand. Consider making a donation, buying something, or if you're in the area, take a little time to help out. Thanks.

(sorta) Practical CSS sprites for high-traffic sites:

robby — Mon, 10 May 2010 06:57:35 +0000

This past week, I learned about how google is starting to take server speed into account in their search result rankings.

It reminded me of some work I did a year or so ago when I was a front-end developer for Jobster.com. We were getting just shy of a million unique visitors / month at the time, and our servers were starting to strain under the load. We solved some pretty big performance problems by reducing 50+ image requests on each page to just 2 using CSS sprites. Here's some of the stuff I learned during that process.

Disclaimer: In most situations, bending over backwards to get everything into a single sprite is overkill, and I don't really recommend it unless you're suffering from high-traffic performance problems. If you find yourself in that spot, however, it can make a huge difference.

First off, look at these two pages, for a fictitious online candy retailer called BaddassSnacks! They should look identical. The only differences are under the hood. I noted some details about the assets used in each page.

Demo #1

Demo #2

Total image files: 24

Total image files: 1

click here to see sprite.gif

Getting all of these images to work with a single CSS sprite was a bit of a challenge. Here's a few of the techniques I used to make it all work:

1. Replacing a block of text with an image:

This is one of the most straightforward things to do with CSS sprites. Just make sure the text is contained in a block-level element and set the height and width of the element to the same as the image. Of course, you'll need to hide the text too, here's how to do it.

/* page logo, for example */
H1#logo A {
  display: block;
  height: 100px;
  width: 175px;
  text-indent: -9000px;
  outline: none;
  /* set the background to your sprite, then move the sprite into position
     in this case, 25px from the left and 50px from the top */
  background: url(/path/to/your/sprite) -25px -50px no-repeat;
}

This can turn into a lot of CSS if you're doing this with a lot of images. You can clean this up a bit by creating a single class that you can apply to any text-containing element that you want to turn into an image. I usually call this class ".img" or something similar.

.img {
  display: block;
  text-indent: -9000px;
  outline: none;
  background: url(/path/to/your/sprite);
  background-repeat: no-repeat;
}

H1#logo A.img {
  height: 100px;
  width: 175px;
  background-position: -25px -50px;
}

here's an example from the demo page:

2. long, tiling backgrounds

If you need an image to tile horizontally AND vertically, you're out of luck when it comes to sprites.
But if you can live with only tiling images horizontally, then you just make a REALLY tall sprite with all your horizontally-tiling images, then use background-position to line them up to the right point.

Again, an example:

3. Backgrounds for elements with a variable width

This is really similar to #2
You can use the sliding doors technique with CSS sprites, you just need to make sure that your sprite is as wide as your widest variable-width element is likely to be.

4. Bullet icons

This is where things start to get a little bit tricky when you're using sprites, and it's difficult to come up with something that's bulletproof. The problem is, in a nutshell, that you want to make use of individual icons, but because they're on the sprite, the neighbors of the image you want will show through unless you've positioned them just so. In this example, I just made the image really tall and gave everything a lot of padding. I've found that increasing the dimensions of the image doesn't increase the file size proportionally, so you can get away with it and still achieve a smaller total file size.

5. Inline images

These seem tricky, but are actually quite easy, so long as you're willing to put up with one teeny bit of ugliness in your code. The obvious problem is that inline elements can't reliably get a height and a width in all browsers. You need something that will act like an IMG element. As it turns out, that's what you use. But, we want to keep our images all in the sprite, so how do we do it? There are two ways. First, and easiest, accept the extra server hit and serve your inline images as a 1x1px transparent gif.

<img src="/images/invisible.gif"  />

Then use css to set the height and width of the image and use your sprite the same way as you would with any block-level element. That's what we did on Jobster.com, and it worked fine. The second way is uglier, but will keep you from using a second image. The SRC attribute of the IMG tag usually takes a url to an image file, but you can also put raw image data in there. This will give you an image that's the equivalent of the 1x1px transparent gif:

<img src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw=="  />

Did I mention it's ugly? In either case, you can then use CSS to position the sprite like so:

IMG#whatever_id_you_give_to_the_inline_image {
  height: 15px;
  width: 45px;
  background: url(/path/to/your/css/sprite) no-repeat -50px -65px
}

And that's basically it. For a real-world example of most of these techniques, check out the search results pages on Jobster.com (although I don't work on that site anymore so no guarantees that things haven't changed in the meantime)