Partner Detection and Student Identification
Currently, students are identified by their seat ID (e.g. 09L, 11R etc.), which is also used by the frontend (at least in the reworked version) to determine their partner in any interaction that involves another student (hitting, talking, ...).
This isn't a particularly pressing issue, but there are some flaws with this approach that I want to address for future changes to this system:
- It is very easy to end up with duplicate IDs, e.g. when adding new seats by copying existing ones or just by mistying a new ID
- duplicate IDs lead to multiple students reacting to the same behavior change, which is most likely undesired
- When seat order gets scrambled somehow (e.g. someone reorganizes some of the seats in class) the association breaks down (avoiding this requires knowledge that the IDs matter in the first place)
- breaks down when students in class are missing, i.e. students may need to have different partners than usual
Another approach that was employed at some point was the use of proximity to determine a partner. This avoids much of the ID minutia but may result in unexpected pairings.
Furthermore, there is currently some ambiguity where partner actions are processed or rather who is responsible for engaging both students in the current behavior. Previously this was settled entirely on the Unity side, but iirc the new frontend takes over part of the functionality. This should be cleared up in future work to ensure that modifying logic for partner behaviors doesn't require knowledge of both applications (at least as much as possible). Personally, I want to pursue as much as possible the approach of moving the application logic back into Unity wherever possible and have the frontend mostly be concerned with orchestrating visualization of the classroom state and interaction with the current session so that TeachR developers only need to interface with it directly on rare occasions.
So that being said, here is the catalogue of tasks I see for this issue:
-
ensure students are identified uniquely (e.g. by their object hash or some similar value) -
maintain association of students to their work partners within TeachR (not the frontend) - Frontend receives feedback that partner was activated through message from TeachR as for usual behavior updates
-
fallback for missing partners (this could be a hybrid approach of using fixed partners usually and going by proximity if partner is missing or anything similar)