Replies: 5 comments
-
|
@chrisekelley @lachko Let me know if you have input! |
Beta Was this translation helpful? Give feedback.
-
Teacher Case Module IntegrationTeach Dashboard IdsTeach Dashboard Ids are generated for attendance, behavior, and scoring response documents and used as the Couchdb
if (!curriculumLabel) {
id = type + '-' + sanitize(grade.replace(/\s+/g, '')) + '-' + randomId + '-' + reportDate + '-' + sanitize(username) + '-' + reportTime
} else {
id = type + '-' + sanitize(grade.replace(/\s+/g, '')) + '-' + randomId + '-' + sanitize(curriculumLabel.replace(/\s+/g, '')) + '-' + reportDate + '-' + sanitize(username) + '-' + reportTime
}Example Ids:
Issues The current implementation has the following issues:
Responses Ids
Case List
Generic Case Dashboards
Participant Dashboard
Teach with Case Dashboards
Student Dashboard
Case {
"_id": "12345",
"type": "case",
"events": [
{
"event-id": "12345-1",
"event-forms": []
}
],
"participants": [],
"caseLists": [
{
"caseListId": "45678",
"caseListName": "Students",
"caseListItems": [
"student-id-1", "student-id-2", "student-id-3"
]
},
{
"caseListId": "67890",
"caseListName": "Teachers"
"caseListItems": [
"teacher-id-1", "teacher-id-2"
]
}
]
}Case {
"_id": "12345",
"type": "caseList",
"name": "Classrooms",
"metadata": {
"studentId": "12345",
"teacherId": "12345",
"date": "2021-01-01",
"time": "12:00:00",
"curriculumLabel": "curriculumLabel"
}
}Case List Item {
"_id": "09876",
"type": "caseListItem",
"caseListId": "12345",
"caseListName": "Student",
"metadata": {
"studentId": "12345",
"studentName": "John Doe",
"date": "2021-01-01",
"time": "12:00:00"
},
"forms": [
{
"formId": "form-1",
"formResponseId": "form-1-xyzabc",
"formName": "Assessment",
"formType": "assessment",
"formVersion": "1.0",
"formScore": 90
}
]
}Responses New Add
{
"_id": "form-1-xyzabc",
"type": "response",
"formId": "form-1",
"userProfileId": "teacher-1",
"respondentId": "student-1",
"formName": "Assessment",
"formType": "assessment",
"formVersion": "1.0",
"formScore": 90,
}Updates to SyncBasic Sync Rules SP1:
SP2:
New
Client ViewsTangy-forms Views from These are SP1 only. If we move to using SP2 everywhere, they can go away Sync (SP2) Service Views from Search Service View from Case Home Views Teach Views from Custom Views |
Beta Was this translation helpful? Give feedback.
-
TasksLachko: Update the import scripts to transform data into the new Case structure
Chris/Erik: Integrate the Teach Views into the Case Module
Has the information about the classroom in the header
Classroom: Grade 1
Curricula: Math, Science, English
Teacher: Ms. Smith
[**Assessments**] | [Attendance] | [Behavior] | [Dashboard]
| Student| Assessments |
|------|-----------------|
| John | Math 1: Section 1 |Chris/Erik: Association of Case List Items with Cases
Document Update Workflow
Chris/Erik: Investigate the changes needed to combine the registration and sync processes
|
Beta Was this translation helpful? Give feedback.
-
|
From Lachko: Going through the Ideas ticket, I think we have left out some important items.
The questions are:
|
Beta Was this translation helpful? Give feedback.
-
|
I think that this is perhaps a good structure of Teach case. 
Once I tap on top of case listing (classes listing) I get subject listing (right image above). The listing should have only the students show up. Beside each student there is an action icon to create a new evaluation for one for the subject for this class. So when I tap the + button I will see each section of that form-event form (subject) not the to fill the entire form at once (per section) 
To make things easier we can save summary results data in the case automatically. So that for each student we have subject/formID | student ID| formative Score. Perhaps the same can be done with attendance, behavior, and summative scores for easier already calculated totals per student. Those can be used on reports and available through the T.service. 
The SART report (attendance-dashboard landing page currently) is a little different as it considers all scores (for either subject and by semester – defined in app config. ) and behavior forms, plus attendance for the entire classroom (for any subject part of this classroom) This can be on classroom level I’d say. Attendance can be linked to either an entire class or it can be per subject for this classroom. Attendance needs to automatically list all students on the form and show the icons to mark them as late or absent. So we need a new template that will list all students and show some form input next to them. To comply with form response, this form input must create a standard form response in tangerine. The attendance records in the case should be somehow hidden to avoid long lists. We can show only the last X and if enabled in case, allow editing of those. The attendance screen should Ideally have a date dropdown on top and allow for other inputs to be added (since it is a standard form template, eg. period), that is locked to today’s date by default. But if editable can be changed. Rules checking that only one record pe day can exist, if manual entry is allowed or teacher is doing back date entry. This means we need to save date of entry, and date of registry of attendance.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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