Lightboxes are really irritating. No users I ever speak to like them, but all website owners love them – communication problems there, maybe?

Here’s why I don’t like lightboxes:

• They usually override keyboard functionality. I use my escape key to clear fields and I use my arrow keys to navigate pages – don’t overwrite that. I know best, not you.
• They’re unnecessarily schmancy and animated – if I opened a lightbox, chances are I want to look at a picture and nothing else. Leave me alone otherwise. I don’t want to see your great “close” icon or any of that crap so just drop it!
• Some are nearly impossible to close

There are probably a bunch more reasons, but you get the idea.

My lightbox stays out of your way. It doesn’t override any standard keyboard behaviour and it doesn’t use visual fluff to irritate you. What it does do is open a big version of the picture you clicked on so you can see it in more detail. When you’re done, it closes. Here’s how you use it:

• Click a flickr image to open the lightbox (this might be the last time you need your mouse/trackpad)
• j = next
• k = previous
• o = open the flickr page for this image
• q = close the lightbox
• You can also click anywhere to close the light when it’s open

If you’re wondering why j,k,q; use Vim for a day. I would’ve used e to open, but who’s going to remember that?

I’m probably going to implement a resizing thing for people with small monitors so that screens don’t get flooded – if this affects you, please tell me whether you’d like the process to automatically detect your browser size, or whether you’d prefer to handle it yourself. I’m aware that this will affect basically all portrait images – this will probably make me make it automatic. Pictures are pretty pointless if you have to scroll, but I’m tired now and can’t be bothered.

If you want the code for this, view source and find the javascript yourself. There’s a PHP file to make Flickr API calls, but that encapsulates my API credentials. If you can’t figure out what to do here, holla so we can all have a good laugh.

On BuiltByBuffalo‘s Proposal Planner, we use a much-revered slider thingy that we’ve had a lot of compliments on. We recently received an email asking for a little tutorial on how to put this all together. The main brief is actually pretty esoteric, and you probably won’t be working with designers of the calibre of Jason Reynolds, but this should show you how to put such a thing together.

First off, you need 3 elements. I’ve gone for divs because they’re fairly non-descript and semantically pretty viable for use here. I’ve gone for the following structure:

<div id="scale" class="m1" rel="6">
  <div id="full">
    <div id="marker"></div>
  </div>
</div>


The rel on this div refers to the maximum number of positions on the slider. Unless you shamelessly steal all my source images, you might need to change this! The class refers to a CSS class that denotes the width of the guage element (#full), defined thus:

#scale.m1 #full {
  width: 43px;
}


Because the marker element (#marker) is floated right, it will always stay to the right side of the guage div, so there’s no need for any more CSS than this.

Now that we have our layout and have defined our images (I won’t insult you by teaching you how to set a background image. If you really don’t know that, the declarations are in the source!), we need a method of getting between them. In the actual planner, we do a bunch of ajax-y stuff between stages that’s not relevant here, so here’s a simple breakdown. We’ve got 2 links, next and previous. We, therefore, need 2 event methods to handle input.

In our Marker class, the initialize method deals with identifying the container, marker and guage elements so that we don’t need to keep traversing the DOM to get them. It also sets the current state of the marker and gleans the capacity from the rel attribute (even though it shouldn’t really – you can hardcode it if you want!). We then have our next and previous methods, which just check that their respective states are valid (we don’t want the marker trying to go to 0 or 7, so we stop it from happening).

The method do_morph is where all the legwork is done. We construct the class to Fx.Morph to (mootools requires the whole CSS declaration, not just the element) then define some other options for the morph (namely the duration and a method to run when it’s completed). The completed function calculates the background position needed on the marker image so that we display the correct state.

I’m not great at explaining things, but hopefully that’s done a little to make it clearer for the person who asked for this post, and easy to steal for the people who are that way inclined!

Enjoy the demo:

Oh crap, I accidentally deleted the demo. I’ll put it back when I’ve got some time. In the mean-time; check out the real thing

I’ve made some changes. If you see anything that looks wrong (and you don’t use IE6), let me know.