Gadgetopia

I’m just wrapping up a bigger-than-average, commercial content management install. One of the things this system promotes — as do many — is image management.

Sure enough, the system has a library in which the users can store images. They can browse the library to insert images using the WYSIWYG editor.

Sounds great, but here’s the problem —

Records in the library are one-for-one matched with files on the file system. Meaning if an image has two versions — a full and a thumbnail — then it has two records in the library. If it also has a cropped version, that’s another record. Etc.

To this, I ask, what’s the point? How are you any better off than just having a folder structure with the images and the image files in it? I’m looking at how they’re starting to use this system, and I just don’t see how they’re going to much better off than before.

There are going to be tons of different images and different renditions of images…just like in an “images” folder in a normal file system. There’s going to have to be file-naming conventions and rules and regulations to keep everything organized. I predict it’s still going to spiral out of control and more and more users start using the system and more and more files get uploaded.

There is a better way.

Content management systems need to separate the idea and concept of an image from the specific implementations of the various files. Images need to be logged in the system as the “pure essense” of the image — less of a concrete file, and more of a picture of something. These pictures need to be referred to and handled as abstractions of images. These image abstractions can result in multiple “implementations” of image files.

Say, for instance, that we have a picture of a boat. It doesn’t matter that it’s in 32-bit color, or that it’s a JPG, or that it’s 400 x 300. The abstraction is that it’s a picture of a boat. If I’m looking for a picture to illustrate my article about sailing, I can look at this picture and decide if it’s what I want.

Now, back when we uploaded this picture of a boat, our CMS created mutiple implementations of this picture. We have it set to create a thumbnail that’s 200 pixels wide, and another version that’s black-and-white for the print version of the site. These are implementations of the pictures — specific file manifestations of the abstraction that is our original image.

This implementations are based on “image implementation profiles.” We can name them — “thumbnail,” “b+w,” full_size,” etc.

So what we’ve done is created our library with a third dimension — depth. You can browse the library, look at the all the pictures, then look “behind” each picture to determine what specific image files are available for that picture.

This makes a lot of problems go away.

1. For each picture we put in our CMS, we automatically get multiple renditions / manifestations / implementations of that picture as image files.

2. Images files are not accessed directly. Our templating language, for instance, can have a syntax where we refer to the abstraction (“boat_picture”) and the implementation (“200_px”). Kind of like this:

   <img src=”{get-image name=”boat_picture” profile=”200_px”}”>

   The system then calculates the path to the actual image file.

3. Multiple image files are managed behind a single representation of the file. If you delete the boat picture from the system, all the image files behind it get deleted too. If you rename the boat picture, it doesn’t matter since the name of the image abstraction isn’t at all connected to the name of the image files (which can be random guids, for all we care).

4. If we want all of our thumbnails to be 250 pixels, the system knows what image file is affected since each image knows what implementations are “behind” it. Batch resizing turns out to be pretty simple.

There is one content management system that does this pretty well. Not everything I’ve descibed in Deane’s Perfect Content Management World, but still a lot of it. But I talk about it all the time, so I don’t want to seem like a shill.