Primarily, I want to encourage wiki-as-CMS use for UMBCs website architecture. I have a lot of wiki experience and what I believe are success factors for doing a CMS right at UMBC (and abroad).

The below ideas and ideal situations are things I have noticed and is advise that I give from my professional wiki/CMS experience. At the very least, keep the ideas in the back your head!

I saw that OIT may be moving their webpage to confluence! Yippee! I say go for it, it will shine (if implemented in the right way). I very seriously toyed with the idea of using my wiki of choice, dokuwiki, as the CMS for the gradschools public website over the past 2 years. Over and over again the only stopping concern was that no one would know how to run or support dokuwiki if I were to leave or something happened to me or my position. Everything else inherent with a quality wiki/CMS (Content Management System) would have served to enhance the Graduate School’s and UMBC’s goals and business habits. With Confluence, its supported by Atlassian and OIT workers, so there should be nothing stopping you if it is a flexible, open, quality wiki product.

I have administered and used 7+ professional-grade CMS‘s & wiki’s and have some ideas, observations, and suggestions that may enhance what OIT has already succeeded in accomplishing.

In my opinion, CMS systems such as “stupid simple” wiki’s are the future of the web administrative wise, content-creation wise, and outward usefulness wise. They will explode interaction by not only external users but also internally too, as they are too simple to dismiss and NOT use them (again, when implemented in the right way). The utility fee of using this technology has to be so low, that it does not make sense NOT to use it; users will be better off by using it, than not. By utility fee, I mean the resources, effort, and time it takes a user to utilize a tool. I give examples below of methods that reduce the utility fee.

I kept an extensive wiki about the Graduate Schools IT systems at http://www.umbc.edu/gradbusiness/techdocuments/ It has maybe 60+ pages of content, but more important to you, has some features that I think are important. Dokuwiki is extremely smart in its search-ability. Search-ability with correct and easy to swallow results is one of those ‘implemented in the right way’ items that really goes a long way in how a CMS will be successfully accepted and used.

Users often need to know a general page to go to, not a specific instantiation of the text inside of an obscure page. In particular, dokuwiki has ajax to show page names that match your search, as you type, before submitting your query. Actual submitted query results first list page-title hits, then hits on text inside pages.

Another idea, that the web in general may begin seeing more, is googlesque features similar to Wikiwyg (which i was going to include link, but it is outdated and not working). Others have implemented the idea though. Basically, making content editing as easy as double clicking a current web-wiki page as you are consuming it, and editing it right there on that page via ajax’ian style editing methods; no more clicking an edit button, no more page and content refreshes when you want to edit what you are looking at, less separation and barrier between content consuming and creating. Wiki’s as CMS are all about reducing barriers for entry and continued use.

I think content creation by external users would best work if there was a stupid simple content verification workflow that was guaranteed paid attention to/managed; when I say guaranteed, the fear is in that an employee may not have the time or forget to check on changes that other users make, which instantly discourages user interaction. To satisfy both concerns, one could implement something where if a change is made, and not acted-upon / disapproved within 4 days, it automatically is approved and put live. Email could be automatically and forcedly sent to those people in charge of a page (original content producer?, assigned systematically?). In OITs webpage case, certain pages would ideally be locked down more or less. I have no idea what confluence and its plugins provide, just spitting out what I think would conceptually work best in a business+user collaborate-web-environment.

Another barrier reducer, is easier and more automated user authentication handling. UMBC has a nice single sign in system that I think looks like you integrated... nice! The ideal would be to not have to login, for the website to just “know” who you are (after initially establishing who you are) and instantly let you double click any text to edit it at any time. This does not conform with existing security realities, but a step toward it might be allowing users to sign up certain IPs, cookies, etc to allow the wiki to repeatedly and automatically authenticate the person to the system. Logins are an unseen and ‘accepted’ barrier, that I think could be substantially eased.... it just might take a lot of work to implement the ease.

A success factor that I never implemented or figured out is content classification and organization that is flexible, yet (semi?) automatic. I really like tagging systems and hierarchies. It looks like Atlassian has some kind of built in hierarchy or taxonomy system. Not sure if it integrated and automated. Balance between site usability for consuming users VS completeness of content VS succinctness of the system for editing users provides so many questions and balances, that I do not have a finalized ideal situation here. It should definitely be thought over carefully.

Content conformity is another huge, unsolved by me, problem. You want your website and content to conform to some standards, similar organization, and writing style, despite coming from multiple sources and users. The only success I have seen here is to look to wikipedia and their extensive meta-documentation and policies on how they expect users to post and organize content.