Design
Design Overview
Our final design drew heavily from our original Designs #1 and #2; it is based on modes, and the display resembles a calendar. When inputting or modifying a schedule, a user clicks a button on the sidebar to select the mode, which is either a discipline to schedule a shift, the eraser to clear a shift, or the arrow to reset the cursor and mode. If the user is an admin, there are also buttons to mark shifts as excused or absent, and to clear these markings.
| |
Once a mode is selected, the cursor changes to match the icon on the button, and the calendar updates so that only relevant shift buttons are enabled. For example, if the mode is a discipline, only shifts that are valid to schedule and are not already scheduled with that discipline are enabled.
Racing shifts only occur during the Saturday Day shifts.
Instructor Interface
Until an instructor is done submitting his initial schedule, there is a message indicating that the initial schedule has not yet been accepted. After hitting Submit Request, the schedule is marked as ready for approval by an admin.
After the schedule has been approved by an admin, any changes an instructor makes to his schedule are marked as pending. A pending shift has a gray border around it, and is accompanied by a message at the top of the screen detailing the pending shift.
The pending changes after Sam requests to add an adult ski day shift on 12/16/12, and delete his adult ski evening shift on 12/16/12.
After an admin approves the changes, the border and message disappear. If the change is rejected, the shift returns to its previous state.
Admin Interface
After an instructor has submitted his schedule for approval, the admin can approve the entire schedule, along with any changes he has made, by clicking on the Accept button at the top of that instructor’s schedule.
If an instructor has any pending changes, the admin can approve them using the radio buttons above the calendar. As in the instructor interface, anything marked “Approve” will change and the pending border will disappear, any change marked “Reject” will cause the shift to return to its previous state, and anything marked “Clear selection” will keep the pending border and leave the decision unmade. If a pending change was to delete a shift, accepting that change does not empty that shift button on the calendar, but rather marks it as excused.
An admin can mark a shift as excused or absent using the corresponding buttons on the sidebar. These letters will appear on the shifts in the instructor interface as well.
Design Decisions
Originally, we chose a calendar-based interface with modes because we believed the modes would allow for efficient shift scheduling or modifying once a mode is selected, and that the calendar was an externally consistent interface which would improve learnability for users who are not as comfortable with computers.
During our paper prototype testing, we found that users were confused by some of our labels, so we made them more clear. We also added the “Clear Excused” and “Clear Absent” buttons, which hadn't been there before. For the pending changes from the admin view, we had initially had two buttons for each message, one for accept and the other for reject, but users found that this confused their mental model, so we replaced the buttons with radio buttons.
In our heuristic evaluation, the main issues we found were that users were not always sure of which mode they were in, did not know if their requests had been submitted, and thought that our icons were far too complicated. As a result, we added a black border around the current mode, added a confirmation dialog box after hitting Submit or Submit Request, and simplified the icons representing the three shifts.
During the final user testing, we found that the arrow button in the sidebar panel confused users, so we added the text “Reset cursor” to label that button. Also, when logged in as an instructor, our users were unsure of what E and A represented, so our next iteration would add a legend explaining that E is for excused shifts and A is for absent shifts. Finally, our users suggested we have a more visible way to tell that a shift is pending, for example adding a P (similar to the E and A) to indicate a pending shift, in addition to the border, and this would likely be added to our next iteration.
Implementation
The biggest design decision we made for our implementation was to use the Django framework. We chose to use a framework in general, because it would allow us to make our application much more robust with much less code. We chose to use a database, because it provides an easy and persistent way to store data. We specifically chose Django, because it provides an excellent admin interface, which we could use without having to actually write it and which makes it possible to edit the database without being a technical person. This was important for our project because it makes it so that the administrators at the ski school could actually directly edit the database if need be even though they do not have any coding abilities. Django also provides authentication methods, which made implementing login very easy.
...