ChrisBoesch / singpathfire

An AngularFire-based version of SingPath
http://chrisboesch.github.io/singpathfire
MIT License
4 stars 7 forks source link

Provide a way to resolve SingPath problems. #89

Open SingaporeClouds opened 9 years ago

SingaporeClouds commented 9 years ago

Users can not currently edit any successful solution to SingPath problems. The reset button is disabled after successful solutions.

Provide users with a way to go back and re-solve SingPath problems from the SingPath user interface.

dinoboff commented 9 years ago

What should happen to the resolution time? should I reset the the completion ending time?

SingaporeClouds commented 9 years ago

This becomes another architectural decision related to what users can update with their permissions and what requires verifier permissions to update.

Users will need to be able to change/reset their start times when they "reset" the problems and try to solve problems for the first time. Users will also need to be able to clear their current solutions when they reset a problem to solve again and to edit their solutions. So we should allow the users to clear/reset their start times and current code.

The verifier can save all (or the last 10) valid solutions submitted by users for each start time the user has set after resetting problems. So if I reset a problem 10 times, and submit valid solutions 10 times, there would be 10 records somewhere with 10 different start times and 10 different solve times that only the verifier could modify. These past solutions can be kept in an object with the keys being the start time.

The most recent start time set by the user and solve time (and/or duration) for that start time set by the verifier should be fetch-able in an efficient way for class owners. The Class owner view needs to be able to quickly check and visualize which participants have solved a problem since some start time.

There will be a future task feature that allows task owners to require class participants to solve or re-solve a task after the time at which the class owner sets the task to be visible. When that SingPath task feature is enabled, the GUI will check not just to see which class participants have solved the assigned SingPath problem (solved for any start time) but also which users solved or resolved the SingPath problem after the SingPath task was set to visible. So class owners will need a way to see if users have ever solved a SingPath problem and at what time they last solved the problem.

There will also be a task feature that allows ClassMentors links to SingPath problems that automatically reset the user's solutions when landing on the problem. This will allow ClassMentors to provide different links to SingPath problems that have been previously solved by class participants but not solve or re-solved since the task was made public. This is how class owner can require participants to resolve problems.

// Something like this is what I envision readable by everyone and only writable by the verifier. https://singpath.firebaseio.com/singpath/solvedProblems/<userID/ { "startedAt": 1432613583751, "solvedAt": 1432613588751, "duration": 5000, "pastSolutions": { // past solutions moved here by the verifier "1432613000000":{ "startedAt": 1432613000000, "solvedAt": 1432613040000, "duration": 40000 } , "1432610000000": {...} // another past solution. } }

If no re-solves have been recorded, then each record would just be something like this once the problem has been solved by the user. The times as the root of the object are always the last start time, solve time and duration. { "startedAt": 1432613583751, "solvedAt": 1432613588751, "duration": 5000, }

dinoboff commented 9 years ago

ok. It's all doable:

  1. the user saves the current duration in an array someway. The security rule can enforce that it's the current duration.
  2. the user then deletes the current duration. If only the verifier is allowed to write a value "solvedAt" field, the rules can allow the user to delete the "solvedAt" field (and other related field).