Replies: 1 comment
-
@chrisekelley @lachko Let me know if you have input! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This discussion began while Chris and I were reviewing the PR #3630. The features for Tangerine Class/Teach module and Tangerine Case module fit into a similar modal. Both track entities longitudinally and synchronize data in two directions. While Case is a generic module, Teach was developed specifically for classroom/education scenarios. Currently the modules cannot be used at the same time.
Teach Document Types: "Attendance" and "Scoring"
In Teach, there are two new document types that hold a list of inputs for a set of students in the classroom. The "attendance" document captures the daily attendance for the classroom. It has a list of students and a set of inputs ("status", "mood", etc) for each student. The "scoring" document is for a test presumably given daily. It similarly has a list of students and inputs for a set of tests ("score", etc).
Though experiment: What does a classroom "Case" look like?
A classroom can easily be mapped to the Case Model. Shifting the Teach module data structures to case and preserving the view of teach ("classroom-dashboard", "attendance-dashboard", etc) could help simplify the code base and empower the use of multiple modules.
For the above to work, the document types for "attendance" and "scoring" could be transferred to generic "response" documents.
Retaining the Views for Teach
If the shift is made to generalize the Teach module documents, then the client-side views for Teach need to be available. These views can be included by adding a flag to the group config that defines the attendance and scoring forms. The system administrator would be able to select which views appear in the nav bar on the client.
Generic Event Records
In the future, we can add a new entity to the [Case Modal](Case Model called an "Event Record" that is a generic entity based off the Teach "attendance" and "scoring".
An event record would be defined under an Event in the Case Definition file and be tied to a specific "Event Form" definition and "Form Definition". Current form responses are taking for one participant. The new Event Record will be taken for the current set of participants.
The views for the event record are also important. The views for "attendance" and "scoring" are specific to the education context. It will take significant effort to define a generic set of inputs and layout that could be used for viewing Event Records. Ideally views for Event Records would be Authored in a web interface (similar to Form Authoring).
Beta Was this translation helpful? Give feedback.
All reactions