center-for-knowledge-communication / mathspring

Mathspring website
http://mathspring.org
6 stars 3 forks source link

Bugs in StudentProblemHistory #30

Open perspegrity5 opened 4 years ago

perspegrity5 commented 4 years ago

There continue to be unusable rows in the studentProblemHistory. Some of this was cleaned up (by Neeraj?) but problems remain. Every item should have an EndTime, but many have NULL end times. This is probably because the code does not catch all of the ways students can exit working on a problem.

See this file for examples, stuProbHistory_12_argent_classes_summer_2019.xlsx at: https://drive.google.com/drive/folders/0B_GYlt5BXq8gTElja3NjS05rVjg

IvonArroyo commented 4 years ago

It might be related to problems being shown as EXAMPLES. It is possible that the logging is not correct, for the effort on the problem. The timestamp of the problems might be null also.

mkartik commented 3 years ago

While analyzing the code, I did find certain cases where the student could exit working on the problem, but it was not handled in the code and so for that specific problem, the database had the EndTime field as NULL. I have fixed those cases, wherein the user would exit working on the problem, using the different modes available in the application. Should we also handle the case, wherein the student closes the browser, instead of properly logging out of the application.

perspegrity5 commented 3 years ago

On Jul 29, 2020, at 5:47 PM, Kartik Mittal notifications@github.com wrote: While analyzing the code, I did find certain cases where the student could exit working on the problem, but it was not handled in the code and so for that specific problem, the database had the EndTime field as NULL. I have fixed those cases, wherein the user would exit working on the problem, using the different modes available in the application. Should we also handle the case, wherein the student closes the browser, instead of problem logging out of the application.

Thanks Kartik--this is great. If its easy to do, i would say yes to catch that possibility. In fact (if its not hard) to enter a record in the eventLog table indicating "Browswer Window Closed to exit" or something like that (with time stamp).

In addition, I suggest we should have a field in the StudentProblemHistory that flags "ProblemAbortedBy" which would either be empty (not aborted) or say the method of leaving the problem: BrowswerWindowClosed, SkipByNextProblem, ExitToMyPP, LogOut, ExitToGarden, etc. Hopefully, since you have got to know the code for the places to add this already.

mkartik commented 3 years ago

I have included the field named "ProblemAbortedBy" in the StudentProblemHistory table to track the method of leaving the problem. The ability to catch the method where the browser window is closed to not direct, and I am still looking into it.

Also, I observed a peculiar behavior when looking at the entries made in the StudentProblemHistory table. For example, if a user is at a particular problem, and leaves the problem by clicking the "My Garden" tab, an entry is created in the StudentProblemHistory table for the current problem that is left. Now if the user clicks "Practice Area", the same problem is shown and the same entry in the table is updated to the current timestamp. Is this an expected behavior or should I new entry be created in such cases.

perspegrity5 commented 3 years ago

Hi Kartik,

On Aug 3, 2020, at 5:08 PM, Kartik Mittal notifications@github.com wrote:

Also, I observed a peculiar behavior when looking at the entries made in the StudentProblemHistory table. For example, if a user is at a particular problem, and leaves the problem by clicking the "My Garden" tab, an entry is created in the StudentProblemHistory table for the current problem that is left. Now if the user clicks "Practice Area", the same problem is shown and the same entry in the table is updated to the current timestamp. Is this an expected behavior or should I new entry be created in such cases.

This does make sense but it might be too confusing. If the student clicks on Garden or MPP and then clicks back on the Practice Tab it makes sense that they return to the problem where they left off. Whereas if the go to the MPP there are several ways to choose the next problem to see and go from there.

I would suggest that if a student clicks on the MPP or Garden, then the problem is aborted as far as the studentProblemHistory goes. If they click on the MPP or Garden, and then click on Practice tab, they should return to the problem where they last left off, but it should start a new problem instance for that problem, and reset the start time etc.

--Tom