Jim’s Development Blog

I am making good progress on the web server for the Museum Archive software project. You can see a brief write-up here (PDF file). I hope to release a beta version by Labor Day. Feedback is appreciated.

Users of the premium edition of the Museum Archive software project are invited to contact me in order to participate in testing (playing with) the first version of the project’s web server. This is version 0.1. It has very limited functionality – it is really just a quick example to see how this approach might work.

You can see your Objects in a web browser. You can sort by column. You can use a locator field to jump to a specific Object in the list. That’s it – no viewing of the Object’s details, no editing, no reports. Just a simple browse list with basic locator and navigation controls. But it is a start. If you want to see how it works, contact me and I’ll send you a link.

The web browser produces the web pages served on the fly. There are style sheets and javascript code that make it work, although I am totally ignoring the user interface style at the moment. Eventually, you’ll be able to apply your own styles and make this look the way you’d like.

How does this work?

The Museum Archive software database exists in a folder on one of your computers on your network. This computer has an IP address. In this example, let’s say that the IP address is 192.168.1.20. Other computers on your network have similar IP addresses; these addresses typically all begin with 192.168.1, with only the last segment having a distinct value.

Continuing with our example, let us say that the Museum Archive software is located on the computer’s C: drive in a folder called Musarch. When you are working on that computer, the path to the software is C:\Musarch. You can allow other computers on your network to share the contents of the C:\Musarch folder, and they can access those contents by specifying a path from their machine to the shared folder. This is how you set up a multi-user environment to use the software.

What we want to do is place a new application in the C:\Musarch folder. This new app is a special purpose web server; its job is to watch a specific computer port for web requests and answer those requests when appropriate. The web server coexists with the rest of the Museum Archive software, and it accesses the same database. In this example, the web server watches port 88 (normal web browser traffic happens on port 80). When you start the web server app, it just sits there waiting for a web request to show up on port 88.

[I always advise you to backup your data before trying anything new, so back up now.]

Download the zip file from the link I provide in the email (you’ll get an email from me after you tell me that you are interested). Extract the contents to the installation folder of the Museum Archive software package – be sure to enable the use of folder names for the extraction process. You’ll end up with a musarch_server.exe file in the installation folder, as well as a new sub-folder called web. Double-click on the exe to start the server.

If you start a web browser (Internet Explorer, Firefox, Chrome, Safari, etc.) on the same computer that holds the Museum Archive software, you can point to this special web server and see your data. In the address bar of the browser, type this:

http://localhost:88

Localhost is a way of telling your browser to look at this computer, and the port number following the colon tells it not to use the default port number (80).

You can access this same web server from another machine on your network. Start the browser and type in the IP address of the computer running the web server, and don’t forget to add the port number. In this example, you could go to a computer with an IP address of 192.168.1.25, start the web browser, and specify this address:

http://192.168.1.20:88

Your web browser will communicate with the web server running on the computer with the IP address of 192.168.1.20 (the computer with the Museum Archive software on it).

[Note: Your firewall might ask you for permission before making these connections.]

Eventually, you can open up access to this special purpose web server to the whole internet. This involves setting up your router to forward requests made on a specific port to a specific computer on your network and so on. We won’t be dealing with this now. This example is merely a “test of concept”, something to see if I am on the right track as I attempt to develop a web-based component for the Museum Archive software project.

Is this safe?

The special web server can only do the tasks that I build into it, so in that sense it is safer than a general purpose web server such as Apache or IIS, which are designed to do many things and are much more flexible. Because the backend of the Museum Archive software project does not use an off-the-shelf database engine, it is not vulnerable to the usual tricks and techniques favored by malicious users. Plus, you can simply close the web server app at any time.

This example is meant to be used on your own computer (localhost) or, at most, on your local network. It only displays data. Play with it and let me know what you think.

If your organization works with local museums, historical societies, schools, or other nonprofits and you would like to take a look at the premium edition of the Museum Archive software project, send me an email (support AT musarch DOT com) asking me for a review copy. I want to get the word out about the package, and I want to get feedback from as many users as possible. Maybe you’ll tell a few friends… 

Are you a member of the AASLH (American Association for State and Local History)? Are you expecting them to give you the latest information about software packages to help you organize your collection? You might be out of luck if you want any meaningful guidance from them.

I was searching for Museum Software on Google a few weeks ago, just to see where the Museum Archive software project turned up in the search results. It was nice to see two entries in the top ten. I then read the snippet underneath the number one entry, which said:

Approved by the American Association of State and Local History for museums and historical societies.

I thought that was cool, so I decided to contact the AASLH to see what it took to be “approved” by their organization. A week went by; no reply. I sent a follow-up email; once again, no reply. After another week or so, I forwarded my question to other staff members listed on the organization’s web site. Finally, I received a nice reply from one of them. The reply was nice in the sense that it was pleasant and polite, but the substance of the answer struck a nerve:

“At this point, though, we endorse only one software and that’s [a well-known software package]. We have had a formal partnership with them for many years…”

The bottom line seems to be that the AASLH does not review software packages or provide information to their members about new offerings in the collection management software field. They have a business relationship with a single vendor, and it is that vendor’s package that they endorse and push on their site.

The software they endorse is probably a fine product. I’ve never used it, but I’ve heard that many organizations do. The problem is that it is rather expensive, particularly if your organization has limited resources (which includes most small nonprofits and local historical societies). I specifically started the Museum Archive software project to address this concern. Why should a smaller organization have to struggle to catalog their collection using a spreadsheet or a text document these days? My software is designed to help them, and you cannot beat the price (It’s free!)

Wait a minute - aren’t you selling a book?

As to my own motivations for this project: Some might object by pointing out that the premium edition is only free to people who buy the book, so it is not really free. Two points: First, the basic edition is totally free. Second, you really must have never tried to sell a book. Anyone who has knows that the less-than-generous author’s share of the sale price is not a real motivator. My share of the proceeds thus far means that I have made almost one dollar per hour on this project. I should report myself to the Department of Labor. Not to mention that I spend more time setting up premium users and answering their questions than I care to count.

Wrong or just cheesey?

I have no objection to a nonprofit organization like the AASLH cutting a deal with a vendor and making a few bucks. The part that bothers me is that they allow the vendor to claim “approval”, and they themselves talk about “endorsing” a product, in a way that implies testing and evaluation and comparison with other offerings. Why not say to AASLH members, “Hey, we like this product and if you buy it, you also help us out financially. But you should know that there are other options, including these products…”

A nonprofit organization exists to fulfill a mission. The AASLH mission statement talks about providing leadership to its members. If by “leadership” they mean to “influence or induce”, then this software endorsement arrangment makes sense. Call me crazy, but I think that most nonprofits use the term “leadership” to mean something different: to “guide in direction, course, action or opinion” - to provide information to stakeholders to help them in their own missions.

With the AASLH’s current practice of limiting approval and endorsement to their business partner’s product, they have no shot at providing their stakeholders with much needed guidance. You might say that the AASLH’s mission is impossible.  

I’ve recently had a number of comments from users about the Museum Archive software not providing a needed field for an Object (such as, “I wish it had a spot for the book’s author”). Of course, most of the time the needed field does exist, but the user was not aware that it existed on the Object Details form. I guess a lot of people populate the Objects without ever using the Object Details button, which is a shame because the Object Details provide the real guts of the data. The Object “header” form is the same for every Object, but the Object Details form is specifically designed to match the Object’s category. The Object Details form for a piece of Art is competely different from the Object Details form for an Oral History recording, and so on.

Don’t forget to click on that Object Details button! 

I’ve been looking at various technologies, trying to decide how to port the Windows version of the Museum Archive software project to the web. I think I’ve settled on a plan… Using the same database and a small Windows-based web server application, the new web version will allow authorized users to edit and maintain the database through their web browser, and it will allow guests to view a sub-set of the data, all without any downloads or hassles with installing apps.

The technology I’ve chosen uses jQuery and css - giving you the ability to customize the look and feel of the pages served, even though those pages are ‘virtual’ - created on the fly by the web server app. It will be pretty cool. The downside is a fairly long development schedule; I’ll keep you posted on my progress.

It’s been 14 months since I released the basic edition of the Museum Archive software package (www.musarch.com). Despite the fact that (due to the nature of the software) it appeals to a very limited number of users, and despite the fact that many organizations are already using other museum collection management software, there has been a steady number of new users. More than 700 people have downloaded the basic edition, and the feedback I’ve received has been all positive.

I am currently investigating the development of a specialized web server for the Museum Archive database. This server could run on any Windows machine and serve pages over the internet (if you provide an accessible IP address and port) or over a local area network. Check back for more details on my progress.

If you have a Museum Archive software success story that you would like to share, please let me know. Spread the word about the package, and link to the web site if you can. Thanks!

When I first designed the Museum Archive software, I thought I might provide a method to play audio or video files from within the program. After playing with the idea, I realized that there were too many variables (codecs and so on) for me to spend time on, so I shelved the idea. Recently, some users have asked for the ability to link to PDF files, and that prompted me to take another approach to my original idea.

Version 1.4 (premium edition) gives you the ability to link to other file types from within an Object, and to open the referenced file from within the Museum Archive software. I simply pass the file name to Windows and let the operating system open the file (the same way it does when you double-click on the file name). If Windows can open the file, you can now open it from within the software.

The image section already opens the associated image file and displays it. Version 1.4 adds that capability to Audio Tracks, Oral History Tracks, and Video files. Each of these Object Detail forms now has a Play button. Don’t forget, Windows is doing the work, so you have to set up the operating system to use the appropriate software to open that type of file (that is, you have to associate the software with the file type).

I’ve extended this capability to any type of file - DOC, PDF, XLS, whatever. I’ve also added the ability to associate an external file to every Object Note. You simply place the associated file name in square brackets at the beginning of your note text, and the software will pass that name on to Windows to open it up. The Note form also has a file look-up button which will place the file name in square brackets for you. As one user commented, this is like having an email attachment for every Note - easy to keep track of and view.

Thanks to Charles Browne and Jeremy Robson for the very helpful feedback. The upgrade is available at the site (www.musarch.com).

Version 1.3 of the Museum Archive software project is now available at the site (www.musarch.com). This release takes care of a few minor cosmetic items, but it also introduces two new features.

First, it seems that many users are entering similar items into the database, and it gets to be a pain to fill in the same values in the Object table time after time. For example, a group of objects might all have the same General Category, Category, Collection, Source Category, Status, and so on. Users have requested a way to automate the process a little by filling in those fields during subsequent Insert operations. I’ve added a check box on the main Object browse:

If you check this box, the software will remember your entries and try to use them on subsequent inserts during the current work session. It forgets these “default” entries as soon as you exit the software, and it only remembers some of the settings on the Object header form - fields that are likely to have the same value from object to object. You can turn it on and off at will. I think this will help to speed up those repetitive entries.

Another feature that people seem to really want is the ability to store the images associated with objects in the database. Prior to version 1.3, the database recorded a link to the image. Now, you have the choice of using a link pointing to a separate image file or telling the software to copy the image into the database. You can mix and match this option - use some links and some internally stored images - it is up to you. The path to the image file is still stored in the database if you choose to store the image internally, but that is more of a reminder. Once the image is stored internally, the software no longer uses the link.

 As images are stored, the database size will grow accordingly, so keep this in mind.

These two new features are available in the premium edition of the software.

The installation (setup) files for both editions now include a copy of the import/export utility and a copy of the read-only viewer. The premium upgrade installation file is password protected; registered users can obtain a password by writing to support@musarch.com.

This new version makes a small modification to the database structure, so be sure to backup your TPS files prior to installing the new release.

I sent out a short poll to registered users of the premium edition, and the majority of respondents want the capability to store images in the database, as opposed to the current method of storing just the link (path and file name) to the image. That is the feature I am going to work on next, followed by the ability to create web pages (html) directly from the database. Check back here for more news about the project…