Project: Phase 3

Now time for the final, biggest push of this project. Gather the best of the ideas that all of you have developed and integrate them together into a complete product.

In this document I have listed specifications and guidelines for different aspects of the final phase. But first, some general principles:

• At the beginning of the semester, I envisioned that in the final phase there would be room for working on a variety of special features (say, an editor for the user to put in new texts or tuns). At this point, however, I've changed my mind. I would much rather have you produce a polished and complete version of the basic features than try to add anything fancy. So, the slogan of this phase is get it right, don't get it fancy.
• The main technical task of this phase is rendering the text and music together. A lot of the technical work of displaying the music (alone) and the UI has been done (of course, they need some fixing and a lot of integrating), but laying out the text with the music is what's new.
• The main project-management task of this phase is integrating code and ideas from six different project submissions. As we'll see below, each team in each phase has something to contribute to the final version.
• The main interpersonal task of this phase is working on a team of seven people. You will quickly discover that seven is a lot. You will need to break the group down into subteams, which will probably overlap. By this time in the semester, you will have discovered who is good at what and who works best with whom. Play to your strengths as a group.
• In the list below, you will find that in some cases I will make a specification (ie, requirement) of what to do, and in other cases I will simply make a recommendation In some cases when I've looked at your submissions for phase 1 and phase 2, I feel I can identify a best approach to some aspect of the project, and so I'm going to specify that you use it. In other cases, the best I can do is offer my best guess: From looking at all three submissions, one of the three seems to me to make the most sense, but it is possible that your own experience and research would indicate otherwise. In that case it is up to you seven to make the final decision about how to proceed.
• In light of the previous points, make sure that none of you become territorial about your code or approach to some aspect of the problem; don't take any of my decisions or the group's decisions personally, because choosing one approach is not necessarily a criticism of the alternatives. For example, in the rendering of the music, I am going to specify using the LilyPond approach of the Kendal/Lily/MichaelToy team---not because it is inherently better than the JohnCharles/Daniel homemade graphics or the Neile/Suzanne music font approach, but only because I think it will make the best-looking product in the end.

1. The internal representation

You will need to pick a way to represent the musical information internally in the program (ie, a model). I recommend the model used by Neile/Suzanne in phase 1. It seems straightforward, clean, complete, and conceptually right. Moreover, it is well-documented so it should be easy to work with.

2. The musical rendering

The final product is specified to have its appearance based on the phase 1 submission of Kendall/Lily/MichaelToy. It should be noted, however, that there were a handful of mistakes or weaknesses in that submission (no grace note support, the bass clef was off by 1 note...), so the other two teams' work should also be consulted. I considered the submission of JohnCharles/Daniel to be the champion of completeness and accuracy.

3. The input files

From my experience in evaluating phase 1, I found the Neile/Suzanne submission easiest to use and understand. (The JohnCharles/Daniel submission was similar, but a little less human-readable.) So, using that format is my recommendation. However, there might be factors that I'm overlooking that would bear on what input format you use. For example, it might be that the format used in the Kendall/Lily/MichaelToy submission is based on some more standard notation, or is easiest to use with LilyPond.

4. The user interface

This is the hardest for me to specify. There are things I like in each submission. The UI that is most visually appealing is that of the Lily/Daniel team. However, some parts of that UI need to be reworked for space efficiency. The Neile/MichaelToy submission achieved sharp space efficiency by using drop-down menus and a separate dialog box; the JohnCharles/Kendall/Suzanne submission had a button to hide or restore the controls. Both approaches have their advantages and liabilities. You must decide how to integrate these ideas or to look for a third approach. You should do further usability tests to help you decide.

Several features from the submission of JohnCharles/Kendall/Suzanne are now going to be specified for the final product:

• The UI of the final version is specified not to have a "display" or "render" button. Instead it should use the the submission JohnCharles/Kendall/Suzanne as a model for how the controls should interact with the display panel: once enough information is selected, the display should update automatically, without the user having to click on an extra button.

• Use the submission of JohnCharles/Kendall/Suzanne as a model for how the lists of texts and tune are organized: specifically, all text and tunes are listed, but the ones with the same meter as the current selection listed first; secondary to that, they are alphabetized.

• The final product is specified to have a search feature, as found in the JohnCharles/Kendall/Suzanne submission.
• The window of the final project is specified to be scalable as in the JohnCharles/Kendall/Suzanne submission.

Two out of three submissions used check boxes to select stanzas. That seemed to work to me. I highly recommend the check box approach, unless a new approach can be found.

See the section on "Features" below for a few more specifications for the UI.

5. Back end and storage

Two out of three groups in phase 2 used a database for storing text and tune data. That seems like the "right" approach to me in principle, although the teams that did this also ran into difficulties with the interaction between Derby and SVN.

Neile has suggested to me that sqlite be used instead. I recommend that you use a database and that someone at least looks into switching from Derby to sqlite.

6. Features

Everything in the following list is a specification

• The music and text must be rendered together, appearing as they would in a typical hymnal.
• The UI should be highly reactive, meaning that the display should update as soon as the user has selected enough information to display a new text/tune combination.
• The text and tune information (meter, author or composer, date, ...) should appear somewhere on the screen. See the UI of the Lily/Daniel submission as a model (although theirs could be streamlined a bit).
• Assume rhythmic unison of the voices. That is, there will be no syncopation of the voices in the music. All parts will be singing the same syllable at all times. (If we have time, we might revisit this, but I doubt we will.)
• Make sure you can deal with double meters. To determine if a text is in a double meter, you need to look at its rhyme scheme. If the periodicity of the rhyme scheme allows it to be set to a regular meter tune, then it should be consider to have that meter. If the periodicity of the rhyme scheme requires the double meter, then the text should be considered double meter. Note that in this definition, a double meter text cannot be set to a tune of the single meter. Moreover, a tune of the single meter can be set to the double meter only if it has an even number of stanzas.
• Some meters have repeats. See the tunes Hendon and Zerah. The common text for those tunes (the hymn "Take My Life and Let it Be" is commonly sung to Hendon) shouldn't be considered to have an inherent repeated line---it should be able to be rendered without the repeat. Moreover, any text in the appropriate meter should be able to be set with a tune with a repeat, and the appropriate line should be repeated.

7. General expectations.

Use Java packages to organize your classes. I don't think any group has used packages yet, but you will need to do so to keep your directories from becoming overly cluttered.

This phase needs to have an extra level of professionalism, polish, and robustness. It should be error-tolerant and carefully documented. I would like this piece of software to have a life beyond this semester, so make it maintainable. See the Neile/Suzanne submission for a model of professionalism.

DUE: (Tentatively) Wednesday, April 28.