Posts Tagged ‘libraries’

Finding web tools for collaboration for Hordaland State Library

Monday, September 27th, 2010

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.

Three men at dusting books 1913 - Librarians in the information age have so many more sources to show patrons.
Three men at dusting books 1913- Librarians in the information age have so many more sources to show patrons. (Photographer unknown)

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.

Organic Groups, Calendars and new hosting perspectives

Friday, March 19th, 2010

It has been awfully silent on this blog about the work on Drupal sites for the Hordaland libraries. Quite the opposite were my work days. I have had a number of meetings with the three library consortia I have been mainly working with, and soon there will be more classes for the librarians who are becoming editorial groups for their own social media-ready web sites.

New modules have been tried. I am very satisfied with using the Organic Groups module for making subsites for the involved community libraries. Although they don't use the full spectre of social media capability og the module, it is quite powerful for managing the workflow and adding more areas for publishing. That way both the collaboration between the libraries and the profile of the individual library is preserved and managed. If the libraries will have use for this, their patrons can authenticate on the site and get notified about new articles and events. Maybe they will even have forums or other features for their users one day. While Drupal is somewhat more complex to administer than WordPress, it makes it so easy to add new features and areas without programming in PHP. Two library consortia needed calendars that would show the individual libraries events as well as the whole consortias events in different views. This was easily deliverable with Organic group calendars, the Date and Event modules  and the Views module. I learned a great dal about Views, which has a learning curve. But once you understand the essentials (what means what), you can do powerful reorganizing of content and list every type of content in new ways.

One difficult issue was the question: Where to host the Drupal sites? The library department in the Hordaland County Council could not do it in-house and had special needs: The Drupal core and the modules had to be kept up to date for them. It took me a lot of time to research which companies could do this for a reasonable price. We ended up finding a collaboration of two smaller vendors of free software for libraries. Which gives the department both the possibility to get support in Norwegian, as well as the vendors are experienced in the field of library catalogue software, as both vendors sell installation, migration, hosting and support of the Koha and Evergreen ILS. So, Libriotech and BibLibre will take on this task in the coming weeks.

It may not sound like a big deal, but having capable people ensure that the sites are running really wasn't easy to manage and secure the future of this project. It also takes some pressure of my task list as the updating processes will not take that much time anymore when we will come into the critical phase of launching the sites for the public to see.

Testkatalog – under construction

Tuesday, December 16th, 2008

Del av den nye jobben min er å finne frem til en løsning for det aktuelle problemet: De fleste folkebibliotekene i Hordaland har nettsteder som er vanskelig å oppdatere. For å forbedre kommunikasjonen mellom bibliotekbrukere og bibliotekarene skal jeg lete etter en CMS som er både moderne, enkel å bruke, vil eksistere lenge. Etter det og andre faglige kriterier har jeg utarbeidet en testkatalog, som jeg gjerne vil ha tilbakemelding og tips om.

For å se hvordan programvarene som skal bli testet forholder seg i virkeligheten har jeg skaffet domenen folkebiblioteket.org. Der er for tiden utviklingsfeltet, og jeg jobber med forskjellige scenario hvilken programvare man kan bruke til hva. Strukturene er ikke endelige og kan endre seg hele tiden, men så snart den skal beta-testes sender jeg en e-post til alle interesserte.

Prosjekt - Tilbud om felles nettsted til folkebiblioteka

Testkatalog: CMS som egner seg til bibliotekenes behov

Preambel: Kravene som rettes mot en Content Management System (CMS) retter seg etter spesifikasjoner i prosjektplanen. Kravene kan bli utvidet eller innskrenket etter samtaler og møter med folkebibliotekene i Hordaland. Testkatalogen skal spesifisere utfordringer til programvaren og i gjennomgang av katalogen skal det bli synlig og transparent hvilken programvare egner seg mest - og hvorfor. Til tross for skjematisering skal ikke inntrykket vekkes, at avgjøringen er fullstendig objektiviserbart. Det foreblir en viss subjektivitet, men tross alt skal programvaren som blir valgt være brukbar og håndterbar.

Lisens:
Hva betyr det?

Installasjon:

Tid brukt:
Enkelt eller tungt?
Hvorfor?

Språkfiler:

Bokmål:
Nynorsk:
Installasjon enkelt eller tungt?
Hvorfor?
Dekker språkfiler både både frontend og backend?
Kvalitet:

Oppgradering:

Tid brukt:
Enkelt eller tungt?
Hvorfor?

Er installering og oppgradering automatiserbart?
Hvordan:
git
subversion
annet, hva?

Hva kan programvaren fra starten av:
Blog
RSS
Statiske Sider
Meningsmåling
Podcast
Filhåndtering
Mediefremstilling
Wiki-funksjonalitet
Katalogintegrering
Annet, hva?

Moduler/Plugins:
Enkelt å installere
Språk
Kostnader?
Utvalg (biblioteksspesifikk?)

Brukbarhet:
Brukere ser bare I menyen det de kan gjøre
Admin-funksjonene er enkelt å skjønne
Brukerfunksjonene er lett å skjønne
Tid å opprette og lage en artikkel
Stavekontroll?
Lett å legge media til artikklene
Avansert brukersystem
Backend har hjelpesider (som kan utvides?)

Sikkerhet:
Sikkerhetshull i fortid:
Mulige sikkerhetsproblemer:

Community/Langvarighet:
Hvor lenge fins programvaren?
Har utviklingen vært stabil?
Konstruktive konflikter?
Destruktive konflikter?
Hvor mangen hovedutviklere?
Inklusjon av nye utviklere?
Lett å kommunisere?
Oppdaterings-syklus?

Konklusjon:

Plone – and what libraries could do

Monday, November 24th, 2008

A colleague of mine mentioned Plone in a meeting about the on-going project I recently blogged about. He introduced me to Plinkit, a project started in the USA, where small libraries are provided with a Plone-based CMS to suit their web publishing needs. So far it seems to me, that some problems are being solved by that:

  • They can easily publish.
  • They can integrate a search form of their catalogue into their site.

I have visited some of the sites, and it seemed to me, that there were still some problems remaining, which come naturally to small libraries and which are caused by small money and time budgets:

  • Boring default designs
  • Few updates
  • Few information about the specialties of the libraries.

The last point seems the most important one: Local libraries need stronger profiles. They need to advertise their knowledge and their profound and demanded specialties, be it local history and archives, good knowlegde of local artists and writers - or the like. To stay an important focus point in small local communities, they are most likely toexist further if they develop to an important meeting point and work space for locals who have special information needs. I would like to give some examples. Does your area have:

  • Strong tradition of handicrafts? Let the local people get together in the course room of your library, advertise it and let everybody know about it. Ask the group, if they have suggestions for very important learning media about what they are doing. Support them with information about what others do. Take pictures and blog about it on your site. This could be worth a podcast.
  • Different groups who like to read books and discuss? Stay in touch and get them what they need. Advertise there meetings at your library. Let them have a closed or open wiki on your site.
  • Writers? Let them gather. Let them write. Let them read with the public. Establish a demo place, where people can display their work and check it out from the library. (As done in the Bergen public library in Bergen, Norway. The site is in Norwegian, but you can see a picture here.)

Okay, I could go on and on with this. I think you got the main point. The library could and should evolve from a place where you only gather written knowledge on dead trees on shelves. And develop itself to a place where you gather people to make knowledge while using it. Libraries have a tradition in this, it is not a new thing. But it becomes vital to the existence of libraries - and especially small local libraries - to focus on this kind of service. Or rather than service: This kind of knowledge cooperatives.

Looking at some of the plinkit libraries only made me think. I haven't been looking into plinkit too much, which I will do further on. Until then I'd really like to hear your thoughts. Please comment. :-)

Open Source ILS

Friday, November 14th, 2008
Library Spiderweb by

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.

Library towards 2.0

Friday, November 14th, 2008

Due to a new job, I will spend the next eight months thinking and working on better communication solutions for public libraries in the Region Hordaland, Norway. You can find some of my ideas on the site Library & Development. You can follow the postings occuring in this category by subscribing to a category-specific feed as well, if you wish. That way, you can avoid listening to my blabbering about other stuff. ;)

Thats another thing I wanted to say: I will also go on sharing stuff that I am interested in otherwise on my blog, but not on the front page. My posts will probably vary between my native language German, Norwegian (bokmål) and English. I hope, you understand. I will try and make this easier on you when I find a solution for the language problem, that isn't too much of a hassle.

Libraries and Open Source CMS

Friday, November 14th, 2008
Drupal Pumpkin
Drupal Pumpkin by Mike Gifford

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:

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.