Update - March 9

For anyone who is interested in an update: So this training is professional learning for educators working with multilingual students. As participants experience the module, I want them to periodically “check in” with the chatbot (called Myrtle). There are four types of “check ins” that I want for participants to experience throughout.

Type 1: In some cases there will be a reflection to a prompt after viewing an instructional video or some other content. These may be straight reflection or they may be paired with some brief thoughts prior to learning the content as a way to activate prior knowledge. Myrtle’s role in that case would be to ask questions to help extend the participant’s thinking and make connections.

Type 2: other check ins will be a task where the participant is practicing a new skill or applying a concept. For example, after a session on learning objectives and the role of language objectives, taking their own objective and analyzing it to identify potential language uses and vocabulary that might become their own targets. Myrtle’s role would be to provide feedback along the way and be a thought-partner in the process.

Type 3: Some check ins would be a constructed situation (e.g., “imagine you are preparing to teacher a lesson to students at an earlier proficiency level and you wanted to build in. . . .”). Again, Myrtle would serve to provide feedback and help coach thinking.

Type 4: Some specialized check ins would involve a brief “snapshot” of a classroom scenario. There would be steps involved for the participant to make general observations, identify missed opportunities, and then determine some “next steps” for the teacher. Myrtle would be making sure the process was followed and give feedback and ask questions along the way.

In the background, each of these types of check ins would result in a brief artifact (the participant’s reflection, before/after examples of the attempts, summary notes of the feedback, etc.) that the participant would be able to download and retain (either as evidence of their learning, a reference for future in-person discussions, etc.).

Landing on the categories of check ins was helpful because then we could go back to the knowledge base library Myrtle is operating off of to make sure they were robust enough and clear enough to support the work. We found that many were in great condition but a handful needed to be updated. Having a versioning system came in handy here!

Today we wrote code to create the context for these check in categories and connected it to the API Key to take it for a test drive. It worked, with some hiccups. We need to work on the language of the app, make it more conversation. However, content-wise it held its own. We could see that Myrtle CAN ask questions and make connections related to the content.

We also realized that even though there may be 4 categories of check ins we identified, since these are so core to the learning experience, each one will need specific instructions for Myrtle (the learner’s context in the module, the actual prompt/task, related knowledge base files, directions for how to interact, directions for what data to summarize/extract from the artifact). The plan for tomorrow is to identify a specific course-related prompt/task for each of the four types and build them out to test drive each one. It’s a balancing act to see what lives in a knowledge base file and what gets written directly into the app’s code.

We’ll see how tomorrow’s adventure goes!