Capstone Project: Module II

 

 Capstone Project: Module II

This week our team was able to tackle quite a few Milestones, and have been heavy in development as of late, with database integrations, establishing a clean local development environment that will transition seamlessly into production. We started Front-end design, and are making headway in on building out all the necessary components and pages required. The scheduling algorithms prototype has made headway, among sharing with our advisor he thinks we're on track, and would like to establish an AB test in association with the Programming Team of CSUMB, as they are a direct fit into our primary beneficiaries. 

🧮 Scheduling Algorithm

I've been working on the prototype for the scheduling algorithm, which started out with spaghetti code at the start, however, through refactoring and utilizing interfaces and abstract classes, we believe that there is a lot more opportunities to further tailor and redesign it in the future. I started in Python, since it's easier to prototype and use pandas dataframes to incorporate simulations across multi-day intervals, to check for intended behavior and edge cases.

A user will have the option to rate a problem based on their own perceived performance:

Hard: could not recall how to solve the problem.

Medium: could recall how to solve, however, thinks there's room for improvement.

Easy: could recall how to solve and were happy with their performance.

A user's progress will be designated per category across state transitions; these are the primary ones: 

Locked-to-Learning: When a category unlocks, this will occur when a user successfully transitions from Learning to Progressing in a previously unlocked category.

Learning-to-Progressing: progressive point where user solves enough problems within the category successfully(user rating easy on all problems).

Progressing-to-Scheduled: when a user has solved all problems within the category( with an easy rating), it will then be rescheduled to activate in the Progressing state at a later date in time.

Scheduled-to-Progressing: when a category's due date is the current Date or less than, it will reactivate; however, on the first problem, if they recall and resolve the random problem within the category, they will immediately reschedule it at a later date in time. If they fail to recall, they will have to resolve 2 problems before rescheduling; however, it is by design that the user will never have to solve more than 1/2 the problems in succession before being scheduled.

Chart indicating Unlocking Behavior Across State Changes

This chart is across a 20-day simulated window, where the user has a deck containing 6 categories containing 6 problems each. With a strict cap of only being able to rate at most 5 problems per day(considering how long these types of problems take to solve). with a weighted distribution of: 10% hard, 20% medium, 70% easy, for users' ratings. You can see that categories unlock only after a previously activated category transitions to progressing. And that in this instance, even with easy rating's dominating the distribution, you can see that the user is exposed to at most 4 categories at any point in time, having the potential to limit the cognitive load of our users as opposed to the standard SM-2 algorithms method which schedules problems atomically and exposes the user to all problems within their deck. Worth noting, this is a simulation and just illustrating the behavior of our scheduling algorithm; however, it does support our efforts to further test.