typo(s), tendency and text

In 2008 I contributed to the department I work in by introducing wikis for collaboration on texts and documents, aggregating and sharing knowledge about projects. Before that, there were lots of Microsoft Word documents floating around, which was a problem when the number of people contributing to a document became too big. Keeping track of changes was difficult, and when a deadline came close, lots of emails were sent and people tried to write on the document all at once.

There was also a wish to give the collaborating libraries in four regions of Hordaland a tool to work similar with their documents, and on their projects and events.

Enter DokuWiki

I rolled out 4, eventually 6 instances of DokuWiki for library groups in the regions, our own department, a book project within the international library organization IFLA and for one local library. All of the wikis were closed for internal use and their content was visible for logged-in users only. DokuWiki is well-documented and the localization to Norwegian Bokmål (Nynorsk is required for official communication at my workplace, but this was an internal tool, and it was free) is acceptable.

DokuWiki is a Wiki software written in php, which most shared webhosting services support. The main difference to other big wiki applications is, that is doesn't  store the content in a database, but rather in plain text files on the server.  If you use the hierarchical "namespaces" in DokuWiki for sorting your content, DokuWiki puts your pages into folders named after the namespace they are in. (This makes it really easy to use those textfiles in real geeky ways over the command line.  But thats just a sidenote.)

In practice using the DokuWiki installation worked for a while, but there was a huge difference in how frequent it was used and for what purposes by certain users.

The wikis used by the collaborting libraries were used a bit or a lot in the beginning, but after a while people stopped using them. The IFLA-wiki helped to make the process of finding new examples of best practices in libraries for library guidelines editable for all contributors in an international group. But after its purpose was fulfilled, and the project done, it wasn't used anymore.

Two problems: Purpose/design of the tool & missing WYSIWYG

The wiki of the Hordaland State library was not readable or writable to the general public, but all colleagues in the department used it to update their tasks in one long document. Working with one long document was what people were used to before, but the wiki didn't help much to do that.  Certain co-workers used it more than others. Those who used it the least, said that they found it diffcult to use the WYSIWYM (what you see is what you mean)- editor for the wiki pages and that it was difficult to remember the syntax, when they were not using the wiki often. Most people are used to WYSIWYG-editors for documents such as Microsoft Word provides. While this is perfectly inderstandable, many WYSIWYG-editors in web applications are known to produce horrible html-code, especially if they have a wide range of operations you can do with them. The existing WYSIWYG editors for DokuWiki match that description - and my time budget too limited to do something about it.

The purpose of what this tool was used for and the way it was used did not really match its design. The head of the section encouraged everyone to use the wiki, but required only the use and updating of the long reporting document before internal meetings. What happened was: The document grew very long. Typical deadline problem: Everybody wants to update the section about their work 30 till 5 minutes before the meeting.

DokuWiki makes it possible to edit a document sectionwise, but everybody edited the document at once. Since DokuWiki tracks changes in documents in order to show differences between the versions and to make an RSS feed of the changes, only one user at a time can edit a page. So people grew frustrated because they could not use the report page when they had to, because a co-worker was working on it.

The reason why I write this in detail is not to complain about the users, my co-workers. I take the difficulties of working with those tools seriously. Which is why after almost two years we decided to take a second look at what tools we wish and need.

Audience and organizational setting

Some difficulties to mention here are:

• The rules and regulations which public service organizations have to behave when giving buying goods or services companies
• Public service in Norway has to give access to records in general, unless certain circumstances are met under which the citizens' privacy has to be protected.
• Not everything that is being worked on is ready to be disseminated to potentially everyone on the planet at once. Personal learning or work documents should be able to be protected.
• The corporate brand and identity of the mother organization Hordaland fylkeskommune and its main communication channel on the web, hordaland.no, should not be overruled. Official communications by the library department should still be posted there.
• People working in the department: Their privacy and right to opt out of their work being cached, stored and fulltext searchable. This is a particularly complicated topic, where I am not sure yet where I stand, how to solve it or if it is sovable.

At the same time, especially in Norway, libraries have policies that make them about distributing information, knowledge and cultural narratives and technologies freely to all citizen to enrich a free democratic society. The Hordaland State library works towards enabling the libraries to continually fulfilling and developing their services and skills to meet those goals. So, opening up discussions and the dissemination of information of how we work, what we work with and which ideas we come up with would hopefully help the other library aiding organizations, librarians in the region, colleagues from other places on the cultural sector understand and learn from what we are doing.

Several other public service organizations like the City of Oslo are right now working on a social media strategy, and the Norwegian Department of administration and ICT has published Guidelines for communication in social media based on an open discussion in their blog.  The Norwegian administration discusses initiatives openly.

More specifically in the library field, there has been a library blogosphere for years now, the library lab tries to help public libraries to develop and adopt new technologies, and aids in implementing social applications to their data and media collections.  A good place to start if you want to dive in to the norwegian library blogosphere is this handy collection of library and library blog rss. Some libraries and librarians meet their patrons on facebook, twitter and other social networks.

Purpose

There is a need for collaboration on internal collection of facts, document, processes and progress of projects for official reporting purposes. But their is also the need to share knowlegde, write tutorials and discuss ideas, questions and problems within the process of developing libraries.

What I see as the most difficult task is to embed the reporting part into a communication tool, that is also open to all audiences. If you use a fine granulation of open for all/closed for member permissions system, this might be difficult to understand/remember.

Possible solutions: multiblog cms

We are still discussing options for which software (our preference is something php-based, free and open source software) to use. When we set the reporting task aside for a while, and look at the other things we want to do, we probably want a multiblog system like WordPress's BuddyPress (example install for a creative writing group at Bergen Public Library) or something like Drupal Commons/OpenAtrium, two Drupal-based distributions for collaborating in groups.

I am in favor of a tool, that we can own, as opposed to a tool that is a free service provided by a company we as a department use as long as the company lets us. Using a blog/cms software for the core discussions, and making it possible to let discussions on facebook and twitter get through to us, or let our discussions be linked to on facebook is my favorite way of doing this. That way we won't lose our data on terms of a third party. But I think this process needs some more thought, and some deeper diving into examples, and we need to include the opinion and the way people want to collaborate into realizing the way of communicating.

Library Spiderweb by Yvonne Loomis

During my research I got to read about Internet Library Systems (ILS), which seems to be the new term for a new stage of Library systems. As I understood it, they should integrate cataloguing and web publishing for libraries in a better way. As of now, many libraries have the problem that they have implemented expensive library catalogues with huge effort, but that they now with the growing need for better librarian-patron-communication, seem to disturb the image of a whole identity that libraries feel they should create.

I came along two Open Source ILS: Evergreen and KOHA. I can't really say much about them at this point, but the Biblioteklaboratoriet seems to have looked into it. It's rather interesting, that it's being translated into both the norwegian written languages, Nynorsk and Bokmål, and that there is also a discussion going on about the - probably - proprietary data standards.

Open Source formats would be a real ease of the problem of integrating publishing and media search, which are both parts of the duties that libraries have. There are teams working on modules "MARC" and "Z39.50" for Drupal, but I can't say yet, if it is a workaround for the problem.

Libraries are a public service, and tend to be very interested in Open Source publishing. Recently I am looking into open source content management systems for small public libraries in the region where I live now. Since the solution has to be usable, stable and sustainable, I try to focus on the three to four most stable communities on this sector. These seem to be:

• Drupal
• Joomla
• Typo3
• WordPress

My first anticipation is, that Typo3 might be a little overweight for the purpose of building a cost effective and stable solution that will last the next years. And WordPress might be a little underweight. But could still be viable: There are so many people using it, and there are methods to automate updates of websites, that people within my range have had good experiences with.  My gut feeling says Drupal, though it will be a lot to learn for me. Joomla isn't bad, either. But there are so many modules, themes and plugins that are non-free. And although I totally understand people have to make a living by writing software, I have to make this project reliable for the future. Not for all future, but for the next 3 till 4 years.

Another point is, that I feel that Joomlas administration panel is much more complicated than Drupals. On Drupal you have a lot of functions already build in, and if you simply set them together, the site already after fifteen minutes seems to get more and more structure. And the admin panel is not only easier to look at, it also makes all the built-in functionality visible very soon.

Don't worry, dear Joomla, WP and Typo3 evangelists. I will get into some testing, before I decide. And I will not base the decision on gut feeling. But until then, I have to think and evaluate a lot.