Serving larger photos to larger monitors?

Some photos don’t work very well online. Close-ups usually are fine. But there just isn’t enough space on most readers’ monitors to do justice to wide-angle shots that cannot feasibly be cropped and pictures of large groups of people. Since so many photos lose necessary detail when run at a (typically) 150-pixel width, many news sites have learned to offer “enlarge” links with higher-resolution photos in popup windows.

Hold that thought for a moment.

The philosophy of “liquid design” argues that Web sites should scale to fit all display sizes. Most news sites, though, lock themselves into fixed layouts about 770 pixels wide, leaving a large empty right margin on my 17" monitor. Pages at Knight Ridder’s Web sites are probably the most prominent exception — text on those sites wraps to fit the width of the browser window, reducing the amount of vertical scrolling for readers with larger monitors.

Now here’s a wacky idea. What if liquid layout didn’t just mean wrapping text into a wider column, but using some of a larger browser window’s extra horizontal space to display larger photos? This idea may not be practical or desirable in practice. It would require building twice as many JPEG files, it might confuse readers, and it would require some JavaScript trickery. But on the other hand, news sites could improve their presentation of photographs for readers with larger monitors without altering the status quo for readers with smaller monitors.

Take a look at this demo page I built — once with a browser window opened to 800x600 resolution (or less) and again with a larger window. Let me know what you think.

Comment by Chris Heisel, posted March 6, 2003, 11:19 am

I really like the idea of photos resizing with the page -- you're right in that for a layout to be liquid, so must the photos.

However, the Javascript thing might get messy -- what happens if the user has JS turned off?

I'd prefer it if all browsers would support percantages for heights and widths of img tags -- that way the picture could easily resize in proportion to the screen.

I'm not a JS person myself, but I imagine you had to set certain cut off points at which the photo would shrink. This could lead to either unpleasing combinations if the window hasn't hit the cut off point or a lot of coding for all the different sizes one could think of.

Comment by Adrian, posted March 6, 2003, 11:52 am

Chris, Nathan has (smartly) put in a NOSCRIPT tag that displays the smaller version of the photo for users without JavaScript.

Nathan, rather than using messy document.write()s, what do you think of changing the SRC of the image as an onload event? That way you could give the image a class or ID and have an external .js file apply the resizing according to a certain filename convention.

It's all about unobtrusive DHTML, my friend. :)

Comment by Nathan Ashby-Kuhlman, posted March 6, 2003, 5:36 pm

Chris, in theory I like your idea of using percentages, but in practice I think photos need to be resized in a photo editing program to discrete dimensions for use on the Web. Otherwise they end up looking “pixelated” pretty easily.

Adrian, I agree that the document.write() method is really messy. In fact, I originally built my demo page with an onload event almost exactly as you recommend.

Here’s the reason I changed my mind: The onload event doesn’t “fire” until after all the images are loaded. So doing this with DHTML would force visitors’ browsers to first download the smaller image, then download the larger image if necessary. That would waste bandwidth, which would be unforgivable over a dialup connection. It would also change the layout of the page after it loaded.

Comment by Julie, posted March 6, 2003, 7:43 pm

Cool idea and I like your implementation of it, but I think I still prefer the traditional 'click to enlarge' method.

The biggest problem as I see it is a practical one -- namely that it doesn't help much with horizontal images (the ones that really tend to lose a lot of detail even at widths of 280px) unless you're going to stretch the image across the entire content well, pushing the story text down below (and as a reader I think I might find it annoying to always be scrolling past images).

There is also the issue of bandwidth. By offering the click-to-enlarge method you allow your low-speed users to decide for themselves whether they care enough about an image to wait for the download of the larger, better quality version.

Comment by Adrian, posted March 6, 2003, 11:00 pm

I see your concern about bandwidth. Good call. The problem-solver in me still wants to do it with an external .js file, though....Hmmm.

I saw something today that reminded me of this discussion. The newly redesigned has a "Photo of the Day" that's resized according to your browser window. It's achieved by making the image a background image using CSS -- hardly a solution for the problem at hand here, but an interesting hack.

Comment by Elaine, posted March 13, 2003, 2:54 pm

You might want to look at what Matt Haughey did with his site redesign - he's got a photo included, but as a background image using CSS, so it fills whatever space is available. (better description on his blog)

maybe that combined with a smaller shot for the non-CSS browsers?

Comment by Thomas, posted March 18, 2003, 11:58 am

liquid design seems a very good idea to me!
the company i'm working for just recently launched a new version of the austrian newspaper kurier's homepage.

we got quite some complains about the fixed width - but we willingly decided to fix the width a quite narrow 666 (no joke) - thus having the chance of positioning a large image on the level of the article display - and still having a comfortable width for reading.

the perfect solution for liquid webdesign will come when scalable vector graphics (svg) finally succeed (perhaps the best thing about flash - you can resize it).

btw - most important is the size of windows (not screens).

POST A COMMENT on “Serving larger photos to larger monitors?”

Your name: (optional)

Your site: (optional)

Comment: (only <a>, <em> and <strong> allowed)

This page last modified on Sunday, January 15, 2006 at 6:57 pm