typo(s), tendency and text

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.

A good friend of mine decided to spent one of his precious invitations for the Google Wave Sandbox on me. Expectations to that new service were high after  seeing a video that promised to reinvent email, wiki, personal pages, IM as communications channels, and renew them in a way that made things easier, more collaborative and not as fractioned anymore.

I have tried it, and I must say that my expectations were not met. Without all the bots now flooding Google Wave, wave is somehow a very slow realtime web-based Multi-User-Chat. My first thought was: This looks a little bit like the realtime chat-feature in that dinosaur ICQ version from almost ten years ago. Only in colour, and with maps, and...Well, probably not bad after all.

Another expectation is also not yet met: Wave being an open protocol, based on XMPP, which enables everyone to set up their own wave service. Similar to email, for instance. Imagine email not being implementable by each and everyone with a webserver. That would, obviously, be very bad. Or would it? So if Wave claims to be the new black email+, it can not only depend on Google as an organization, can it? As cloudy as it may be. As I hear, the open part of the waveprotocol is not yet very wave-ey. Which is sad. I hope, that point, too, improves.

Since I lowered my expectations, though, from a very high level, I find it a quite useful tool. I hope, the Google Wave developers will manage to make it a bit faster, though. The user experience is definitely lacking there.

Another reason for my disappointment probably was, that my experience is based on having only a few people to communicate with. At first, there where my friends. Most of them are quite savvy with communication, so we fiddled a bit, but we did not have much to collaborate on, since we live so far apart and don't really have projects we are working together on right now. But more and more people got on Wave, and in the last week I made contact with librarians in Norway, and not least (most of the) co-organizers of and speakers at the "Free and Open Libraries" conference about F(L)OSS software in libraries next week in Bergen, Norway. So we started collaborating, and suddenly the whole map inclusion in wave made a whole lot more sense.

The second  most interesting thing are public waves. I have searched for waves matching my temporary, or overall professional or private interest. I found interesting waves:

Open wave for librarians using Wave

Female Geeks

NaNoWriMo

Hackerspaces FAQ

And many more public waves. Something that I did not find, though, was a public wave for knitters, and it took off very fast from zero to 101 wavers contributing as of today.

Knitters on Waves

Although in the more tech-savvy wave topics people try to figure out things before they participate, many of they waves with specific topics end up becoming undertaken by people take about the Google Wave sandbox and about figuring things while they are at it. This is tiring, and I find myself not participating anymore where Waves become so bloated and cluttered with dozens or even sometimes hundreds of such messages.

What has not happened yet is the development of a certain code of behaviour, what people called "netiquette" (or something) before for this service. Some places people are concerned about it. Most places they are not. Gina Trapani and Adam Pash from Lifehacker have written the Complete Guide to Google Wave. And there is probably more to come. Not only explanations, but also features.

I am still waiting for things to get more exciting. I didn't use twitter much the first six months I had my account, and now I twitter a lot. With all the tummy-ache that follows, relying on a centralized server. So I really hope it grows on me, because XMPP is great, and I think it could become very useful.

I vår avsluttet jeg en test av ulike serverbaserte publiseringsverktøy til bibliotek, og skrev en rapport. Jeg testet, med hjelp av andre bibliotekarer, tre forskjellige fri programvare CMS: Drupal, Joomla og WordPress.

Siden den gangen har min og andres erfaring bekreftet resultatene. Jeg vil gjerne publisere den, for å muligens få tilbakemelding på den. Kan hende jeg har oversett noe, eller andre kan bruke min fremgangsmåte eller noe av resultatene i sin arbeid.

Her er rapporten til nedlasting i PDF-format:evaluering av ulike publiseringsverktøy

Siden vi i Hordaland fylkesbibliotek får for tiden mye nyttig fra Drupal-samfunnet, vil vi selvfølgelig gjerne gi tilbake hva vi kan. Noe som ofte er undervurdert av utviklersamfunn selv i veldig oppegående åpen kildekode-prosjekter er brukerdokumentasjon, ikke minst til end-brukeren.

Jeg er invitert til Fjell folkeboksamling i morgen for å gi opplæring i bruk av Drupal til bibliotekarene, som blir da redaktører på sin egen nettside. Jeg har derfor laget en redaktørhåndbok for å støtte denne prosessen og for bibliotekarene å ha den aller viktigste informasjonen lett tilgjengelig i deres travel hverdag.

Eventuelt er det interessant til andre Drupal-prosjekt å bruke og forandre teksten på håndboka. Den skal få en GPLv2-lisens, så gjerne forandre alt mulig, så lenge du pusher tilbake til Drupal-samfunnet. Og ta bort mitt navn og organisasjon, bare gi oss kreditt hvis du synes det er nødvendig. Last ned filene (zip, ca. 850k med bilder): Kilde til redaktørhåndboken

A team member from Siruna presented his companies solutions to a bog problem: Making useful, light and flexible mobile websites in Drupal.

The problem is that there are so many different cell phone models out there, with different screen sizes, colour capabilities, browsers. The networks differ from being very slow to very fast. Which leads to 35% less likeliness of completing a task with mobile browsing than otherwise.

• So it is important to deliver relevant content adapted to these situations automatically. Mobile tools need to be able to:
• Detect the device
• Switch to the adaption for this model
• Aggregate functionality and content to this situation, and
• theme it accordingly

Then the presentation went on to demo open.siruna.org and OSMOBI (which is in alpha) and to show how it is possible to make mobile websites automatically using Siruna's service, supporting the Garland theme and colour picking module.

Another talk that I have been to was about how to communicate design and workflow on a new site in its planning stage, by Roy Scholten. The presentation basically promoted the method of building paper models and sketch on the computer only at a very late stage.

It was interesting to see some of the paper modules, one of them made into a "screen"cast of how the site would act if the user started clicking on buttons.

Ægir is a drupal install combined with several modules and drush that helps installing new drupal sites, maintaining existing ones, backs up and rolls back to earlier version of a site. With Ægir you can package a certain site buildup with modules and themes, and reproduce it as often as you need it. It provides you a web gui to do all these tasks, so there is little knowledge needed beyond structural knowledge of "what happens if I click this button".

The biggest hold-up for me is that you need full root access to the webserver, which I don't have. But it would certainly make things a lot easier. If we could develop and package a good solution for libraries in Norway, we could make it easily reproducable and accessible to other norwegian libraries.

Tim put the different methods for connecting to and between social networks in relation to each other and explained what was good, bad and ugly about them:

• OAuth
• OpenID
• The Hire
• XRDS/simple
• Activity Streams
• OpenSocial

The talk was not so much about Drupal. But the point was that all those connecting methods were either very useful or very appliable. Tim argued that it was the main interest of nowadays social networks to have a centralized and locked-down user base and to own their data, and that therefore the interest of social networks weren't that big to build good open connecting methods or protocols.

Usecase: Compagnie des Alpes
Tourist attractions with their own branding, i.e. Parcasterix

One directory per site in /sites/*

Hosting: 2 apache servers and 1 MySQL

page views per day in the 100.000s
stable & dev/maintenace cost effective
code for all sites go in /sites/all/

different mysql-tables, admin-account is replicated through all tables (how?)

Boost module?

Although I got up really early, I missed the first minutes of the OpenAtrium presentation. I had a look at an OpenAtrium install earlier this summer when I quickly installed it for seeing what it is like, and it looked pretty nice and useful. If you customize Drupal for your needs, it is a process that takes time, more or less depending on how good you know Drupal and how much you know about what you want.

OpenAtrium is supposed to be an Intranet-like collaborative platform to share Documents, calendars and project/task-data. It is supposed to connect members of a group or a team at work. It looks appealing and it seems to serve its purpose from the beginning. It is one of the few approaches to package Drupal into a product, to download and serve from the beginning.

The talk showed its features, and also adressed the problem in Drupal development/site/feature building, where you have the very centralized repository of core at drupal.org, and the contributed modules, too. But when you want to make packages and built more features around them, there is no existing infrastructure to do so.

What was now implemented by pingvision, who took OpenAtrium by developmentseed in use, was a feature server, that is supposed to provide this function. It didn't get very clear, is this actually solves the problem, or if it is just a temporary workaround. It seems to me, that if OpenAtrium already steps out of the cvs/drupal.org way of working - using git and github - why not make the full step and host everything in open git repositories?