Some thoughts:

(1) Unlike an ecommerce CMS site, a museum system doesn't need to be
able to cope with thousands of people simultaneously changing data.
Viewers won't constantly be changing "stock levels", so "writes" can be
comparatively slow.

(2) It would be nice if exhibit page URLs could be actual HTML page
names rather than PHP? queries.

(3) In fact, it'd be nice if the pages could all be stored on the server
as proper web pages. That way, if someone screws up the software
settings, the site itself will still work. If you trash the software
completely, you still have a working read-only site. Which, in an
emergency, can be edited using a conventional webpage editor (so if a
meteor strike takes out your server, you can move the IP address to
another machine, upload the files, and manually edit in a message saying
what happened).

(4) If the public site is being stored as complete set of HTML files, it
also means that although the editing software might be "operating
system"-specific, a clone of the site will work //anywhere//, under any
server operating system. In an emergency, you can get the site back
online using a spare machine regardless of whether it's running macOS,
Windows or linux, or run it locally in "read-only" mode, on any machine
or network ...

(6) ... including the museum intranet, from a local filesystem, no
server software needed.

(7) ... or on a stand-alone Museum information terminal's harddrive,
regardless of whether it has internet access, or whether or not it's in
range of the Museum's wifi signal.

(8) ... or loaded onto a memory stick or micro-SD card, to run on
tablets and other mobile devices (again, useful when an old Museum
building blocks wifi signals).

For larger museum sites, the exhibits are going to have unique catalogue
numbers anyway, so why not use the catalogue numbers as filenames?

(9) This'd also give the ability to edit and regenerate copies offline,
for tinkering and experimenting with layouts and the like, without the
public seeing. In fact, if the software generates (or works from) a full
set of read-only html pages, why not make the public site a static
read-only copy of the current "live" site? that way, staff could still
edit remotely and see their changes real-time, but the public wouldn't
see the updates on the "public" server until a Museum manager decided to
"commit" the current version by copying the pages over. Using a
"snapshot" as the public copy means that the public site also wouldn't
need to go offline when you were doing maintenance of backups (don't you
just hate it when that happens?).

(10) The database should be able to save all its information in a range
of formats, so that the same information can be accessed and edited
using standard desktop office apps, like MSAccess and OpenOffice. Museum
and "Museum Office" staff ought to be able to import and export
catalogue/schedule/school booking data from MSOffice or OpenOffice, or
whatever other tools they're already using.

(11) The use of standard formats, either as main storage and/or as
automatic safety backups (with or without automatic synch-ing) would
mean that there's less risk involved in merging critical office IT with
the system. If the remote server goes down due to a power cut, or the
net connection fails, then the museum staff can still read (and maybe
even edit) their schedules and school visit calendars locally, either
because their information is stored locally and synched, or because the
system saves offline backups that they can open with standard "office"
software.

(12) Periodic "idle-time" offline backups of as much information as
possible to other formats (Excel spreadsheets, other database formats,
rtf, raw text), just in case someone somehow manages to screw up
absolutely everything, including the standard backups, the server, and
the server harddrive (the "meteor strike" scenario). In case of a
complete breakdown of civilisation, our descendants might still be able
to read the text files.

The guiding principle should be that if the system fails, you should
already have the backups in multiple formats ready for loading into
other programs, without needing to have had the foresight to know to
export those files immediately //before// the unexpected failure. If an
organisation decides to stop using the program and switch to something
else, this should be made as easy as possible.

(13) HTML5 structure tags in all exported webpages.

(14) Semantic tagging.

(15) Auto-embedding of tag and field data associated with images,
directly into the image files themselves. I'm still mildly shocked at
the number of picture vendors that don't bother embedding subject tags,
titles or their copyright info into their images using the tag system.

(16) Support for new and emergent tagging formats such as geolocator tags.

... and probably some other stuff.


Eric Baird
volunteer, Brighton Toy and Model Museum

****************************************************************
       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/
****************************************************************