Paper textbooks for music theory are more often than not accompanied by a CD-ROM to play musical examples, present drills for ear training, and so on. Less common is an entire textbook delivered exclusively via a computerized hypertext platform or CD-ROM. It would seem a logical step for many textbooks, especially in music, to adopt this format, given the high cost of traditional paper books and the enhanced multimedia capabilities a computerized platform can deliver. With this move to a digital learning environment, though, are various programming and interface design dilemmas. With a web-based hypertext platform, one must design an interface to be an efficient method of delivery for text, graphic images, musical examples, and sound. Any such application needs to be easily navigated and intuitive for the user, and the hypertext linking structures must be carefully developed to allow the desired amount of flexibility. Topics must be clearly ordered and accessible from one central place in each chapter. The addition of other desirable features in a computerized theory book–scores, easily accessible glossary, worksheets, interactive drills, playable musical examples, etc.–also require thought and ingenuity.

My point of departure will be the interface design for Models and Embellishments: An Interactive Guide to Music Theory, a CD-ROM learning environment I am developing with J. Timothy Kolosick of the University of Arizona. It is a hypertext, web-based application accessible in Netscape from a main page showing the table of contents and links to the glossary and anthology. Each chapter appears in a new window, opening on top of the existing one. In this essay, I will discuss some of the basic design features of the interface, as well as the HTML and Javascript routines that make them function. A basic knowledge of HTML and Javascript will be helpful to the reader.

All topics found in Models and Embellishments are accessible from the main page. Chapters are listed in order, and from this page users may also access the printable anthology of scores and the glossary. The original window for this page remains intact; all other functions accessible from it open in new windows.

All links for the individual chapters access a Javascript function that opens a new window.

You pass to it as parameters the name of the HTML file you wish to show in the window and also the name of the new window. This particular function specifies that the new window will be resizable, scrollbars will be omitted, it will fill the height and width of the user's screen, and it will be positioned in the upper left corner of the screen.

When accessing the printable anthology from the main page, the openPrint3 function is used:

This function is similar to the previous one, but indicates that the toolbar will be included at the top of the new window. This page shows a list of links to scores in the Adobe PDF format that open in the same window, and it is necessary to include the toolbar so the back button could be used for navigation after viewing a score. All files have the .pdf suffix, and the Adobe Reader plugin is automatically activated when users click on the link. The file is then displayed in the Anthology window, from which the file can be viewed or printed out from the Acrobat Reader application.

All chapter windows feature the same basic design. A vertical navigation bar on the left side allows the user to access any portion of the chapter at any time. The remainder of the window is divided into two horizontal frames: the top frame on the right always features the musical examples, the bottom shows the text explaining the examples. Dividing the window in this way is fairly simple. A frameset is declared that provides the vertical navigation bar at the left side of the window. The remaining vertical frame displays another frameset dividing it into the horizontal top and bottom frames.

We also found it desirable to provide navigation among the content showing in the top and bottom frames. Each example or text page shows a right or left arrow link allowing users to flip to the next or previous page. This minimizes the amount of scrolling users must endure. And, any mention in the text of a musical example in the upper frame is also a hyperlink. So, for example, if the user reads about the differences between two examples, he or she may toggle back and forth between them in the top frame without changing the explanatory text in the lower frame.

The interactive drills allow students to test their knowledge about recently introduced concepts. In the top frame of this drill, the user sees a set of question marks inside eight squares. When the mouse is passed over these question marks, a musical example appears. First, we preload the image files.

This code creates an image object for the C major triad shown in the drill and is repeated for each of the examples. Then, this code allows the image swap.

Here, the images for the mouseover and mouseout situations are specified. We also show the image that will appear initially (with the <IMG> tag) and we give the object a name so that we may reference it.

In the bottom frame users are provided with a table showing drop-down menus and a set of answers for each example, a button to play the QuickTime sound files, and buttons to check their answers. This drill may be used as an ear training drill when the user doesn't take advantage of the mouseovers in the top frame. Or, if the student wishes to drill only on notation, the sound may be excluded.

The next routine evaluates the answers and provides feedback to the student.

For each popup menu, we use the following code:

The loop checks each answer entered against the correct answer in the arrays. The selected answer is assigned to the variable "ans," which is then compared in a series of Boolean operations to determine its status as correct, incorrect, or no answer entered. Based on this evaluation, an appropriate message is then displayed in the text box under each popup menu. Each popup menu is an element in a form, which allows us to access the value the user selects and store it in a variable for comparison purposes.

The code does all this for each example and displays the appropriate answer or feedback. The other types of drills use similar Javascript code to check arrays of correct answers and to display appropriate feedback to the user.

On each navigation bar in the chapter pages is a link to the printable and playable worksheets. When each link is clicked, the list of worksheets appears in the right frame as a series of links. When a link for a worksheet is clicked, two things happen. First, the worksheet itself is displayed in a new window in PDF format. This new window is created by the following code, which calls the openPrint function and passes four parameters to it.

Two windows actually open here. The Panel Window is a small window that contains only the QuickTime movie and its play button. The Worksheet window displays the actual PDF file for viewing or printing. The size of the Panel window is specified in the function. The Worksheet window is also specified, but it is moved slightly to the right on the user's screen to make room for the smaller Panel Window. Finally, if the variable" Sound" is false, there is no sound file for that example and thus no small window is opened.

Probably the most challenging code for the book was for the glossary. The glossary needs to be accessible from anywhere in the application. From the main page, for example, users can see scores in the anthology and thus might make use of the glossary to explain musical terms, tempo markings, and so on. The glossary also needs to be accessible from each chapter, for obvious reasons. Because of this desire for accessibility, I decided to make the glossary open in a small window of its own that could remain in the background or come to the front when needed. The glossary window contains two horizontal frames. The upper frame contains a set of alphabetized links that control the content in the bottom frame. The lower frame is where the actual definitions are displayed for each letter. Users then scroll until they find the definition they want.

The biggest problem comes in maintaining a database of glossary definitions that can be accessed from anywhere in the application. This is not particularly difficult if one accesses information on the same page, but becomes problematic when attempting to access data residing on another HTML document. To solve this problem I used <FORM> elements and the Javascript parent/opener properties.

Each definition resides on the main index.htm page as the following type of entry:

Here is one entry in the P definitions. The definitions for each letter are contained in a single form, and the definitions are stored as values of a series of hidden inputs. This allows the value of each input to be accessed from another page as a form element. Each form has as many inputs as are needed to store the definitions. When a letter is chosen in the glossary window, this function is called:

Since the page on which the definitions appear is generated dynamically, the first thing that happens is the initialization of this new document. "Parent" refers to the frameset containing both top and bottom glossary frames, and "document" refers to the HTML page being created in the bottom frame. The "write" command writes to this document.

There are two loops in the function, one of which is called depending on the page from which the glossary window is called. If the user is opening the glossary from the index page, the first loop is entered. When this occurs, the definitions are accessed with the "parent.opener" portion of the code, which refers to the window that opened the parent frameset. If, however, the glossary is opened from one of the chapters, the second loop is accessed. This code contains an additional reference to "parent.opener" to access the definitions. Since the user is opening the window from a different window, we must find not only the opener of the glossary window (the chapter window), but also its opener (the index window).

Once the proper window is referenced, the variable Def is assigned each definition in turn for the selected letter. Then, they are written with the "write" command in the bottom frame, the document is closed, and the user can scroll to the desired definition.

The interface presented here is fully functional and a demo version is now under review. Other features will be included in later versions: I am writing code that will allow students to make notes about a specific chapter, add a title for reference purposes, and then e-mail the note to themselves or a friend. This note pad will float, similar to the glossary window, and be accessible from anywhere in the application. We will also be adding the capability to play the scores in the anthology with accompanying MIDI files with Apple's QuickTime Musical Instruments extension. This feature will provide users with the ability to hear all the scores, although the playback will not produce the quality of a professionally recorded compact disc. As the CD-ROM evolves, I expect further refinements and improvements as reviewer and user feedback is noted. In the very near future, we hope our application is not the exception, but the mainstream learning environment for music theory.