Writing these DAM instructions

Over the past few months I have been developing a DAM system for a nonprofit institution.  The goal was to create a system that would enable them to locate images from their collections in order to publish them, either to the website or in print.  The project is drawing to a close and I am nearing the point at which I will hand it off to them.  One issue I’m now confronting is the need for some instructions they can take away from this.  The software I’m using is ResourceSpace, an open source package that I have written about before.  ResourceSpace is a great tool and it fits the nonprofit’s needs very well, and not just because there is no licensing fee.  It’s web-based, fairly easy to use, and it can handle many different file types in addition to digital photos.  But one area that I find a little lacking is in its documentation.  There is a wiki available, but it isn’t really a comprehensive user guide, and sometimes it seems like it is written for a user who is already somewhat familiar with the software.  The developers also published a user guide, but it is now a few years old and some of the features and appearance of the software have changed.

I have a little bit of experience with other DAM software, including Canto’s Cumulus, and Portfolio from Extensis.  If you have ever read the user guides that accompany some of these tools, you can appreciate how dense and unwelcoming they can be.  The user guide for Cumulus is well over 100 pages, and I’m willing to bet that you can’t find too many people who have read the entire thing from beginning to end.  Possibly not even the person who wrote it.  For another take on the issue, see Henrik de Gyor’s post about documentation.

So I’m working on a (hopefully) short, basic version of a user guide for ResourceSpace.  I want to convey the essentials of the system without overdoing it.  I feel that too much information can be just as bad as too little, as it can cause the really important points to get lost in a sea of needless detail.  And since the whole concept of digital asset management is to create efficient ways to locate key information, it is counterintuitive to make the documentation difficult to navigate.  But I’m discovering that writing clear and concise instructions for this system is harder than I thought.  Even with software that is reasonably intuitive, there are lots of little details, and different ways of working, and I want to provide my client with a comprehensive discussion of the key points.  After all, they are the ones who will be using the system, and I want them to feel confident that they can max out its power, and also that they got their money’s worth.

So far I have spent several hours on the document, and every time I feel like I’m getting close to completion I find something that I either a) failed to include, or b) included that I want to take out.  I suppose it may never be perfect, but I’m going to spend some more time with it over the next couple of weeks, in the hope that I can refine it enough to consider it a finished product.  It’s part of the agreement I signed with them when I took the job, and I feel like it will be almost as important as the DAM system itself, because it will make the system much more accessible.  Also, if they hire new staff who will be using the DAM I would like them to be able to hand my instructions to the new person and have it make sense.

Another reason that I’m putting this much time into it is that, as a part of the open source community, I have been considering making this user manual a contribution to the product.  I’m not a programmer and I won’t be able to add much value to the underlying code, but if I can offer up some useful documentation, I will feel like I have done some small part for the good of the community.

So I’ll close by saying that if any of you have any good tips for writing something like this, please let me know.  And, if you are feeling especially generous of spirit and would consider critiquing my work, let me know that, as well.

Advertisement