Project 6: Ruby on Rails Project

Ruby on Rails Tutorial

Complete chapters 2, 3, 5, and 6 of the textbook. (If time permits, try the main bits of chapters 7 and 8 too.) See the syllabus for notes on textbook access.

Everyone in the group should complete this part of the project. Collaboration is permitted and encouraged! You do not need to submit anything for this part of the project, but completing it as soon as possible is highly recommended as it will help in completing the second part (i.e. the final project, below).

Final Project: Audience Evaluation of Presentations

Background

In classes with presentations, such as CSE 3901, evaluations of these presentations by audience members (ie other students in the class) can be a useful component of the grading rubric. The feedback from these evaluations is useful to the instructor for assigning a score to an individual student, as well as to the students for receiving constructive criticism from their peers.

A web application would streamline the collection, collation, and analysis of these audience evaluations.

Required Features

1. The instructor/TA should be able to create presentation events for which evaluations can then be submitted.

2. An audience member should be able to submit scores and comments for a presentation. The application should support multiple presentations over the semester (eg, different presenters or multiple presentations by the same presenter).

3. An administrative interface should give a useful view of the scores and comments submitted for a presentation. This view should support the instructor's need to assign grades based on these evaluations.

4. A presenter should have access to the feedback provided by their audience.

5. Authentication/login. Evaluations should be connected to an authenticated user, preventing forging of evaluations.

6. A non-trivial javascript feature must be implemented. Searching, sorting, dynamic manipulation of page elements based on user choices, or whatever other interesting things you can come up with would work for this requirement.

Extensions

The following list is not exhaustive. The goal is to create as useful an application as possible, so the following are some challenges that could be addressed to that end. You are encouraged to think of other improvements that would be useful.

1. Class roster. The instructor or TA should be able to control membership, populating the class, for example, with names and email addresses from a roster.

2. Prevent self-evaluation. Presenters (for either individual or group presentations) should not be allowed to submit an evaluation of their own work.

3. Admin dashboard to monitor submission of evaluations and simplify sending reminders or managing evaluations that are never submitted.

4. Changing enrollment. Students might add or drop the course and this should be handled cleanly by the tool.

Submission

There are 2 separate submissions for the final project, with different due dates.

1. Demo/presentation. By the due date of the final project (as indicated on the class web site), you must submit (on Github) a presentation describing your project, as well as all current code. Over the next several lectures, each group will have about 10 minutes to present their project to the class. Give a client-view demo (i.e., from the end-user perspective), and also describe any interesting technical details of the design from an implementer's perspective (database schemas, architecture, etc). The order of presentations will be random, so expect to go the first day, and plan to attend both lectures.

2. Final submission. You may continue to revise your project until midnight, Saturday December 7th. Include a file called RELEASE-NOTES.md that indicates the major changes between this version and the earlier beta version.