We're trialling MediaWiki as a prototype repository for more
"visitor-friendly" information on exhibits. It currently looks a bit
rough, but it's still officially at the prototype stage.

The installation software happened to "like" our server, so it only took
about half an hour to get up and running.

The museum has one of the old "standard" Museum collections systems (and
needs to keep using it for certification), but it's a bit of a pig. The
catalogue was never intended to be publicly viewable, so the format of
the existing entries is rather dry and not really suitable for
presenting to the public -- even if we knew how to interface it. It has
a lot of fine-detail entries that members of the public won't want to
see, and a lot of major items that they /will/ want to read about aren't
yet listed, as the indexers painstakingly work their way through the
entire collection, in order.

Another challenge was that the museum is extremely "dense" - it has a
lot of very small items packed very closely together, which makes
conventional labelling problematic. Ideally, we'd like the sort of more
"conversational" background info that you might normally see on a museum
plaque written into an online system that museum staff or visitors could
access, with additional touches like QR-code "launchers" on the cabinets.

So, basically, we needed second system that we could use for holding and
displaying this "less formal" background information on selected
exhibits and displays, starting with the big items. It didn't need to be
complete, or to interface with an existing database. There was a lot of
interestng information in people's heads, or tucked away in the paper
archives that wasn't ever going to be in the "official catalogue", and
we needed some sort of public "notepad" to let people jot this stuff
down and make it available. The museum is also a tourist information
point, so it was also legitimate to want the ability to add local
information that didn't fit into any conventional museum database
structure or schema. There's a famous Banksy mural opposite - that's
worth adding as useful tourist info, even though it's not owned by the
museum or even on museum property. We needed a multi-user,
multiply-indexed, free-form, general-purpose knowledge-store that wasn't
committed to any particular categorisation system.

We also needed something that wasn't //too// difficult to learn for
non-technical volunteers, had decent online documentation and community
help, was robust, and had some sort of recognition factor (and nice
reassuring brand-name) that wasn't going to give Museum staff the
heebie-jeebies, or intimidate volunteers, or deter other people from
learning how to maintain the system if the project leader upped and left.

MediaWiki's recognition factor was a big plus-point -- Wikipedia is
something that most people have heard of, and that makes volunteers more
willing to invest time in it. They already know roughly what it does.
We've even made a point of not changing the default layout templates
(yet) ... partly as an exercise in expectation management. Content is
still a bit patchy at this point, perhaps we might do an overhaul and
give it a slicker interface once the information-set is more solid. Once
all the main exhibits are listed, if some shiny new open-source option
reaches release-quality status, we might even manually transplant the
contents over so some other system. But for now, we need something that
works //now//, and lets people throw as much information onto the system
as quickly and easily as possible, with good indexing, and lets us track
progress and edits on a per-user basis, with version control.

Spam is an issue, but there's the option of creating new user-group
categories by editing the setup text file, and restricting editing
rights only members of categories like "Museum Staff" and "Invitee",
with only "admin" users able to bestow those group memberships to other
users.

The downsides of MediaWiki relate to the way that its development is
focused on the needs of Wikipedia (and to a perception that some people
have that Wikipedia is somewhat dubious as an information-source). Lack
of WYSIWYG editing is a downer (although it's useful that the editor
strips out MSWord formatting nasties and only pastes "raw" text).
WikMarkup is fine for things like headings and bullets, but sucks for
tables. There's no default support for image-linking to create graphical
buttons (although you can get extensions for this). Templates are useful
for adding pre-formatted info boxes and the like, ad-hoc, to pages (and
altering them globally) with the nasty scary coding encapsulated and
hidden away out of sight of most editors (and protected if necessary),
but ... all sorts of coding things work differently inside templates,
for security reasons related to Wikipedia.
Mediawiki's categories are great - they let you add multiple freeform
categories to any page, and automatically generate listing pages for
each active category, so they're a bit like superpowered "tags", but ...
linking to category pages is awkward, and you can't browse the existing
category list when you want to add a new one.
There's also no default feature that lets casual users add tags easily,
or add star ratings or the like, to say that this is a favourite exhibit
(unless you can find a suitable extension that does what you want). You
can get extensions for some cool things (like embeddable forum panels
that can be added to any page), but the quality of the extensions is
variable. There's a QR code generator extension, but it doesn't yet work
on the latest MW release. Exporting data from MW isn't obvious.

Conditional coding in MW is stinky. There's no conventional
"if/then/else" or "select/case" (or data arrays), unless you install
more extensions. I've had to do some of the ugliest, hackiest, most
inefficient coding of my whole life to get some simple-looking things
working flexibly inside templates and working with global parameter
lists. It looks as if the MW markup system has grown piecemeal around
arbitrary exceptions that have been added to protect WP from this or
that security risk, in ways that'll have some programmers hitting their
heads against the desk and screaming.

And because the system is query-based, you'll need to do an "htaccess"
hack to get neat and tidy wikipedia-style URLs, you can't really do
offline editing from a local copy, and there's no obvious way to install
the resulting site on a simple non-networked Museum terminal (which
would have been nice). Perhaps an "export as a portable HTML-page
website" tool exists somewhere, but it's not obviously part of the
default package.

So. By no means an ideal solution, and for a lot of cases, definitely
the /wrong/ solution. But if you approach MediaWiki as a great big
multi-user hypertext notepad-thing, with decent per-user and per-page
edit-tracking and undo functions, which gives you an almost instant
mini-Wikipedia for free, it does pretty much what you expect it to do.

Eric Baird, volunteer
Brighton Toy and Model Museum


On 18/08/2011 14:12, Mia wrote:
> On 18 August 2011 13:58, Joseph Padfield
> <[log in to unmask]> wrote:
>
>> Would anyone consider using "Mediawiki" as a CMS ?
> Two issues spring to mind - one, the usability of the authoring
> interface is a real issue for non-geeks, and secondly, the 'anyone can
> edit' content ethos isn't taken well in many publishing contexts.
>
> I'd be curious to know if anyone has overcome these issues to use it
> as a CMS (as in content management, not collections management). The
> Science Museum experimented with an object wiki, but it was before my
> time so I'm not sure how the initial decant of objects was done to
> know if it was able to hook into a collections management system.
>
> Cheers, Mia

****************************************************************
       website: http://museumscomputergroup.org.uk/
       Twitter: http://www.twitter.com/ukmcg
      Facebook: http://www.facebook.com/museumscomputergroup
 [un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************