MWeb™ Online Exhibits

Online Exhibits display in two to four panes in a single browser window. The panes are:

• The optional Etoppane spans the entire width of the window. In this pane you may have logos, titles, and links in this pane that do not change as the user views the Exhibit.
• The Econtentspane is a vertical pane along the left, and shows a clickable hierarchy of terms showing the structure of the Exhibit. Some OEs consist of only a single concept and therefore do not require a Econtentspane.
• The Edocumentpane is a vertical pane in the middle, and shows the HTML text that goes with the Exhibit.
• The Ethumbnailpane is a vertical pane on the right, and shows the thumbnails for the Exhibit. You may show (and we recommend) mini-thumbnails if we can resize your images (more on resizing images). This pane is called the Erecordpane when a Full Record is displayed in it.

In other words, there is one optional pane across the top and three panes under it. This diagram shows the bottom three panes and how their content relates.

Pane widths (and the height of the Etoppane) are determined by you or your designer, and may be either fixed widths or percentages.

You may link a Section to a Document but not to Objects, if this makes sense in your OE. In this case the Document spans both the Edocumentpane and the Ethumbnailpane. Likewise you may link a Section to Objects but no Document. In this case, the Object thumbnails span both the Edocumentpane and the Ethumbnailpane.

Exhibits are their own Content Type (see MWeb Glossary). The data elements required by MWeb for the Exhibit Content Type are:

• Unique ID
• Title
• Unique ID of root Term in the hierarchy for this Exhibit

You may add any additional data elements, such as:

• Department
• Brief summary or introduction (a few sentences)
• Authors, curators, start/end dates, locations -- any other info you want to have

Exhibits are organized for the user by dividing them into Sections. The Sections are an outline of the topics of the Exhibit. Section names are displayed in the Econtentspane and can be a hierarchy with multiple levels. If Sections form a hierarchy, they are displayed indented for each level.

When the user clicks on a Section name in the Econtentspane, the HTML Document in the Edocumentpane changes and so do the thumbnails in the Ethumbnailpane. In other words, a Section is linked to text as well as a group of Objects.

Exhibits may also have Galleries -- which are parts of Sections. Galleries are implemented by links in the HTML Document that cause the set of thumbnails to change to go with what the user is reading; however, Galleries do not change the Document that is displayed in the Edocumentpane. Galleries are incorporated into the term hierarchy that displays in the Econtentspane, but do not themselves show in the Econtentspane. You need not have Galleries, but they are there in case you want to show one or more images to correspond with a part of the text the user is reading. If you use Galleries, you will probably also want one to return the user to the full set of images; to do this, create a Gallery as shown below using as the ID the ID of the term for the containing Section. (You may have multiple links to a Gallery within a given Document, such as each time an artist is mentioned; if so, the Gallery need be in the term thesaurus only once for that Document. If the Gallery appears in several documents, by definition this is several Galleries, not the same one, even if they have the same name and thumbnails. If you diagram the Sections and Galleries as a hierarchy this will become obvious.)

To restate, both Sections and Galleries update the thumbnails, but only Sections change the text the user is reading. And only Sections are shown in the Econtentspane.

So when a user clicks a new Section (in the menu) the text changes and also the thumbnails. Clicking a Gallery (in the text) changes only the thumbnails. The actual appearance of a Gallery link could be a heading, a hyperlink, a graphic, or whatever. This is a decision you need to make as part of the design of the HTML pages for the Exhibit.

Terms are another Content Type in MWeb.

Terms for Sections and Galleries should be organized into a hierarchy for display, and linked to the objects you want the user to see when the Section or Gallery term is clicked. Sections are also linked to an HTML Document (and optionally to a section of a Document).

The data elements required by MWeb for Terms are:

• Unique ID for the term in your system
• Term as you want it displayed (need not be unique)
• Unique ID of the Term's immediate parent
• Document name (filename of the HTML Document to appear when this Term is clicked). Add the filename for Galleries even though the Document displayed does not change.
• Path name (path to the HTML Document to appear when this Term is clicked). Add the path name for Galleries even though the Document displayed does not change.
• Anchor name (optional location in Document to jump to when the user clicks the Term). Add the anchor name for Galleries even though the Document displayed does not change.
• Links to object records whose thumbnails will appear when the Term is clicked
• Indicator to show whether this Term is a Section name or a Gallery name. Use Yes for Gallery and No otherwise.
• (Optional) Indicator to show whether the Term's Document should open in a popup window or in the Edocumentpane. Use Yes for Popup and No otherwise. Terms coded as popups cannot have objects linked to them.
• (Optional) Sort order of sibling Terms (if not to be alphabetical). Use this field to enter a number or some letters to indicate the order a group of Terms with the same parent should be sorted, if not alphabetically. Case is ignored in these sortkeys.

You may add additional fields to Term records if you wish.

The Unique IDs you use for a Term should not change over time, as they are used in the Exhibit HTML Documents to encode Gallery links. However, you may change the wording of Section and Gallery names if you want to without affecting links (but the database will need to be reloaded).

The top node for Sections is the exhibit name. Galleries must also be in the thesaurus, and are children of Sections (at any level you want). You may have any number of Sections and any number of levels. They display as an expandable tree, in which the user first sees the top level of terms and can click to see sublevels.

In addition, if MWeb loads a thesaurus for a purpose other than Exhibits, you must export the exhibits hierarchy separately to a different filename (details on how to prepare linked terminology for MWeb.)

While Documents used elsewhere in MWeb are a separate Content Type, each with their own record, for simplicity we do not follow this model for Exhibits. This saves you a lot of work! Instead the Exhibit Documents are just stored on your server and accessed by their filenames.

Store the Exhibit didactic text as HTML pages (called Documents in MWeb), which will be stored on your server along with any graphics the Documents require. You may have any number of Documents for an exhibit, from one on up, but not more than one per Section. Each Document must have a unique filename. These documents are not part of the MWeb system, and are your responsibility to code and maintain.

If you wish, you can use one Document per Section, or you can use a single Document for multiple Sections. If you use one Document for multiple Sections, we recommend you use anchor tags in the document at the start of the relevant part of the Document for each Section. In that way when the user clicks on a Section term in the menu, the relevant part of the Document will be shown. An anchor tag looks like this:

<A NAME='xyz'></A>

Anchor names must not contain spaces, punctuation, or diacritics. Anchor names must be spelled identically to the way they are stored in the anchor field of Term records, except that case is unimportant.

You may use any HTML coding in the Documents, except that the Document should not include links to other Sections of the Exhibit, because such a link will not update the thumbnail display; but Gallery links are OK.

Here is how to insert a Gallery link in an HTML Document:

<a href='/mwebcgi/mweb.exe?request=egallery&id=xxx'>What 
the user sees to click on</a>

where xxx is the Unique ID in your system for the Gallery Term. Or, if you have a graphic or button for the Gallery, it would look like this:

<a href='/mwebcgi/mweb.exe?request=egallery&id=xxx'><img
src='/mwebgraphics/yyy.gif'></a>

The MWeb Preprocessor (PPS) does examine or load the HTML documents. You may put Documents in various folders; send the folder name with the rest of the data for the Terms.

We recommend that you use an external style sheet to ensure all your Documents look similar. If you wish, we can send a list of all the styles in your current MWeb implementation so you can use the same ones.

You may wish to have terms in Documents that display their definitions when they are clicked. Since the Documents are just normal HTML documents, if you wish to include definitions you may do so using any HTML, DHTML, ASP, or JavaScript technique you wish.

Here are four techniques for displaying definitions. The first three do not depend on MWeb in any way; we include them here to provide ideas. The fourth technique uses the MWeb database as the source of the definitions.

1. Embedded technique

Provide terms and definitions within the text, and use DHTML coding to make the definition appear when the user clicks on the term. This requires a unique ID for each term in a document.

This sentence has a definition for MWeb MWeb is the easiest way to get your catalog on the Web! hidden inside. Click "MWeb" to see it!

The code for this technique looks like this:

<p>
This sentence has a definition for 
<span style='color:blue;cursor:help' 
onclick="document.getElementById('mwebdef').style.display='inline'">
MWeb
</span>
<span id=mwebdef style='display:none;color:red'>
MWeb is the easiest way to get your catalog on the Web! 
</span>
hidden inside. Click "MWeb" to see it!
</p>

Notice we added "cursor:help" to make the cursor a question mark when it is over the term.

We haven't yet coded a way to close the definition, but it can be done.

2. Hints

Hints are the yellow hints that pop up when you hold your mouse over something. These have limited formatting, but you can have multiple paragraphs. There is a problem in that hints stay open only a few seconds, so definitions should be kept to a reasonable size -- no essays. Another problem is that Windows waits a second or so to display the hint, and some users will try clicking instead, which prevents the hint from displaying. Hints disappear when the cursor is moved away. There are no bold, italics, or underscores, which is too bad but we hope a minor consideration for a short definition.

These hints are equally usable within fields in a Full Record for an object, so the same technique would solve both problems.

These are relatively easy to code. Here is an example:

This sentence has a definition for MWeb hidden inside. Hold your cursor over "MWeb" to see it.

Here is how the above hint is coded:

<p>
This sentence has a definition for  
<span style='color:blue;cursor:help' title='MWeb is the easiest way to put 
your catalog on the web!'>MWeb</span> hidden inside. 
Hold your cursor over "MWeb" to see it.
</p>

To achieve line breaks, just enter them into the document. They are respected, unlike those in HTML code. Here's an example:

Here is a paragraph with a term to be defined. Now we continue with the paragraph.

Here is how this example is coded:

Here is a paragraph with a 
<span style='color:blue;cursor:help' 
title='Here is a multiple paragraph definition for the following term.

The definition is formatted as shown here, with a blank line between paragraphs.'>
term to be defined</span>. Now we continue with the paragraph.
</p>

3. Popups

This technique opens the definition in a small popup window

This sentence has a definition for MWeb that will open in a popup window. Click "MWeb" to see it!

To avoid repetitious code, we put the popup function in a separate file, that all exhibit pages can access. If your exhibits already have a ".js" file, use that one; otherwise create a new text file called "exhibits.js" in the /mweb/ folder (where all exhibits can access it). Put the following in that file:

function showdef(def)
{
    var x=window.open('','def',
      'directories=no,height=200,menubar=no,resizable,scrollbars,status=no,toolbar=no,width=350');
    x.document.close(); 
    x.document.write(def);
    x.document.write("<p align=center><button onclick='self.close()'>Close this window</button></p>");
    x.focus ();
}

Next, in the <head> element of each page with definitions, add this line:

<script src="/mweb/exhibits.js"></script>

Finally, where you want a definition to appear, put code of this pattern:

This sentence has a definition for <span style='color:blue;cursor:help' 
onclick="showdef('MWeb is the easiest way to get your catalog on the Web!')">
MWeb</span> that will open in a popup window. Click "MWeb" to see it!

Notice we added "cursor:help" to make the cursor a question mark when it is over the term.

Formatting can be added to the definitions, but quotation marks can be a real problem. Both single and double quotes are needed by the code, so you should avoid them in your definitions (including apostrophes). If they are essential, use similar-looking Unicodes.

Furthermore, the "x.document.write" statement is sensitive to line-feeds. We recommend you do not use linefeeds within any sets of quotation marks.

4. Database technique

Terms can be stored in the MWeb database with their definitions as their own Content Type. This means you would need to maintain the terms and definitions and include them in the MWeb load. In other words, it is similar to a controlled vocabulary.

The definition would be displayed using one of the other three techniques above. We do not show code for this, as it would depend on how your data is loaded into MWeb. This technique might involve some billable programming.

This technique requires the unique IDs of the terms to be added to the HTML Documents. Because of the complexity of this technique we do not recommend it unless the terms are loaded anyway as part of a controlled vocabulary.

Summary

We are not enthusiastic about any of these techniques. However, MWeb supports all of them. The "popups" technique seems like the least of the evils. Be wary of techniques that require unique identifiers for terms (unless you are loading a controlled vocabulary anyway); getting unique IDs correct can be a HUGE problem, and it would be your problem, not ours.

Exhibits link to Object records through their Section and Gallery terms. Thus when the user clicks a Section or Gallery term, MWeb changes the display of Object thumbnails.

The Ethumbnailpane does not have Next and Previous buttons when used for Exhibits, so you will want to keep the number of Objects linked to a Section or Gallery rather small. The rationale for this is:

• Exhibits are intended to tell stories, not replace the other MWeb search functions. We want to encourage curators to pay a lot of attention to authoring the Exhibit with small Sections and Galleries that can be easily comprehended on a computer. An online exhibit is different from having a large physical space to work with. Users want things broken into small sections! Although we are not museum exhibits specialists, this view reflects decades of experience with designing user interfaces.
• Having a hundred thumbnails would be comparable to having a real exhibit with a wall label and then a hundred examples illustrating it. Isn't it preferable to show a few of the most illustrative examples?
• The Ethumbnailpane (where search results are shown) is smaller than it is for a search so space is tight. Anything that can be removed, should be. (Hint: look at MWeb on an 800x600 monitor, which a lot of your users have, and you'll see how little space there is once you allow room for the HTML text. You may see only four thumbnails at a time.)
• Comprehensive groups of records are better found using MWeb's search facilities.
• Even if you have a hundred, there is no need for breaking them into pages, since the user does not have to wait until they display to begin viewing the HTML text or the first images. In effect, the later images are being prefetched for the user.
• Each time you want an Object to appear you must create a link in your database from a Section or Gallery Term to the Object. The more thumbnails you want to show, the more work you will have to do.
• We are trying to change the normal look of MWeb slightly for Exhibits, to keep the user interested -- less "technical" and more fun. It is cleaner without buttons.
• Most important, we feel that showing a large number of thumbnails with buttons to break them into groups destroys the flow of the user's progress through the exhibit. They begin to focus on their interaction with the computer rather than what the Exhibit is trying to say.

You may wish to include some new data fields for Objects, such as exhibition history, locations, or curatorial notes. These show in the Full Record.

The user gets to an Exhibit from an Exhibits button in the MWeb Main Menu. You may also wish to link to specific Exhibits from other places in your MWeb site or your main website. With MWeb's Direct Access functionality, you can link directly to an Exhibit from any web page, so the user does not need to go through your MWeb Start Page.

When the user selects an Exhibit, its first Section that has a Document attached is displayed, plus any thumbnails that are linked to that Section. (Normally you would attach a Document reference to the first Section of the Exhibit, but this is not required. For example, you may not want to attach Document references to the top level of the hierarchy, but only to lower levels.) If there is no Document attached to a Section, it does not display as a link, but only as a static label to show the outline (see this example, in which "Ceramics" is not a link, but its children are).

When a user clicks a new Section (in the menu) the text changes and also the thumbnails. Clicking a Gallery (in the text) changes only the thumbnails.

Because space is at a premium, the thumbnails are shown with little or no text; after all, there is lots of relevant text in the HTML Document in the Edocumentpane. However, the first field in the Image Label (which appears under all thumbnails and images in MWeb and is made from fields you choose, normally the object name) displays as a rollover for each thumbnail. All thumbnails linked to a Section or Gallery display at once with a scrollbar if necessary; there are no pages, no buttons, no messages.

Clicking on a thumbnail shows the Full Record. Clicking on a Full Record thumbnail shows the image in the Image Viewer, just as now.

The functionality outlined herein is part of the standard MWeb. Like all MWeb data, each Exhibit and Term is counted as a record for pricing purposes. Documents, since they are not loaded into MWeb, are not counted.

Special features such as indicating in the thumbnail and Full Record displays which Objects are in the current Exhibit, may be billable on a time-and-materials basis.

It is suggested the exhibit designers diagram the exhibit as they plan it, or at least after they plan it. It should be emphasized that an Exhibit should be conceived of as a hierarchy or outline, in which Sections and Galleries provide the structure, and Documents and Objects are related to these.

Here is an example of an Exhibit outline, showing the hierarchy of Terms as Sections and Galleries, and the Documents and Objects linked to each:

Then you need to decide on the required and optional data elements, and determine where to store all data elements in your CMS and what they should be called in MWeb. Then change your export programs to reflect the new Content Types and fields. We will have to change your PPS and MWeb parameters to make them load Exhibits.

You also need to determine the graphical appearance of the Exhibits, such as pane colors, logos, backgrounds, styles, etc. As with all of MWeb, we can apply generic values for this that fit with your existing website, if you do not want to work with a designer.

This diagram shows how MWeb can link Images to Exhibits. This may be required if you wish to show photos of the installation; you probably want to link these to the Exhibit, not to an Object. MWeb does this by means of records for each part of the Exhibit you wish to picture. The Images are linked to these records for the parts of the Exhibit.