A Generalized Description of Making A DDM

A working draft - version 2003.02.11

Chris Condit ccondit@geo.umass.edu

Department of Geosciences, Univ. Massachusetts-Amherst

Funded by National Science Foundation Grant #NSF-DUE-CCLI-0127331

Let me talk my way through what it will take to make DDMs, and put some time gestimates on it. This is a "working draft" version of a document that I will be revisiting and updating periodically over the next year or so. In no way should it be confused with the forthcoming "Cookbook" which will include the details of how to make DDMs, down to the mouse-clicks to make on different palettes.

I'm going to assume we're dealing with a reasonably computer savvy DDM-maker, who has all material ready to go (more on the material below). By that I mean, they can work moderately comfortably with CAD programs, image processing programs, and word processor and spreadsheets (if needed for data intensive DDMs).

DDM-makers should download the programming environment (named "Revolution") from www.runrev.com. You'll be able to use it, and go through the tutorials it has without buying it (this is known as the "Starter Kit", which once you pay to own it expands the number of lines of script you can program beyond the Kit's 10-line/object limit). Note that educational institutions pay pretty nominal prices for it, especially true since one site license is good for multiple operating systems.

The DDM-maker will need to go through the first three Revolution tutorials, built into the programming environment. That should take about an hour each (3 hrs). In this process you'll get a hands-on idea of what Revolution is, how the GUI (Graphical User Interface or programming environment) works, and what "object-oriented" programming is, especially using the "almost English" programming language called "TranScript".

The open-source DDM-Template you'll be using will be down-loadable from my web site, once I'm more comfortable with the final configuration. The reason I haven't posted it yet is that I don't want users creating something which they then have to go back and revise when I change the code/configurations of the template.

The Template is organized as a series of Windows (called "stacks"), each containing one or more cards, on which different objects can be placed. The main objects we need to be concerned with are text "fields", and an object within which to place pictures, maps etc, called an "image". The idea here is that the DDM-Template includes a framework of components ready for you to insert your own parts, as you make your own DDM. These parts are prepared outside of the DDM environment, for example in word processor, CAD or image processing programs. For example, if you have a text for a guidebook, there is a stack for guidebook articles that includes a scrolling text field. To insert your text you open the appropriate stack and it's card, displaying the wanted field, copy the text you want to insert from you word processor program, and paste it into the field.

The way I've organized the Template is to call up all visual material (images, movies) from folders or directories into which they are sorted according to type. Thus these material are not part of the program, but rather are displayed in the program when asked for. For example, the "home" screen is an index map. A click on a label showing the location of the detailed map will activate it's script (code) which will open the "Map" stack (window), and fill it's previously empty image on the card with a jpeg image of the detailed map, called from disk (or CD or web site).

This concept of using code or script attached to labels or fields is essential to understanding the structure of the DDM-Template. Each object in Revolution may have script attached to it. In this case, the DDM uses the script attached to these objects, as activated most commonly by a mouse-click on it, to display images or data. These script "links" are usually attached to vector objects (like fields as in the above example) that are placed at given locations on top of the bit mapped image or map. They are stored in the program, as opposed to the jpegs which are brought into the program temporarily. I call a group of these scripted links that is associated with a given jpeg an "overlay". When an image or map is to be displayed, the DDM opens the appropriate display window (stack) fills the "Image" object with the asked for bit-mapped jpeg, and then copies the appropriate overlay to the top of the image. Creating these overlay links is the most time consuming process in making a DDM. Another kind of a link is the camera icon; the DDM-Template includes a "Photo-Icon" Maker capability, so that these can quickly be made, complete with code, and pasted into any given overlay.

The main kinds of overlays include those associated with Maps and those associated with Images. Two distinct stacks, the "MapOverlays" and the "ImageOverlays" stacks exist in any DDM. Each map and image must have an associated card on which it's specific overlay is stored, in order for it to be displayed by the program. For example, when a new image is initially added to the DDM, it's overlay contains a "plain" overlay with no "custom" links in the form of fields, or camera icons. The DDM program itself, as used in the Revolution programming environment provides the capability to add the linking objects and, once added, to store the newly modified overlay back into the DDM.

Other stacks, such as the "Index Maps - Home Screen" stack contain only one card and, when opened display an image (here a jpeg of the index map for the DDM). As you create your own DDM, your job is to create and place named text labels in the appropriate location using the RR GUI (Graphical User Interface or programming environment). Because these label objects are attached to this window only, they don't have to be stored as overlays elsewhere in the program (unlike Maps and Images).

The DDM includes "ClickLists" which are scrolling lists on which each line contains a description of a part of the DDM. These serve two purposes. The first is to provide a "Table of Contents" for the DDM. The second is to provide access to each item on the ClickList. For example, the ClickList of Maps contains a list of all maps included in the DDM. Each map is assigned a distinct number (e.g. "M#001", and the line in the ClickList includes a brief description of what type of map it might be (e.g. "Topography") and what area this map contains (e.g. "NE Quadrant"). A mouse-click on that line will open the appropriate map. Additional ClickLists include one for "Articles" (e.g. guidebooks, field trip guides, or perhaps map text), and one for "Images". The DDM maker will need to enter text into these ClickLists, one line for each map, image or guidebook article. The line contains information about each. For example, the line in the ClickList of Images contains a number (e.g. images are numbered with a "S#" preceding it's number, S#001, S#002 to S#999), a three letter designator ("img" for image, "mov" for movie, "qtm" for QuickTime movie), a file name, and a brief series of key words describing the image. The key words are displayed at the top of the image window when it is opened, and are also seen as "Tool Tips" when the mouse is placed over camera icons.

Once all text, overlays and data are added to the DDM-Template, a "Stand-Alone" is made of the DDM. This is done using Revolution. Once created the Stand-Alone can be run on the specific machine it was created for with no additional software (except QuickTime in the case of movie display) needed. For example to create the DDM-NE, I simply tell the application builder, through pop-up palettes activated in Revolution, to build Stand-Alones for both Mac and Win32, point the builder to the appropriate DDM file and let it run.

A look at the "Application Overview" of Revolution will show these stacks [image of this to be added].

I assume all material has been prepared (e.g. having all images or maps saved as jpeg images). Below I list that material and how long it might take to insert a "nominal" version of each into a DDM-Template.

That would include:

An index map - 10-30 min., to add labels with links , a min each.

Any/all detailed maps ready to go (if you have various thematic version you mush be sure they are identical in scale) - if they include say 20 camera icons, a field trip route and say a dozen field Trip Stops, say a 60 min. each.

All images likewise saved in jpeg format - if each have a couple of camera links to add and a few labels, say 10 min. each

Any map legends also in jpeg format - a simple legends - say 10 min.

Any cross-sections saved in jpeg format - if simple, with no links, say 5 min.

Any correlation of map units likewise saved (may be different from map legend, may not be...) - if it includes labels for search routines to find, each label will take a min. or so to add.

A list of figure captions, all written out in a word or whatever word processor file.- as long as the file name precedes each and is followed by a --tab (that is dash dash tab), and each caption is contained in a single paragraph (logical line), , say 5 mins to insert

Any field trip guide text likewise saved as a word processor file. Say five min. to insert, to add links, a min. each to set.

For more analytical DDMs, any data is stored as tab-delimited ASCII files. - the time-sink here is to format the header to the table, and make sure the columns align. I note that vrsion 2.0 still in beta will have new spread-sheet like table capability.

MORE NEEDS ADDING HERE….


Bug reports and suggestions to ccondit@geo.umass.edu
Updated 2003.02.11


Go to DDM Homepage


Go to UMass Geoscience Faculty Index


Go to Chris Condit's UMass Home Page