I’m back, and now I’ve knocked “sharing the DAM thing” off my “to-do” list. Read on.

Gavin’s DAM System

Finally (finally!), my brain kicked into gear. I figured out an easy way to share the DAM thing. Moreover, I re-did the whole thing in WSS just to make sure it was totally portable and didn’t have any residual MOSS attributes, etc.

I knew it should be easy. I think I was just over thinking it. Finally, one day, I, not so gently, slapped myself in the head and said (to myself): “why not just put it up on one of those free file sharing/storage systems that have sprouted up all over the place in the last few years. Might just be a good chance to take a look at how they work anyway.” A couple of aspirin later (for the headache after the slapping) I did it.

Here’s how: I closed my eyes and picked one. Once I picked one, I then puttered around with it trying to figure out how to actually share something. Then I trashed it, and tried another. Trashed that one, and tried yet another, and then another, and … finally I found one that would do what I wanted. It’s a nice service and it seems to work. It’s called File123. It seems workable.

The downside — it has a time limit. Four weeks. We’ll work around that simple enough. As long as people want it, I’ll keep resetting the date and/or posting a new copy.

So, (tad da!) you can find the completed DAM WSS template here:

http://www.file123.com/Transfer.aspx?guid=33a3935c-a4e4-4df0-975b-f066fcfe34e7

(Link updated 10/29/2007 – the new link will expire on 11/26/2007)

(12/4/2007)

I got tired of updating that link, so here’s one that won’t expire, up on Microsoft’s new (beta) Skydrive. Click here.

As I said, that URL will work for four weeks (all these systems impose some sort of time limit – I guess so you don’t use them as some sort continual, free, FTP hosting service just like I am doing). In four weeks I’ll re-share the file and reset the date.

Now: Some information:

First, I re-wrote the whole thing for WSS. My original (and working) design is in MOSS. But, I discovered that while something designed for WSS works just fine in MOSS, the reverse is not necessarily true. So, I just redid it in WSS.

Second, I completed the “Graphics” section. The photograph section was fully formed, but the Graphics section had been left wanting. I also put in some sample graphics and pictures. Of course, feel free to delete.

Third, I’ve saved it as a WSS template, instead of a “backup.” This, I believe, makes it much more portable and flexible. Everything is still there (I chose the option of saving data with the template), but templates are designed as “re-usable,” so there should be no issue with broken links or the like. I also eliminated the “search” portions. Instead, it should fall right into whatever search is appropriate for your particular installation.

Fourth, here are some basic instructions

Step 1: Add the template to your MOSS/WSS installation:

• Choose: Site Actions
• From the Galleries list, choose: Site Templates
• From the List menu, choose Upload and then upload the DAM WSS STP file into your site gallery.

Step 2: Choose to create a new site. On the site information page, choose the template under the CUSTOM tab in the Template Selection named “DAM WSS Version.”

Finally — and I say this seriously — download and have fun. However, Caveat Emptor and all that jazz. I offer no guarantees. I distribute this free of all responsibility and liability, use and/or abuse at your own risk. It should give you no problems, but if it does, well… I’ve left town, yeah, and am now living on the island of Fernando Poo, or maybe the long lost Isles of Langerhans… Yeah, that’s it.

[Here's another in my continuing critiques of the scalability and limits of most web-two-dot-oh stuff. It's part of my ongoing litany about nonprofits needing "the basics" – It ain't all about fancy web sites, sophisticated communications systems, and interactive bloggy-wiki-groovy things. The real world needs working infrastructure, including training and training and training, and accounting systems, and communications systems, and shared calendars, and to not keep their mailing lists in a word document, and, and, and… … more than anything, staff that know how to use the stuff. Boring, I know, but true. ]

What got me thinking about this was two-fold: First, I have a crying need to manage thousands upon thousands of images — a collection that dates back some 75 years, and second, someone asked the very question over on the “InteRider” listserv, to wit:

“Does anyone have any recommendations for a digital photo management system for a small NGO? We are looking for something that makes cataloguing, indexing, storage and retrieval of images relatively easy and efficient.”

There was, of course, a flurry of responses — including folks suggesting both Picassa and Flickr — but all suffered, in my opinion, from the same old problem: These damn things are not designed for organizations.

Let’s look at Flickr, for example. I love it. I love it enough to pay for the “Pro” account. I load my pictures up there on a regular basis. Feel free to browse my latest set, entitled “Brussels Noir” – my photo safari through the night streets of Brussels one gloomy February evening or two.

However Flickr — multi-user from the get-go — still suffers the faults of a consumer product. It is a consumer product, so it’s not really a fault. Flickr tools, for example, are designed to help you get items uploaded and into your Flickr site. But, I challenge anyone to point out the tools that let you get photos out of Flickr [aside from the old, right-click-and-save-as]. This is not a product for managing large collections of photographs within an institution. It’s especially not a tool for finding, selecting, editing, manipulating, and generally mucking about with the images. Damn.

Having no where else to turn, I turned to myself. I built a photo management system with SharePoint. I call it a DAM system — DAM is short for Digital Asset Management. It’s fun to talk about in meetings. I get to say things like: “The DAM system works” or “You need to update the DAM subject codes.” Great fun, believe you me. [Somewhere, still inside of me, is that 12-year-old Boy Scout that got such great joy out of singing "Amster, Amster - Dam, Dam, Dam" around the campfire. Strange, I only remember the chorus, not the rest of the words.]

My DAM system is a testament to the flexibility of SharePoint. Start to finish, once I had it spec’ed out, it took only a few days to build — and most of that was in thinking thru the supporting tables and coding systems and then loading up those tables with real data. [Now, in interest of full disclosure, I had thought about the problem for a couple of years, and I had designed a couple of other DAM systems in previous versions of SharePoint, including SharePoint 2001, SharePoint 2003, and WSS 3.0. – but it was still pretty easy.]

The building (and the spec’ing) required some backwards thinking: the ephemeral art of imagining the goal and then working backwards to figure out how you got there. Truthfully, it helps to think backwards. Something I’m good at.

My first foray into programming was on a 200 step programmable HP calculator. It was in high school, amazingly enough. The “calculator” was size of a large microwave, it cost $25,000. You could pick the equivalent today as trade-show swag. It was programmed in “RPL” – short for Reverse Polish Lisp. The emphasis was on the “Reverse” – to program this beast, you had to know the answer and work backwards to the problem. I learned then I was good at assuming a goal and working backwards.

With database design, the same things hold true, despite the intervening years. I just think backwards. Between you and me, with SharePoint, backwards thinking is required. It’s either that, or you end up redoing things a couple of times. In the end, it’s easier to have all the support tables setup before you set up your master list or document/picture library.

Building a DAM System:

First (or is it really last?), I needed a few supporting tables (or as SharePoint calls them, “lists”). My design goals included:

1. Keep it simple, yet powerful.
2. Where possible, use forced vocabularies (read: taxonomy) to catalog the images based on pick-lists and lookup tables.
3. Provide an easy to use, consistent, error-free, and end-user-proof system for cataloging.
4. Provide “Google-like” tools for search, ’cause that’s what users will tolerate.
5. Provide simple tools to sort, manage, organize, view, retrieve and repurpose images.

Hence, my design called for lots of pre-populated lookups. I’d let the anarchists and other folksonomic folks frolic elsewhere in the design. They get their fields, I get mine. And, since I’m the designer, I’d make mine “required” [evil laugh].

I decided on a total of six supporting tables, one each for subject, program,
location, credit, geography, and usage. I describe them and how they’re used, below:

• Subject (Coding): Multiple choice list of pre-selected (controlled) subject terms. I used a subset of the NPC since we already use this taxonomy within the organization. I built the list with two fields and concatenated those fields to create a single field for the lookup. The first field was a “code” in the form like “A10″ or “E4″ and the second the term itself, like “aquarium.” Using the “code” lets you sort by the code instead of the description, hence logically grouped terms tend to stay in the same area of the lookup table. Less messy and easier to use.
• Program (Coding): This is a completely idiosyncratic taxonomy used to catalog our grants. This is so engrained within our thinking that we see the world through these lenses whether we wish to or not. Again I used two fields and concatenated them into a single lookup much like the subject codes, in form: “Program” — “Program Area.” For example, “Environment—Freshwater” or the like.
• Geographic Focus (Coding): This is a three-tiered hierarchal coding originally based on ISO country codes. The table allows up to three fields that are, again, concatenated into a single lookup field. However, in this case I concatenate in reverse order to make the pick-list easy (e.g., “Ann Arbor – Michigan – United States” instead of “United States – Michigan – Ann Arbor”). I also include a “Special” category, such as “Great Lakes – Special.” This lets us have ad-hoc groupings for regions, special areas, and the like. People tend to think “ad hoc” and this solves that problem.
• Credit (Supporting): This is a list of photographer’s names and other contact information. Since it was “people information” I got smart and just used a standard MOSS “Contacts” list. It had everything I needed and more.
• Location (Supporting): This is a completely idiosyncratic list of hardcopy storage locations. Since we have a lot of original photographs, stored in our archives, it’s a reference field to the actual physical location. If we only have it as a digital asset, the option is DAM (as in Digital Asset Management).
• Usage History (Supporting): This is a list of publications where the photo may have been used. Not strictly germane to the system, it’s a user requirement. We use it to track when and if we used the photo in a printed publication. There is also an entry for “Web Site” and the year. Seemed useful.

Here’s a snapshot of how the various supporting tables look like:

Table 1: DAM Geographic Codes

Table 2: DAM Program Codes

Once I had the coding tables and supporting tables in place, building the DAM system was relatively easy.

And, it was here that I got creative and designed in the folksonomic flexibility that I knew people would ask for. I was pretty sure that I had designed in enough structure — enough forced vocabulary — that the system could survive the ensuing chaos. So I went wild (in a database designer way) and added in free form “Keyword” and “Description” fields. I have a suspicion that the “Keywords” field will prove redundant, given that the search engine indexes all fields, it strikes me that the “Description” field should be more than sufficient. Moreover, given user-fatigue, I imagine that we will quickly stop using all but the required fields, and “Description.” Simple always wins.

Trying to think simple (and backwards), the entire system has only 11 metadata fields, in addition to the system fields. I outline the fields below.

Most, if not all, of the system fields are automatically created and populated by SharePoint — this keeps to the design criteria of “simple” yet powerful.

DAM User Interface:

SharePoint provides a sparse user interface OOTB (out of the box); lots of potential, but not much “substance” on the screen. Without some customization, MOSS pretty much drops you to an almost-blank screen. Users don’t like dropping on a blank page. SharePoint leaves you wondering. Unless you put them on the page, any document libraries, or picture libraries, or other content is kind of “hidden.” I remedy that by creating what I call “a soft landing” — usually something simple like a nice graphic that folks can click. The click takes you into meat of the system.

Tool-wise, MOSS gives you a whole toolbox at your fingertips. You get thumbnails, a “slide sorter” view, a list view, and tools to upload, download, and insert into Outlook, or Word, or open in an editor. One thing you can say about Microsoft products is they integrate well – ah, as long as it’s with other Microsoft products.

Figure 1: A DAM Soft Landing

For this DAM system, I used actual content for the landing page –a picture for the link into the photo repository, and a graphic for the link into the graphic repository. To make it easy to change things in the future, the two “click boxes” on the front page are simple “CEWP’s” (Content Editor Web Parts) that reference to generic graphic images named “PhotoLogo.jpg” and “GraphicLogo.jpg.” The images can be swapped out easily by simply placing replacing the graphic files. The JPG files are stored in an unlisted photo library.

(Oh, I forgot to mention I did a similar system for graphic images – uses the same codes, mostly. The only real change was to include artists in the “Credit” table, and a few different supporting tables. But, this post is long enough without me going into that piece of the pie.) Note the nice navigation on the left side – a list of the supporting tables and codes. These are, of course, security-trimmed — only showing if you have appropriate rights, etc.

Clicking on logo of the “shoes” takes you into the DAM system. [See, ain't that fun.] There are two views predesigned views — one designed as a “list” showing a small thumbnail, and allowing you to filter on the various metadata fields. This is how I expect most people to wander around in the system, filtering down on a particular subject or geographic code; and a “Slide Sorter” view. Here’s a picture of the pictures – two different views:

Figure 2: DAM List View

Figure 3: DAM Slide Sorter View

Now, the tools that SharePoint brings to this, OOTB, are formidable. First, everything is indexed by the MOSS search engine. And, just so you don’t feel left out, this works in WSS too. There is nothing here that can’t be done in the bundled version of Windows SharePoint Services (WSS 3.0).

Moreover, within either of these views, you get access to a range of actions, including upload, download, edit, and send to, as well as the ability to subscribe to the library itself via RSS or via MOSS’s own “Alert Me” system that works via Outlook.

Figure 4: DAM Actions

Finally, the Send To feature bears mentioning. It’s a neat little menu that lets you pop selected pictures into Office apps. I used it to insert the following screen cap, right from the picture library and into this blog post.

The fact that all of this can be done fairly quickly and easily with a product that is bundled for free with Windows Server 2003 is pretty damn neat — and that doesn’t even begin to touch it’s flexible, integration with Word, InfoPath, and the rest of Office. Damn, DAM: damn neat.