This idea emerged out of a conversation that Renée Brown and I had last week, and I thought it worth sharing with the group.
Renée & I agreed that one of the problems with our current web system is that the editing functions for CMS are ineffectively distributed around institutional staffing. Focusing only on academic departments (our mutual site of expertise), departmental coordinators are the people who hold the keys to the CMS and edit/update the material on departmental sites. However, most of the content revision requests come from faculty & chairs, not the coordinators, and coordinators update sites so infrequently that most lack confidence and comfort in the tasks, and thus seek out help from LIS. The net result is that department sites are typically out-of-date, stagnant, and clunky in their design.
The interesting aspect of the conversation was our different solutions for fixing this problem. Renée suggested that web updating and editing should be more centralized, with staff who are expert at the website fielding requests from departments & other units for changes, revisions, design overhauls, etc. She felt that coordinators lack both the time and skills to dedicate themselves to this task, and will never have enough to do on the website to justify developing the necessary skills. She approaches this issue as someone well-versed in the current CMS system, and sees how the learning curve and historical problems with the system has made it difficult for coordinators to carry out their roles as active editors.
My idea for solving the problem is to create more editors, rather than fewer. With our new platform, we might imagine a more organically integrated editing system, where any user with a login could “make edits” to any page on our website – click a button that says “Edit this page” and have at it via a simple user interface. Any submitted edits would be sent to a moderator who would approve & tweak submissions to fit stylistic norms, proper formatting, and vet questionable content. Since it would be tied to a Middlebury login, vandalism shouldn’t be an issue (and can be easily disciplined if it becomes one). The moderators, probably at Communications or LIS, wouldn’t need to know the content area, just the form, with contact people for each page if there are content-related questions – since the process of moderation would be fairly simple, approvals could be done quickly rather than taking time for much editing, redesign, etc.. All users would be empowered to collectively improve content and quality, make suggestions and recommend clarifications. It wouldn’t be a wiki free-for-all due to the moderation, but it would marshal the energies of more than just designated web editors. (Renée’s main skepticism about this model is that too many people would simply choose not to participate, still asking coordinators to make changes – I’m more optimistic that there are a few energetic editors out there!)
I thought that our different visions on the potential solutions highlights the different assumptions of, to use a jargony phrase, Web 1.0 vs. Web 2.0. Personally, I think that our makeover should try to come up with a wide range of ways to build upon the efforts of many input sources and invite participation broadly under the banner of User-Generate Content, without turning the site into a decentered playground. I’m curious how others might view this or similar problems and possibilities…
-Jason
Jason, while what you talked about with Renee may be the case for the academic departments it is not so with the auxiliary programs such as SA, BL, LS and I would imagine MIIS. Having first hand experience with the more editors approach, I have found this to be ineffective to the point that I am in favor of a more centralized process. A few points on this- the people who physically make the changes, do so infrequently and the changes generally come all at once related to the calendar. This put strain on all our resources. Secondly, the many editors approach requires limited functionality for flexibility that many of the more advanced users would like. When you have a lot of people making changes the desire for consistency trumps functionality. My 2 cents.
Frankly, there’s no reason that it can’t be both – even on the same page. Take, for instance, Faculty Profiles as an example. These could include information about the Faculty member that is centrally managed: their title, office location, phone number, email address and photo, all of which come from the Directory and Banner. Below that could be a dynamic list of courses taught during recent semesters with course descriptions from a catalog managed by Academic Affairs and links to their course sites (in the case where the course uses one). Below that, a bio or CV pulled from the Faculty member’s personal home page, editable by them, or examples of recent work, or a dynamic feed from their blog, or videos of them engaged in instruction, etc.
We shouldn’t think of each page as a single entity or static blob of content but, when discussing what types of content we want to show, think about where that information could come from and who might be able to edit it at the source.
I agree with Ian that thinking of content as a dynamic entity is important. For example, pulling bio, CV, and publications information from faculty members’ home pages will in some cases retrieve out-of-date information because those pages as they currently exist are static blobs of content and vary in how often they’re updated. Also, the information is in multiple formats. So both timeliness and consistency become an issue with this approach, unless there are central repositories for that information also. So taking this opportunity to make more site content dynamic might be a smart thing.
RE: the many editors issue — might a style guide (available to all online, of course) be a useful tool for editors at the source?