Last week, after about a year of work by our team, we launched the first of our websites at the University using the new Content Management System we’ve been working on. It’s based on Vignette’s V7, a gigantic, sprawling, enterprise CMS system. (My standard joke: “Enterprise software is software that costs a million dollars and doesn’t work when you take it out of the box.”) I thought this an opportune time to post a few reflections on what I’ve learned of Vignette during the past two years I’ve been working with it.

First off, one must understand that Vignette’s offerings are not a single, monolithic product, but a suite of products which has been created by acquiring other companies and their software and then writing some integration pieces in-house to tie it all together. As a result, the quality and engineering foci of the various pieces are pretty divergent. Their Portal, for example, was bought from Epicentric a few years back, and is nicely engineered and well thought-out. The Content Management System, on the other hand, was developed internally by the engineering team and has a byzantine API and a number of bugs. (In fairness, the CMS portions are a good deal more complex than the Portal bits.) Finally, Dynamic Site, which is the presentation layer of the CMS, was actually written by their Professional Services organization, rather than their engineering team, and while it does what it does fairly well, it also has some big, gaping holes in its functionality that have yet to be filled.

I’m going to focus on the content management aspects of the system, since that’s what we’re using the most. Vignette provides web-based tools to manage structured content. Though these tools only work in a limited number of browsers, due to the extensive use of Javascript and failure to adhere to W3 web standards, they are quite powerful. Content can be reused, versioned, assigned to multiple presentation channels, searched, run through workflows, published to various stages, and rendered as XML, HTML, or any number of other formats. Thus, if you have people who can take the time to learn to use Vignette’s content management tools, it’s possible to do some very powerful things with your content. The interface to do all of this, however, is quite complex, and isn’t really suitable for use by people who don’t spend a significant portion of their day with it. As a result, we’ve ended up having to rewrite a fair portion of the content editing interface to make it manageable for the people in the University who will be maintaining sites — typically administrative assistants who only spend a few minutes each week making tweaks to their department’s site.

Initially, Vignette didn’t provide any application at all in V7 to present the system’s content, but instead relied on the implementors to write an application to pull content from the database via Vignette’s API. As I mentioned, Vignette’s API is not at all easy to come to grips with, nor is it particularly thought out. (For example, each content item in the system has two unique identifiers — a VCM ID and a GUID. Some API calls require one, and some require another. Not only is it not always clear which is which, but getting one if you only have the other takes some doing.) Several months after we started working with the system, however, Vignette introduced Dynamic Site, which is a framework on which to build content presentation applications. It includes some powerful content-querying features, and is a marked improvement over the void that preceded it, but still doesn’t provide a lot of flexibility in how a site can be structured. Our user experts deemed it too difficult for our users to be able to interact with directly, however, so we wrote around a fair portion of it as well.

As we got more content into the system, its lack of flexibility began to cause problems. I wanted to add some additional fields to an existing content type so that we could track more information. In most database driven applications, this isn’t problematic: you add the field to the database, maybe update a schema definition file somewhere, and you’re in good shape. Unfortunately, with Vignette, once you define a content type and have instances of it, changes to the content type are off-limits. When I contacted Vignette’s support about this seemingly-common task, their recommended solution was this: “1. Export all the instances of that content type. 2. Delete all the instances of that content type. 3. Make the changes you want. (You may have to delete the content type definition and rebuild it from scratch if the changes you want to make are extensive.) 4. Import your exported data into the newly modified content type definition.” Not a particularly viable approach for a production system.

When programming, one always comes across challenges, which I like to think of as a closed door. One thing I’ve really been enjoying about learning Ruby on Rails is that more often than not, when I put my shoulder to that closed door and push, I stumble because there was so little resistance. “Oh, I’m through and done already? Wow, great!” Programming for Vignette has been the opposite experience. I push, budge the door a few inches, get my fingers caught between the door and the frame, have to call some friends in to help push, and finally get the dang thing open. While it’s generally possible to get things done, it always feels like about four times as much work as it ought to be — an experience that tends to be a big joy-killer for a programmer.

There are some bright spots, however. As I mentioned, Vignette’s Portal product is well thought-out and implemented. It supports PortalBean, a proprietary interface for writing portlets, and JSR-168, the Java standard for the same task. It also supports WSRP, which allows it to publish portlets deployed on other, potentially non-Java systems. Vignette Business Integration Studio is a nifty visual programming tool designed principally for doing data migration and transformation which can talk to a variety of disparate systems. I quite like it as well. Though I haven’t worked with it, Vignette’s Builder also looks to be a very nice way to quickly build portal-based, database-backed applications as well.

So, where would Vignette’s Content Management System be a good fit? In the case of a highly-structured site with lots of traffic, consistent data and people devoted to content management, it makes reasonably good sense. The Olympics’ official site when the games were in Greece was run off of V7 and enjoyed good success. Vignette’s older content management software, Storyserver, grew out of software developed for CNET, a technical news and information site — the sort of application to which V7 is still well-suited.

At the University, however, our most important needs are flexibility, simplicity, and ease-of-use. These are, unfortunately, Vignette’s weakest spots. As a result, it has taken us an inordinate amount of time and consulting hours to finally get to the point where we’ve been able to field what is, ultimately, a pretty basic set of content management services. While there are aspects of our system that I am proud of, in general I’m left with a sour feeling that we’ve put in an enormous amount of effort for a fairly small payoff, and believe much of that to be a result of our decision to build on Vignette.