Preload your CSS Images
Here’s something I come across occasionally that I find rather annoying.
You’re browsing around the web at 2am, searching for the perfect gift for that special someone. You mouse over the tab navigation and.. WTF… the tab completely disappears for a second. After another round-trip to the server, the on-hover image for the tab finally loads displays as it was intended.
Sometimes this isn’t a big deal, since it’s only a 200ms round-trip to the server for a tiny image, but occasionally on a high-traffic server, or a site that has quite a bit of latency, it creates a noticeable eyesore, and to me, it seems flat out lazy when there’s easy ways of avoiding it, such as:
1. Image Sprites
Sprites are becoming more and more common these days. The basic idea of an image sprite is that you combine many small images into a single large image and use CSS to manipulate the position of the image so only the desired section shows up where needed. For example, to get the hover state image for the undo icon, they would have to set the background-position to -200px -40px (200px from the left, 40px from the top of the image sprite).
Instead of the client having to download 7 icons that display on a page, the use of a sprite collapses 7 HTTP GET requests into a single request, albeit one that takes slightly longer due to the large image size. Take a look at the sprite as it’s used in the Stack Overflow Markdown editor.
With a bit of context, you can see that the 3 rows represent the regular, disabled, and hover states, respectively from top to bottom, for each icon. They’ve reduced 39 requests to a single 4Kb byte request. This saves a substantial amount of time in setting up and tearing down TCP connections, and it’s fewer hits for your webserver to service, so everybody wins. There are some good sprite generators around the web, which takes almost all of the hard work out of the equation for you.
2. Preload page images with JavaScript
This one is not quite as elegant, but it’s still used quite a bit, and can be a reasonable solution to a one-off problem.
When I had to build an online portfolio for my Technical Writing class at MSUM, I was required to add links to three tools that I use on a regular basis. I wanted to dazzle a bit, so I took screenshots of the three sites I chose, and used LightBox to load larger, high-quality screenshots.
Logically, the user is going to scan the first paragraph, then move to the first section and start scanning. My guess was at that point, they’d be bored and would click on the image to see a larger version. But in the meantime, enough time has probably elapsed to have downloaded all 3 high-quality versions, so why not make the browser download them in the meantime? Easy.
var imgs = ["images/kuler_large.jpg", "images/reddit_large.jpg", "images/mdc_large.jpg", "images/wikimedia_large.jpg"];
for (i in imgs){
var newimg = new Image();
newimg.src = imgs[i];
}
3. Make jQuery do everything for you
jQuery is a wonderful library. It’s made even more wonderful by the vast number of extensions, one of which is is the CSS Image Preloader, written by the JavaScript masters at the Filament Group.
What’s cool about this approach is that it’s a great balance between the other two: It’s simple, only requiring two javascript files (jquery core and the plugin) and a couple lines of code, but unlike the manual method of typing filenames, this plugin automatically parses linked and imported stylesheets. So if you change image urls, or add or remove images from a page, the plugin does the tough work for you. No need to update anything else. They have a great demo set up over at their website as well.
$(document).ready(function(){
$.preloadCssImages();
});
Ultimately, the ‘right’ approach depends on what your individual needs are. I can see applications and arguments for and against all three of these examples. The first is pure CSS, which is always a plus in my book, but it also requires that you decide on a good way to organize your related images into sprites. The latter two both require JavaScript, which is almost always fine these days, but some people prefer to browse with it turned off, and it’s up to us developers to make sure that their experience isn’t hindered (much) because they chose to not trust our scripts.
Simple, Repeatable, Powerful
In software, simple is better.
As developers, we spend much more time trying to understand code than we do writing it. It’s going to be a lot easier for your collegues to understand what you meant by a method nameddoesUserExist() than everybodyWangChungTonight().
Tracking down obscure bugs is insanely frustrating. It’s even more frustrating when you have to struggle to grasp a shred of meaning from the code that is supposedly buggy. Imagine what your college professors must have gone through.
Dr. Brekke: I’m sorry I picked random animal names for variable names on that assignment. It was late and OperationHerdCats() seemed hilarious at the time.
There. That feels better.
Similarly, if you have to jump through an arbitrary number of hoops to perform some action at work, be it kick off an integration build, generate a report, or make a new pot of coffee, it’s going to be hard to talk anyone in to taking over or sharing in those duties.
I’ve been gradually working my way though The Pragmatic Programmer over the last few weeks. Some things are old hat (thanks Dr. Walker), while others are less obvious, but insanely practical. One of the ideas was that everything you do should be easily reproducible with simple steps. This falls right in line with #2 of The Joel Test.
The Power of Simple.
In building the template that this blog used to use, I ran into a few minor hiccups. I’m currently hosting the site on GoDaddy shared hosting, so I’m limited to using FTP for transferring files. That, by itself, is not a huge deal. I’d prefer rsync, but I can make do.
While chatting with a friend one night, I mentioned that I’d just updated a bunch of stylesheet rules. He replied that it looked the same as it did the previous week, which was odd since I had made several minor updates since then. It turned out to be a simple CSS caching error, caused by me forgetting to update the version number following the script HREF in the HTML. Previously, the link looked like this in the template:
<link rel="stylesheet" type="text/css" href="<?php bloginfo('stylesheet_url'); ?>?4815162342 />
In this example, 4815162342 is just an arbitrary number that gets incremented to trick the browser into thinking the file might have changed by using a simple GET request. It’s a simple way to let the browser cache the stylesheet, but still force it to get a new one whenever necessary by simply changing the number. Rails does something similar, but it appends the last-modified timestamp of the external CSS or JavaScript file in place of the arbitrary numbers I’ve used.
I thought for a little while, but then I realized that what I really wanted needed was a 1-click (err, command) Build Process that did the following:
- Create a dist directory to allow for an uncontaminated base point for a release
- Copy all of the image files to the dist directory (I really need to get ambitious and make some sprites)
- Copy all of the relevant PHP files to the dist directory
- Minify the external CSS and JavaScript files and put them in the new directory
- Update my arbitrary number in the header.php file so I don’t have to ever think about it again.
Using Ant, this ended up being a simple, yet valuable introduction to the Java Build world. The only thing I really needed to sub out was to a really trivial shell script on my desktop that took care of the minification using the YUI Compressor. My build process went from actually more steps than what I laid out before to the following:
- ant deploy
Even my SO could handle that. Simple. Repeatable. Powerful.
Visualizing Data
I love data visualizations.
Raw data can tell you a lot by itself, but putting that data through a process that creates a visual context is a great way to make people fanatical about your software. For example, I’m absolutely addicted to checking my Flickr stats.
It’s strangely fascinating to log in day after day and see how many people took the time to flip through my photos when I don’t spend an iota of time trying to drive traffic there. While I don’t get a large amount of traffic, it’s exciting to try to draw conclusions based on the view stats.
Charts and graphs can make tedious or otherwise boring information seem downright exciting. Take Zipdecode, for example. Zip codes are not very interesting. However, slap them into a Processing app and suddenly people are interested enough to spend some time figuring out how zip codes work. In fact, I’m willing to bet that the Zipdecode example is powerful enough that you can learn more about zip codes in 30 seconds than you’ve learned in the rest of your time scrawling them on envelopes.
Twitter is another interesting point of study pertaining to what data conveys about an individual. Enter Twitter Stats: a Perl script that chews on some data from Twitter’s API and spits back some slick graphs that go beyond the traditional Twitter context of, “What are you doing?”
What does this say about me? I’m more of a night owl than an early bird. Wednesday morning I’m more active than any other morning, and for quite a span of time. I’m also more apt to post on Wednesday than any other day with Saturday seeing the least activity of all (I try to stay unplugged on weekends to some extent). Overall? Yeah, it’s pretty accurate.
But it doesn’t end there.
I was late to jump on the Google Reader bandwagon. Ok I just started last week. They have graphs too!
According to Google, I don’t read shit in the morning.
When I worked for the IT department at MSUM, we used Cacti to track the basic server vitals: memory consumption, processor utilization, spam statistics, that sort of thing. Of course, it’s useful to see some quick stats from SpamAssasin on the command line, but what’s truly useful is being able to see what changes over time.
Take the WebOps Visualization photo pool, started by some of the Flickr server admins. Flickr handles an insane amount of data every day. It’s wildly fascinating to see what other organizations are doing with their mundane data.
And it begins…
I couldn’t think of a clever title for the re-launch of the site, but suffice it to say that the crappy WordPress template is gone, replaced by a slightly less crappy template of my own design. The header image was taken by a friend of mine, and is a shot of the sunset over the Izembek Lagoon [map]. Alaska is truly a unique place, and I can’t recommend strongly enough that people visit there someday, should they get the chance.
That said, the style of the blog doesn’t really have a whole lot of meaning to convey (graphic designers everywhere just felt a disturbance in the Force). I intend, over the next several months, to write a series of articles about developing software: both things that are well-defined, as well as processes that are lacking. My experience in some areas may be a bit scarce, but undoubtedly writing about something is a fantastic way to learn, and as software developers, if we’re not constantly learning, we’re gradually becoming obsolete.
I’ll close with a note about the blog title: Fractions of a Penny. It’s an allusion to the cult classic, Office Space. One of the characters, Michael Bolton, a scrawny Software Engineer commits a fatal mistake, and in a moment of utter regret, offers the following:
Ok! Ok! I must have, I must have put a decimal point in the wrong place
or something. Shit. I always do that. I always mess up some mundane
detail.
That single quote sums up so much about software development today, 10 years later! It’s to that end that I hope to use this blog as a sort of mental unloading place to keep some of the more valuable things I learn about design, architecture, testing, and deployment.
Stay tuned.