Project: Phase 2

The goals of this phase include

• Getting a firm set of features for the final product (and gaining the user interaction experience that goes along with that).
• Getting the data model right (or as close to "right" as possible).
• Determining how to store the data and implementing that approach.
• Taking what was learned in the GUI prototype in phase 1 and maintaining it enough to demo the features (generally the user interface is a low priority in this phase).

1. Teams

For reference, the teams for phase 2 are:

• Team 1: Brian, Andrew S, Josh, Conner, Kayley
• Team 2: Andrew T, Kurt, Leanne, Daniel

2. Users and features

Right away you need to find a group of potential users. It's best to find people who would truly be interested in using such a program, but don't consume time trying to find the ideal focus group---just grab some people, offer them some cookies, show them one of the phase 1 implementations (more on that below) and some sample timelines (some will be available in the lounge, but by all means feel free to find more examples of your own), and get their reaction to what features would be useful.

As a starting point, I recommend the church history timeline found here as a starting point. Obviously the ways a timeline can be organized and decorated are endless, and something of an art. But I think being able to produce a timeline somewhat like this would be a reasonable goal.

Specific features to discuss include:

• Various ways to distinguish among the categories (or layers, or registers): color, font, other forms of appearance, physical position.....
• "Eras" marked off by some visual indication that affects an entire vertical slice of the timeline. In the church history timeline, for example, time is divided into the era of the Apostolic Fathers, the Apologists, and the Church Fathers; additionally, times of persecution are marked by gray swaths.
• Historical vs fictional time
• Logarithmic scale (this, however, may be purely a rendering question; it may not affect how the data is modeled---except that if some events are measured in Myr, then you probably won't want to require a date; also, even features that affect only rendering should be gathered from users at this point).
• Placement of the axis (also a rendering question, but still something that should be discussed with potential users).

3. Decisions

In this phase, the teams must make decisions on what approaches from phase 1 to use going forward. Here are my recommendations; you may choose to depart from these, but use these to structure the discussion, so those arguing for other choices should explain the advantages of the alternative.

• For the GUI and rendering (graphics), it seems like JavaFX is the obvious choice. Even though this will not be the emphasis in this phase, you'll need to have a prototype to show the potential users. I recommend Kurt-Conner-AndrewS's submission for the rendering and Andrew-Josh's submission for the overall GUI experience.
• For modeling the data, I recommend Kayley-Daniel's submission for its simplicity and cleanness. As discussed in class, the real trick to this part of the project is defining an interface between the model and the parts of the system that use the information being modeled (rendering, editing, saving to disk...) in such a way that encapsulates the model and allows the subsystems to change independently.
• The most controversial decision is that for storing the data to disk. My recommendation is to use XML (probably with XStream or a similar tool) as in Leanne-Brian's submission; the main competitor to the XML approach is to use Sqlite. The advantage of XML is its simplicity, which makes it both human-readable and human-editable, and doesn't require the extra piece of using Sqlite itself. The advantages of Sqlite is the support it gives for managing concurrent access---and the personal advantage that you will then have experience working with Sqlite.

Document your code using Javadoc style.

4 Write-up

Please include a write-up to guide me through your submitted code, explaining what decision your team made and what you learned about the problem/project. In particular, detail what you heard from the potential users, how you interpreted that information, and what decisions you made about features and other specifications.

DUE: When you leave for spring break.