Collier Jones, OIT: will provide an overview of the wiki program Confluence and address the group's questions about using a wiki to host library projects.

CJ: Confluence excels at serving as a public-facing knowledge provider, but is not as good as a public-facing marketing tool.

May lose customizations to interface with upgrades. If we customize the interface to look like the library webpage, this may bring us substantial problems later on. Upgrades are frequent, approx every 3 months.

Editing the design of the wiki is possible, through the provided channels, such as editing using themes or changing the colors. Further editing of the design or html will not be supported by OIT.
OIT has a main site that they have made "pretty" and tinkered with the design. This main site includes links to the knowledge management sites that include the information and these pages are made within the standard Confluence parameters.

Confluence allows users to export the information as html, PDF, or Word document. Can export an individual page or the entire space.

Only Collier (OIT) has rights to manage the groups/users/administrators.

Confluence has a WYSWYG editor (rich text) and a Wiki mark-up editor. CJ does not recommend using html.
Can copy/paste from a Word document but cannot import like in GoogleDocs.
To include an image on the page you will need to import/attach the file to a page. Must re-attach an image if using it on multiple pages.
Attachments, when uploaded, are tied to a specific page, they are not uploaded to a central directory.
Headings and excerpts are easy to create.

Confluence offers a lot of plug-ins and OIT is willing to experiment if there is a feature that we would like added to our wiki space.
Mediawiki is no longer supported by OIT. If the library chose to use MW they would need to install, configure, and maintain separately.

News feature is more like a blog than a wiki page because it is date-centric. Includes a calendar to display all news entries. News entries cannot be displayed by hierarchy, only by date. (Question: can they be displayed by tag?)

Page-in-page feature: Create one page of content then show smaller version of this page within a second. Content in smaller version will update automatically if original page is updated.

The main page can display the entire hierarchy be default or it can be closed and expandable.
There is a theme that includes left hand navigation. You can add links to the LHNav. Moves editing tools from along the top of the screen to the LHNav, where they collapsed and need to be expanded to view all options. Everyone working in the same space would see the same theme.
The OIT space has a customized navigation, used a plug-in called Theme Builder. CJ does not recommend this.

Most users of the wiki at UMBC have been knowledgeable and CJ has not had to do much training - we would probably have to do some level of training because of the varying levels of technical expertise at the library. May want to set preferences for some users to the rich text editor vs. the wiki mark-up, more like Word and less intimidating for new users.

CJ has not heard of other depts using GoogleDocs. There is concern within the group of hosting our materials on the Google server, versus through the wiki/Confluence on the UMBC server with UMBC support. Michelle says that there is virtually no support for GoogleDocs only user forums.

Comments are always to set to up "on" space-wide; can set them to "off" or for users only on a page by page basis or for individual users.

Favorites feature: can attach a link to the homepage (the individual users homepage or the space homepage?) and you will be able to track the updates.

It is easy to restore a page to a previous version, although this is an admin right.
A page can be deleted, then admin can restore the page or permanently delete it (purge). After purge it cannot be restored.

Unlimited number of admins.
Admins can export the whole space, set themes, restore pages to previous sessions, and restore or purge deleted pages.
We can create many spaces and share content or link between the spaces.

Do we want to have format-based spaces (reports, meeting minutes) or department spaces? - CJ recommends using only one space for the library and effectively using the hierarchy to manage the formats or dept materials. It would be nice to have different spaces so that we could have separate admins (dept heads); it is possible to set different permissions for individual pages.

Labels, also commonly called tags
May consider setting up hierarchy by dept then using tags/labels to organize by format. This would allow us to pull pages together in multiple ways.
May want to set up a tag hierarchy or thesaurus. CJ - also important to allow users to use their own tags for pages. Everyone sees the same tags on a page regardless of user level or permissions.

It is not easy to generate XML code so that information on one page will display elsewhere and be automatically updated. There is an API, XML, Soap (??), but CJ has never done it. You can have RSS feeds which would show most recently updated pages.

All Confluence users can have their own personal wiki.

Discussion:

CDMWG will be assigned admins and all lib staff will be added as users, for now.

Group prefers Confluence to GoogleDocs

Discussion about bringing group decision to LEC or Library Assembly. Next LEC meeting is March 25 (every two weeks). Next Library Assembly is March 19 - decide to present at April assembly instead.

Lindsey will complete I: guidelines and post on wiki.

Janet and Heather will begin to populate the Confluence wiki; cataloging group will be pilot group.

Michelle will begin to convert Blackboard wiki to Confluence, explore procedure, complications.

Confluence website: http://www.atlassian.com/software/confluence/
There are two Confluence demonstration webinars next week:
March 4, 4pm
March 5, 11am http://www.atlassian.com/software/confluence/webinar.jsp
Interview with a Johns Hopkins employee about his experience implementing and using Confluence: http://www.atlassian.com/software/confluence/casestudies/johnhopkins.jsp