H O M E

Jonathan Cooper Manager of Information, Art Gallery of New South Wales, Sydney, AUSTRALIA

Quantum Leap: How HyperCard is used at the Art Gallery of NSW

Originally published in MACinations (Club Mac, Sydney, Australia), March 1997

Many people already known that HyperCard is a great tool for creating quick-and-dirty solutions, prototyping applications relatively easily and of course for creating interactive multimedia. But it can't create 'real', multi-user, database-type applications, can it? This is what I thought too, until about a year ago. I work in the Public Programmes Department of The Art Gallery of New South Wales. Some readers may remember an article I wrote in 1991 about two HyperCard-based booking systems I wrote for the Art Gallery of New South Wales and the National Gallery of Victoria. Well, these indeed worked, but they had four serious shortcomings:

Firstly, in order for the data to be presented in a daily view and a booking view, each system consisted of two stacks: Overview and Details. Thus, much of the data was unnecessarily duplicated and speed was compromised as a result of frequent switching between stacks.

Secondly, there was a fixed number of time slots on the daily overview cards for each kind of booking. This was partly due to the need to have column-type fields on the cards (1) and partly to prevent overbooking. However, it proved far too rigid (for the Art Gallery of NSW at least): Frequently, a booking would have to be put in one slot when it was really meant to be in another (but which was already being used). This made the daily overview very hard to read.

Thirdly, owing to limited screen real estate, different kinds of bookings had to be on different cards. In fact the Overview stack was interleaved: E.g. Monday's secondary services card, then Monday's primary services card, then Monday's other activities card, then Tuesday's secondary services card and so on... The only way to see all the bookings for the one day at a glance was to compile a printed report.

Finally, each system was restricted to one computer only, because currently the only way more than one user can access a HyperCard stack at the same time is if the stack is locked, and that is hardly practical for a booking system!

The first three shortcomings (two stacks, fixed time-slots and multiple cards for each day) ended up having a single solution:

Each day card would have a single, large scrolling field (in a fixed-width font such as Courier) containing summaries of each booking, one per line, appearing to form columns (see Fig. 1). The full information for the bookings would be contained in a hidden field, again one booking per line, with "fields" delimited by a special character such as ASCII 217 ("" in Palatino or "" in 9-point Monaco). When the user clicked on a line in the summaries field, the computer would get the text of the corresponding line in the (hidden) bookings field, open the appropriate blank template card (in the same stack), pull the line of booking data to pieces and put these pieces into the correct fields (2) (see Fig. 2). If changes were then made to this booking, clicking the "OK" button would put the text of the fields back together again, return to the day card, put the new, replacement booking line into the (hidden) bookings field and put a new, replacement summary line into the summaries field.

The fourth shortcoming (single user operation) was a little harder to solve. A few years ago, I read about a Canadian HyperCard add-on called epsiTalk that promised multi-user stacks. (Locking happens at the card level, rather than for the whole stack.) This seemed to be what we were looking for, so we bought a five-user licence. Unfortunately, it turned out to be extremely complex and not very stable. If you wanted to 'multi-make' a stack that had its own scripts (apart from simple arrow buttons) you were supposed to modify the scripts by hand, using special epsiTalk commands and functions. Needless to say, things didn't work as they were supposed to and, because much of the working of epsiTalk was hidden from view in external commands, it proved to be virtually impossible to debug. (Fortunately it wasn't that expensive!)

With the release of HyperCard 2.1 with Apple Events support, I knew that here was a way to create multi-user stacks. What you could do, with a bit of scripting, was have a normal server stack on one Mac and a number of special client stacks on other Macs. Each client stack would consist of only one card (for each background). When the user clicked a button to go to another card, instead of changing cards (there would only be one anyway!) it would "request" the data for that card from the server stack. Once the data had arrived, it could be put into the appropriate fields. Of course, the server stack would have to be open whenever a client was requesting data and "find" commands would have to be actually carried out on the server. This meant that it would be impractical for the server's HyperCard to be accessed directly because clients would be continually causing it to go back to the server stack and flip from card to card as it found text. However, in our situation at the Art Gallery of NSW, one person (the Booking Clerk) accesses the system 90 per cent of the time or more and, because the phones can often 'run hot' during busy periods, speed of operation is very important. Therefore, it is better if this person can access the system directly.

The solution I came up with was to give each client a full copy of the stack. Whenever a day card was to be opened on the client, the time (and date) when it was last modified (stored in a hidden field) would be compared to the time (and date) last modified of the same card on the server. If the server's was later, then the data for that card only would be copied across. Whenever any booking details were changed (new, altered or deleted booking), instead of updating the server immediately, the client would create a temporary file on the server's hard disk and 'inform' the server that an update was pending for that booking. When the server had been idle for a set period of time (say one minute), it would check for the existence of any of these temporary files. If any existed, the server would process then delete them. Until that time, any existing bookings for which an update was pending would be locked, both for the server and for other clients (3). An added advantage of this method was that a client stack would still work (with some provisos) even if the connection to the server were lost.

Thus, the next generation of booking system (now called Museum·ARTS-for "Museum Activities, Resources, Time and Space") was created. It has been in use at the Art Gallery of NSW since May 1996 and over 10 000 bookings have been made on it. Other features of Museum·ARTS include:

• Sub-bookings, or bookings within bookings. E.g. when a school group books seats for an advertised study morning or when a parent books places for his or her kids for a school holiday workshop (see Fig. 2).
• Repeat bookings. E.g. For booking Volunteer Guide meetings every second Monday.
• Cloning, or using one booking as a basis for others.
• Extensive printing functions. Including confirmation slips, daily reports and reports on commitments for individual staff members.
• Statistical functions. Consisting of general statistics, statistics by topic or exhibition and statistics by geographical area, broken down according to types of groups and whether or not they received a service (see Fig. 3).
• Auto-entry of school addresses, phone and fax numbers, using an external database.
• Automatic and 'one button' back-ups
• Booking filters on Day cards, to show only certain kinds of bookings if required, according to group type, space and topic or exhibition.
• In-built help-contextual and indexed.

The 'competition'

Last year (1996), the Art Gallery purchased a Windows product for scheduling events in large organisations (convention centres etc.). Although initially chosen to control major functions such as corporate dinners and exhibition openings, particularly where catering and invoicing were involved, the expectation was that our department should also start using it for school and public programmes bookings. It soon became clear however, that it was much too complex for 99 per cent of our needs (requiring almost 100 extra key-strokes or mouse-clicks and navigating through a total of twelve screens just to make a simple booking!) and completely unable to handle sub-bookings (an absolute essential for us). Negotiations with the developers are continuing as I write this, for modifications to be made that would meet our requirements.

In my opinion, the reason why this commercial software is presently unsuitable for us (or any museum in fact) is that it was created by professional developers who have made assumptions or guesses about their end users' needs. In some cases, they have guessed correctly, but in other cases, such as ours, the match between needs and solutions is sadly incomplete. I strongly expect that, if the software is eventually modified 'successfully' and we do switch over to it, there will always be shortcomings which we will have to put up with.

Creating Museum·ARTS, and seeing it being used successfully in a real life situation, has convinced me more than ever that HyperCard as a software platform is without equal (at least on the MacOS) when it comes to creating solutions to problems you are personally familiar with. You don't have to be a professional programmer to create useful HyperCard stacks: you are probably either the user yourself or the users are people you work with. As a result, you get instant and constant feedback and the software can be continually improved as required.

A similar case could be made for FileMaker Pro (in fact a use it myself). However, while FM Pro is extremely well designed and 'friendly' for a database (especially a relational one), there are still things that either can't be done with it or which could only be achieved in an extremely complex way (called a "work-around"). It is, after all, a database. HyperCard however, is -... Well, what is it exactly? HyperCard's open-endedness, which is sometimes described in negative terms, is actually its biggest advantage. You dream of what you want to do with a computer and then you just create a stack that does it!

______

Footnotes:

1. Booking number, group name, topic, year level, number and staff

2. With some "lock screen" and "unlock screen" commands, this could be made to appear as though the data was already there.

3. Locking of a booking would also occur whenever any other networked copy of the stack (either server or client) had the same booking open-to prevent two people trying to change the same booking at the same time.