This is the third of three projects based on the GusAir case study, which is described in a the background document. For this project, your goal flows from the following paragraph of that document:
Finally, if our study of dynamic pricing is encouraging, the founders of GusAir are going to need to explain it to a lot of other people including bank loan officers, potential investors, and journalists. Therefore, we have been asked to provide some illustrative examples of how the price might vary over time as customers make their purchasing decisions. We have also been asked to provide a simple user interface that can be used to step through particular what-if scenarios.
Each of you has chosen a different approach:
One of you uses a random number generator to simulate the behavior of customers. Each time the user clicks a button, the entire sales period is simulated. The price trajectory for the particular sales period is displayed graphically, and the expected and realized revenues are displayed numerically for both fixed and dynamic pricing.
Another of you has the user play the role of the customer by advancing the time one hour either with or without reducing the number of seats. The number of hours and seats are also directly modifiable using sliders. The display shows the optimal price for the current circumstance and the revenue that is expected for the remainder of the sales period.
The third alternative allowed either user actions or random numbers to drive the simulation. That is, the user can choose to advance an arbitrary number of hours (with randomly simulated sales), but can also choose to advance a single hour with a manual choice regarding sale or no sale. In order to allow a branching exploration of different alternatives, the user can also back up in time. At each point, the display shows the optimal price, the revenue that has been realized to date, the expected future revenue, and the revenue that is currently expected to accrue over the full sales period (including that which has already been realized).
In documenting a GUI, a picture can be worth a thousand words. An image of some portion of the computer screen is conventionally called a screenshot. I can show you various ways to take screenshots in Mac OS X. For example, if you press the keyboard combination control-shift-command-4, you can then drag through an arbitrary rectangular region of the screen that you want to copy to the clipboard, ready to paste into whatever word processor you are using to write your project report. (Or, without the control key, the screenshot will be saved to a file on your desktop.) If, as is commonly the case, you want to select a whole window rather than an an arbitrary rectangular window, then after the magic key combination, you can press the space bar and then click on the window.
Your project report will be graded based on the following expectations. Ten percent of your grade will come from each of these ten areas.
You are to explain what your program does in language that would be clear to one of our clients at GusAir. In addition to explaining the particular controls and displays that your program offers (as shown in one or more screenshots that you include), you should provide some higher-level explanation of the value the program provides. How would it allow stake-holders to appreciate the nature of dynamic pricing, including its impact on both the customer experience and the airline's revenue?
Each widget in your GUI should be of an appropriate type for the role it plays. (For example, an output value should show up in a label, rather than in a text entry field that seems to invite the user to edit it. Another example of a mistake would be checkboxes with a label warning users to check only one; radio buttons would be more appropriate for mutually exclusive options.)
The widgets in your GUI should be grouped into logically related categories. Where a number of adjacent widgets of the same kind are used for closely-related information, they should have consistent sizes and positioning.
When there is a logical order to widgets (such as chronological order or cause and effect), that order should be manifest in the top-to-bottom or left-to-right spatial order of your GUI's layout.
Your GUI should not have any distracting gaps (such as between a label and what it is labeling), nor any widgets with sizes grossly out of proportion to their contents. To the extent reasonably possible, this should remain true even if the overall window is resized.
Each widget that provides for user interaction should trigger appropriate behavior from the program when activated.
Your procedures should not only be free of bugs, but also as simple and clear as reasonably can be achieved.
Your project report should use devices such as section headings to provide a clear organizational structure.
The writing mechanics should not embarrass Gustavus in front of our business partners. Examples of mechanical issues are spelling, punctuation, grammar, and paragraph breaks.
You are to demonstrate your program in class on April 30th, accompanying your demonstration with an oral explanation in language that would be clear to one of our clients at GusAir. As in your written report, you should attempt to go beyond the mechanics of your user interface by providing some higher-level explanation of the value the program provides.