Naturally, the first question we considered as we developed our content management strategy was: what content are we going to manage? We create all kinds of products, but were only focused on a subset for our project. So we concluded that we’d need to manage text and image assets for the particular products the system would make. Makes sense so far.
Images are relatively easy to manage. Each image is a file. Sometimes an image is made up of several other images. We had to have a philosophical discussion around these. Is the image that contains other images a new, unique asset; or, is it a compilation or reuse of other images and only exists as a different container for those other images. We went with the “new image” concept because the act of combining images created an indivisible content chunk. Or something. Whatever works, I guess.
The content management system we were going to use managed assets as separate objects. The objects could be assigned a “type” having mostly to do with the file format of the asset. The objects could also carry “attributes”, or metadata. The attributes could be anything we wanted them to be. So we had to figure out what we wanted them to be. Per our usual routine, we gathered representatives from each of the groups who would be using and managing the assets and asked them what kind of information they’d like to see attached to each asset. And we got a very long list. Even after editing it down we still had a very long list.
Stupid thing 1: Overdoing it.
There are lots of aspects to image management. There are content concerns, such as “what’s the image of.” There are design concerns such as “what’s the color space and resolution.” There are permissions concerns such as “who owns the copyright.” There are tracking concerns such as “where has this image been used before.” They’re all necessary. But do they all need to be addressed in the content management system? I guess the answer is “it would be nice but only if the system can handle it.” And ours couldn’t. At least not very well.
The problem with sticking all that metadata on an asset in the kind of system we were using is that every time you want to do something with that asset, all that metadata comes along for the ride. We had screen after screen of metadata that a user could fill in whenever they checked in a file. The problem is that not every user cares about all the metadata. I believe the current version of the content management system addresses this problem by assigning certain metadata to certain roles as defined by a user’s account profile. But we didn’t have that option. So, the task of editing a file and checking it in took an extra couple of seconds because all that metadata had to load, and the user had to click through several screens or scroll a long way before the OK button showed up. Multiply those seconds by all the images someone would be working on in a day, and you end up with an unhappy user.
What we should have done: Stick to core needs.
We were not building a contract and permissions tracking system. The image specs such as color space weren’t going to be used by the system to do anything. The overall goal wasn’t to create an art library, it was to create products by assembling assets. So we didn’t really need most of the metadata. We needed to manage all that information of course, just not in the system we were building.
Eventually, it would be nice to have a centralized system that could manage all the assets and metadata. The new publishing system we’re designing now may try to address that need. It would be great to have one place for various groups to do their business. But only as long as the system can handle it, the users aren’t inconvenienced by things they don’t need, and the overall goal of the project isn’t compromised.
More stupidity next week.
Filed under: XML |