Image Abstractions and Implementations in Content Management

By Deane Barker on January 30, 2006

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. Image 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(“boat-picture”, 200)}” />

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

  1. 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).

  2. 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.

Comments (3)

Bill Van Vooren says:


You mention that image filenames can be “random guids for all we care”, but is there a file naming convention that you use or recommend for this type of system. It seems that there has to be some value to attaching a name with some meaning to a physical file, but maybe any attempt at this is doomed to failure when additional “sailboat” images are added to the system.


Deane says:

But, you see, we don’t care about the actual file, we just care about the abstraction name. The user shouldn’t have any interaction with the actual file, just the abstraction and the different profiles. Given this, why do I care about the file names?

Bill says:

In my case, there’s a difference between “users” and “power users”. I am implementing this type of system for a website that is currently 100% static html, and having the graphic designers interact with images solely through a CMS UI (download the file, make changes, upload the file) rather than the file system will be a rude awakening. I was hoping to give the designers some hint about file contents without the need to lookup the image in the CMS or navigate a monstrous folder hierarchy. GUIDs are not particularly user-friendly in a Photoshop “Open...” dialog (though, of course, thumbnails are worth a thousand words).

I totally agree that human-readable filenames are technically unnecessary.

Your CMS comments are always helpful, and I will put your idea of “image implementation profiles” into immediate use. Thanks.