This is almost exactly how permissions work at the college where I work. The big difference is that I am the only person with permission to edit library web pages. I maintain an exact duplicate of our library web space on a server and allow specific library staff members access. They edit the "test" environment - and then I upload the pages to the live server. Our library is much smaller than yours, but this is still a cumbersome process. We have purchased a CMS - and I CANNOT wait until it gets implemented (probably sometime in 2008).

There were several reasons that I didn't push for any other librarians to have access to the live web. The major reasons are that there is too much inconsistency in styling & format with multiple editors (I have to do some serious editing on most pages maintained by others), and that the job of maintaining web permissions by hand in a Windows - and yes, FrontPage environment is incredibly complicated. Creating a duplicate site allowed me to open up our pages to more librarians, but also allows me to see everything before it goes live.

Opening up web pages certainly requires some radical trust - something that I doubt most IT departments would embrace (and there are some good reasons for this).

Good luck!!

Jennifer, Thanks for your comment. I've heard of models similar to yours - librarians create pages, but one person edits them and uploads the files to the server. I hope you enjoy the CMS!

I didn't go into great detail about our system here, but let me add this: All librarians create pages on a development server. At the end of each day, a librarian reviews the pages before sending them to the production server that hosts the live site. If there is a problem with any pages, the pages are held back for revision by the page creator. So, we don't give anyone access to the production server. The permissions groups I was writing about are on our development server.

Hi Laura - web editing at MPOW used to work very much like yours, but we just made some changes. In the short-term, we've moved to a centralized model -- we have a "pool" of web editors who all have access to all areas of the site (on both the development and production servers). Web editing requests are made through a form and one of the web editors picks it up and works on it (based on their time and current committments -- they all have "other" jobs too!). We just implemented this a few weeks ago and so far it's working well. There was a bit of reluctance to remove permissions altogether and open up access to all areas of the site to all editors (the editors themselves were a bit nervous about it), but, as I suspected, there haven't been any issues at all. Having a development server probably helps.

In the longer-term, we're moving to a content management system, so we'll probably de-centralize things again. But that's a few months-a year down the road.

Cheers,
amanda

At my small-staffed library, I'm basically the only one who has permission. Staff submit information to me, and I manually add it (yes, you're not the only library still in the dark ages of manual web-edits).

Right now, I'm in the middle of choosing a CMS for our website (current favorite: Drupal). Once we implement a CMS, I would like to give librarians permission to add/edit all pages with maybe requiring approval by myself before the changes or additions are made public.

Amanda, You bring up an interesting point: that opening up the entire Web site to staff editing can be a bit scary for the editors. As with so many things, the concept can be more worrisome than the reality. I'm glad this strategy is working at your library.

Jonathan, There are rumblings in my library about implementing a CMS. In fact, they're getting louder - very gratifying! I think it can take time for staff to understand that there are better ways to manage a site than the manual edits they are used to. I think that the experience with the simplicity of blogs is helping staff to realize some of the benefits of a CMS.

Best of luck selecting a CMS. I'm sure your colleagues will appreciate the chance to have direct access to their content - as many of them probably do on the recreational Web.

Laura,

At UH Libraries we use a homegrown CMS that utilizes a combination of individual and group ownership, but that has wiki-like features. What this means is that any library staff person can make a change to a page but that page doesn't go live until the page owner approves. Owners can be individual staff, a department or a group of staff. This allows flexibility on sections of the site that aren't owned by an individual. At some point we may extend contibuting to other members of the University community, but it is likely that the page "owner" will still have final approval of changes to maintain a given set of standards. However, for this to work well, page owners need to be responsible in keeping track of their pages and the contributions others make.

Karen, Thanks for sharing this info about your system. The idea of open editing combined with the approval of owners is an interesting one. I assume that owners are notified of edits so that their reviews can take place in a timely manner. I think it's interesting to contempate a library's Web site as an official publication of the institution alongside possibilities of opening up portions of the site to campus contributions. How do we handle standards in a trusting environment?

Yes, you are correct owners get notified when a change is made and can then view that change and approve it or not. One thing we haven't done yet but I'd like to do is let supervisors know if their supervisees are reviewing their pages in a timely manner.

As far as standards, we have a Policies and Procedures document that governs our site and is ever evolving. We rely on humans not technology (for the most part) to enforce this. Personally, I prefer this approach because building a systems with enough intelligence to make policy determinations is difficult and locks you into particular workflow, processes, structures, layouts, etc. We had this with the old site and it didn't work.