The Brewing Process: Part 4 – The Gallery

posted on November 26th, 2007 by Anthony

This is part four of the story of the redesign. If you’re coming late to the party then here are the bits that you’ve missed so far:

In the last part I finished by going through some of the plugins I used to make the various bits of the site work. As great as the plugins are, some of them needed a little bit of coaxing to work exactly as I wanted…

The Gallery

A Flickr feed was a late addition to my previous design. Photography is something both Claire (the lovely Missus) and myself are looking to take a bit more seriously (we’re getting a 400D for Christmas) so I felt it was important that this design incorporated the feed again.

In the Frame

As mentioned in the previous Brewing Process post I used flickrRSS to do the fetching of the piccies. It’s a great little no fuss plugin that has a pretty powerful templating system out of the box. In my previous design I pretty much used it as-is and I was pretty happy.

As you can see the finished product in this design isn’t anywhere near a standard look.

First came the flock wallpaper footer – it’s a traditional look for a pub and it fits the Brewery theme quite nicely. Obviously, with a wall, you also need something to hang on it. Another staple of the traditional British pub look is an ‘eclectic’ selection of dusty ‘antique’ picture frames filled with ‘Olde Worlde’ photos.

So I hit up Ebay (again) and scoured the listings for ornate picture frames. God Bless peoples junk…

The naked frames

What you see above is the frames I actually used – naked of all effects and processing. Each one was taken from an Ebay listing, resized and rejigged to make them square an thus able to easily accommodate a Flickr thumbnail.

For the Fireworks mockup I produced five frames, with five randomly selected photos from my Flickr stream.

It looked good.

Obviously I had no idea how to make it all work like I wanted in code… but it looked good.

8bit Forever

When it came to the ‘making it work’ part the first thing I was worried about was transparency. The frames need a semi-transparent drop-shadow to look right and, because they are on patterned background, a simple GIF transparency wasn’t going to be able to pull it off.

Using an alpha transparent PNG is the obvious way to go but, as you know, IE6 can get a little bit squeamish around such things – generally it vomits a nasty grey block all over the areas that should be transparent…

Fortunately, I’ve had a little experience with this problem (see the header graphic). So I used an PNG with alpha-transparency anyway.

The difference in PNG aplha transparency rendering between Firefox and IE6

As you can see IE has not evacuated it’s grey guts over the frames! In fact there’s nothing at all, it’s just completely ignored all of the alpha bit and not rendered them! It’s not perfect but it looks good enough to mean not having to add extra lines of CSS to serve IE6 an alternative image.

What voodoo magic did I use?

Nothing special, I simply used 8bit PNGs.

That’s it.

It’s a bit of a misconception that IE can’t handle PNGs – it can – it’s the 32bit ones that makes IE6 spew. It can just about stomach 8bit ones, so long as it doesn’t bother with the see through bits! OK 8bit ones aren’t as spiffy as the full 32bit versions – you get the same maximum 256 colours as a GIF for a start. They also won’t be a suitable choice for all situations.

However, for small icons and graphics, like my frames, 8bit is definitely the way to go.

You generally get smaller file sizes than GIF, neater outlines, wide browser support, and semi-transparency on the alpha channel. Lovely.

Coding

Now I had worked out the best image format I needed to make it work all web standardsy in code.

I need the frame to actually ‘hold’ photographs so it was obviously going to need a bit of layering. It was a very straight forward to have the frame as a background image. With there being five images I thought it best, from a semantic point of view, to use an unordered list to act as the virtual frames for each <img>.

So the basic code looks something like this:


<div id="flickr">

  <ul>
    <li class="frame"><img src="blah.jpg" /></li>
  </ul>

</div id="flickr">

with the CSS looking like this:


#flickr li.frame {
	background: url(images/frame.png) no-repeat top;
	height: 97px;
	width: 95px;
}

#flickr li.frame img {
	width: 69px;
	height: 69px;
	position: relative;
	top: 12px;
	left: 13px;
}

That works nicely for one single photograph and frame. That’s nice and all, but to get the effect of a random gallery things need to be moved on a little.

Spacing Out

Adding other frames isn’t particularly a problem if you want them in a single file vertical line.

When confined in a list you have to add quite a bot of extra CSS to make things work. First here’s the HTML framework (obviously this isn’t the exact code, it’s simplified – no alt attribute, etc – just ‘View Source’ to see it all!):


<div id="flickr">

  <ul>
    <li class="frame0"><img src="image1.jpg" /></li>
    <li class="frame1"><img src="image2.jpg" /></li>
    <li class="frame2"><img src="image3.jpg" /></li>
    <li class="frame3"><img src="image4.jpg" /></li>
    <li class="frame4"><img src="image5.jpg" /></li>
  </ul>

</div>

You’ll notice the class names of each list item follow a sequence of 0-4. I’d say I knew to do this from the start, but I’d be lying. It’s done like this to allow me to assign a unique class to each list item via the FlickrRSS plugin, but more on that later…

To that framework this sort of CSS was attached to allow the positioning of each frame.


#flickr li.frame0 {
	background: url(frame1.png) no-repeat top;
	height: 148px;
	width: 129px;
	position: relative;
	left: 60px;
}

#flickr li.frame0 img {
	width: 72px;
	height: 72px;
	position: relative;
	top: 48px;
	left: 29px;
}

#flickr li a img {
	border: none;
}

#flickr li.frame1 {
	background: url(frame2.png) no-repeat top;
	height: 97px;
	width: 95px;
	position: relative;
	margin-top: -140px;
	left: 220px;
}

#flickr li.frame1 img {
	width: 69px;
	height: 69px;
	position: relative;
	top: 12px;
	left: 13px;
}

#flickr li.frame2 {
	background: url(frame3.png) no-repeat top;
	height: 111px;
	width: 119px;
	position: relative;
	margin-top: 10px;
	left: 260px;
}

#flickr li.frame2 img {
	width: 72px;
	height: 72px;
	position: relative;
	top: 17px;
	left: 24px;
}

#flickr li.frame3 {
	background: url(frame4.png) no-repeat top;
	height: 112px;
	width: 114px;
	position: relative;
	margin-top: -60px;
	left: 0px;
}

#flickr li.frame3 img {
	width: 71px;
	height: 72px;
	position: relative;
	top: 16px;
	left: 21px;
}

#flickr li.frame4 {
	background: url(frame5.png) no-repeat top;
	height: 129px;
	width: 133px;
	position: relative;
	margin-top: -90px;
	left: 123px;
}

#flickr li.frame4 img {
	width: 71px;
	height: 71px;
	position: relative;
	top: 25px;
	left: 30px;
}

Relative positioning gives the best results here. You can achieve the same sort of look by positioning with margins, but it can leave odd dead space underneath in some browsers.

All that roughly gives you the layout you see in the footer.

Dynamicising

Again that’s all well and good as long you don’t want pictures added automatically when you upload them to Flickr. As I’ve mentioned FlickrRSS is pretty good with it’s templating. It allows you to add the before and after tags, and to specify a class for each item.

Unfortunately it only lets you specify one class and for my gallery I needed to be able to specify a unique class for each list item. Some hacking was in order, and thankfully I found it relatively straight forward.

The important bits of code are held in the flickrRSS.php file, around line 100, and look like this…


print $before_image . "<a href=\"$url\" title=\"$title\"><img src=\"$cachePath$flickrSlug.jpg\" alt=\"$title\" /></a>" . $after_image;
  } else {
    # grab image direct from flickr
    print $before_image . "<a href=\"$url\" title=\"$title\"><img src=\"$imgurl\" alt=\"$title\" /></a>" .         
  $after_image;      
} // end use imageCache

Thanks to some nice semantic code it was fairly easy to see that these were the part of the code concerned with the HTML output of the images, with both the before and after tag sections.

I knew I needed to get a count function up and running that would increment every time the code looped around. While browsing through the line I notice there was already a $i noted in the code. This is always a sign that there is already some sort of increment (i you see) in place.

I plugged the $i hooks into the existing php code and, well, it outputted 0 five times.

Obviously it wasn’t incremented. So, to be honest, I guessed and added $i++ (which is what you do to increment something). I crossed my fingers – and (woooo!) it worked lovely.

So my version of those lines look something like this: (the bits I changed, or added, are in bold red)


 print '<li class="frame'.$i.'">' . "<a href=\"$url\" title=\"$title\"><img src=\"$cachePath$flickrSlug.jpg\" alt=\"$title\" /></a>" . $after_image;
  } else {
     # grab image direct from flickr
      print '<li class="frame'.$i.'">'  . "<a href=\"$url\" title=\"$title\"><img src=\"$imgurl\" alt=\"$title\" /></a>" . $after_image; 
$i++; 

I’m not in any way saying this is the best way to do it, but it works for me. In fact I’m thinking that the $i++ is in slightly the wrong place. But it does work! (Also note that this will obviously break the template features of the plugin, the rest should work OK though.)

This is why the numbering of the classes in the HTML starts at 0 – $i isn’t incremented until the end of the loop, you see, and it’s start at 0…

Of course I knew that and didn’t have to track back and renumber the CSS…

Ending

That’s it really, that’s how the gallery was designed and implemented.

As usual this post has gone on to be much longer, and taken much more time than I had planned! I really should work on not just dumping my brain on to my blog.

Hopefully it will come in handy for some one, at some point. I know I would have found it fairly useful, so hopefully someone out there will too.

As I mentioned I can’t really say that the bits of PHP are the right way to do things, they are just a way I fudged together to get flickrRSS to do what I wanted.

Your mileage may vary, as they say!