Student IDs

[Cay Horstmann]

Hi Cliff,

in your use case, "the tool" is OpenDSA. It displays a page with smart content. It knows for which student it displays the page. When OpenDSA gets a message from a smart content element that the student has done work, it stores the reported state and score with its student model. (I know that OpenDSA stores the score reported by JSAV elements. Don't know about the state.) When a smart content element asks to get its state restored, OpenDSA needs to retrieve the previously stored state for the student viewing the page, and send a message back with that state. In the case of a slide viewer, the state simply is the current page. When the slide viewer element gets the response, it can flip to slide 15.

If the server-side tool is the LTI bridge, then the bridge receives from the LTI launch a unique LMS ID+course ID+opaque student ID, which it uses as key for its state/score database. And it receives the URL of the page with the smart contents, which it places in an iframe. Then it receives getScores/reportScores messages from that iframe which it can associate with the unique ID.

Does that help?

Cheers,

Cay

On 27/03/2023 04.11, Cliff Shaffer wrote:
>
> One question that I have: How do student IDs play into this? I guess that it relates to the callback function. But while that might be fine for the consumer (that receives the score, and recognizes who's score it is from the callback information that it handed the tool in the first place), how does the tool get prior state for an individual? For example, perhaps a student is returning to a programming exercise after some time, and the prior state of the code should be loaded into the editor? For OpenDSA, some of the books use a lot of Programmed Instruction slideshows. Which means that a person might have completed 15 slides so far out of 30, when they stopped, When they return later, they would like to be able to get back to slide 15 without having to repeat all the work.  How do these use cases get supported?

--

--

Cay S. Horstmann | http://horstmann.com | mailto:c...@horstmann.com

[Cliff Shaffer]

I think there might be some complicating factors, because of all the parties involved. One scenario in particular: Within Canvas, a student clicks a module. That opens a page in the browser, in my example an OpenDSA module. Presumably, some ID goes from Canvas to the module page. The OpenDSA module page is executing its own runtime environment to communicate with any smart content on the page. Looking at the module page, the user clicks on an exercise to do something. Some ID information would then need to be passed to the tool from the module runtime. Note that the tool might be "native" to OpenDSA, or might be a 3rd party (such as a Code Workout exercise, which is a 3rd party to OpenDSA, not native). Hopefully this allows the tool to go back to its own server (say, Code Workout) to gather prior state information. This only works if it's the same ID as the last time the user came to the module. Which ultimately would depend on the LMS. Or maybe not -- It might depend only on the iframe command's parameters as embedded into the HTML of the module page when we compiled it. (Which is probably why OpenDSA content in a Canvas course cannot be "cloned" through the normal Canvas course duplication process.)

We plan to get back to you with a detailed report about what exactly is going on in the current implementation for at least these systems. But for now, looking at what you wrote:

If the server-side tool is the LTI bridge, then the bridge receives from the LTI launch a unique LMS ID+course ID+opaque student ID, which it uses as key for its state/score database. And it receives the URL of the page with the smart contents, which it places in an iframe. Then it receives getScores/reportScores messages from that iframe which it can associate with the unique ID.

Which server are we talking about here? Canvas? OpenDSA? Code Workout? And on the client side, are we talking about the "module page" or the smart content? If I understand you correctly, then:

The OpenDSA module runtime receives from the LTI launch a unique LMS ID+course ID+opaque student ID. It can pass this to the smart content on the page, which can use this as the key for its own state/score database. (At compile time for the module page, the compilation script got from the Canvas API the appropriate wrapper for the URL of the page with the smart contents, which it placed as parameters in an iframe command). Then the OpenDSA module runtime receives getScores/reportScores messages from the tool within that iframe which it can associate with the unique ID.

Does that match what you meant?

One point of confusion that I was having in previous exchanges with you is that I was not properly understanding what you intended with the "lightweight library". I was just thinking about the API for a smart content tool to communicate with some outside party through getScores/reportScores messages. What I was missing (if I understand now) is that you also hope to solve the issue of how the module page should be representing the smart tool. That is, what exactly does the iframe code look like to establish the communication? Definitely a good thing to standardize if we can! Again, a complication is who the communication is meant to be with. In our case, it is not direct communication between the LMS and the smart content. The module page is a broker in between.

Something else that I hope can solve: Right now, if an OpenDSA module page has a Code Workout exercise, that is a total black box. We can get the scores, but we don't get the event stream. That goes directly between the Code Workout exercise and the Code Workout server. We would like an architecture that everyone can use that would let the OpenDSA module runtime see the event stream from any smart content contained on the page that implements the protocol.

                 -- Cliff

--

Dr. Cliff Shaffer                                               

Professor and Associate Department Head for Graduate Studies
Department of Computer Science              Phone: (540) 231-4354
Virginia Tech, Blacksburg, VA 24061          WWW: www.cs.vt.edu/~shaffer

[Cay Horstmann]

On 08/04/2023 21.41, Cliff Shaffer wrote:
> I think there might be some complicating factors, because of all the parties involved. One scenario in particular: Within Canvas, a student clicks a module. That opens a page in the browser, in my example an OpenDSA module. Presumably, some ID goes from Canvas to the module page. The OpenDSA module page is executing its own runtime environment to communicate with any smart content on the page. Looking at the module page, the user clicks on an exercise to do something. Some ID information would then need to be passed to the tool from the module runtime.

Frankly, I have not considered that in the strawman proposal. With algorithm simulators or autograded problems, there is not necessarily a need for the smart content to know the identity of the student. But it is certainly reasonable to offer the information to the smart content element. I will add that to the strawman.

> Note that the tool might be "native" to OpenDSA, or might be a 3rd party (such as a Code Workout exercise, which is a 3rd party to OpenDSA, not native). Hopefully this allows the tool to go back to its own server (say, Code Workout) to gather prior state information. This only works if it's the same ID as the last time the user came to the module. Which ultimately would depend on the LMS. Or maybe not -- It might depend only on
> the iframe command's parameters as embedded into the HTML of the module page when we compiled it. (Which is probably why OpenDSA content in a Canvas course cannot be "cloned" through the normal Canvas course duplication process.)

If the smart content is backed by a server, it makes perfect sense for the tool to go back to its own server to get the prior state. That's a use case we need to support.

>
> We plan to get back to you with a detailed report about what exactly is going on in the current implementation for at least these systems. But for now, looking at what you wrote:
>
> If the server-side tool is the LTI bridge, then the bridge receives from the LTI launch a unique LMS ID+course ID+opaque student ID, which it uses as key for its state/score database. And it receives the URL of the page with the smart contents, which it places in an iframe. Then it receives getScores/reportScores messages from that iframe which it can associate with the unique ID.
>
> Which server are we talking about here? Canvas? OpenDSA? Code Workout?

In this case, the server is the LTI bridge.

> And on the client side, are we talking about the "module page" or the smart content?

I would like to be able to support a single smart content element as well as a "module page" that contains multiple smart content elements.

> If I understand you correctly, then:
>
> The OpenDSA module runtime receives from the LTI launch a unique LMS ID+course ID+opaque student ID. It can pass this to the smart content on the page, which can use this as the key for its own state/score database. (At compile time for the module page, the compilation script got from the Canvas API the appropriate wrapper for the URL of the page with the smart contents, which it placed as parameters in an iframe command). Then the OpenDSA module runtime receives getScores/reportScores messages from the tool within that iframe which it can associate with the unique ID.
>
> Does that match what you meant?

The missing piece is that OpenDSA would need to store the state of any smart content elements that are not able/willing to store their own state (e.g. because they have no server, or because their server is stateless).

> One point of confusion that I was having in previous exchanges with you is that I was not properly understanding what you intended with the "lightweight library". I was just thinking about the API for a smart content tool to communicate with some outside party through getScores/reportScores messages. What I was missing (if I understand now) is that you also hope to solve the issue of how the module page should be representing the smart tool. That is, what exactly does the iframe code look like to establish the communication? Definitely a good thing to standardize if we can! Again, a complication is who the communication is meant to be with. In our case, it is not direct communication between the LMS and the smart content. The module page is a broker in between.
>

A "module page" might directly contain the HTML/CSS/JS of some smart content elements, or it might contain the smart content inside iframes. To enable mixing and matching of smart contents, there need to be two standards:

* The JavaScript API (SPLICE.reportScores/SPLICE.getScores or whatever it ends up being called)
* The iframe communication

In the case of OpenDSA, you would need to decide whether you want to support direct embedding (which I believe you currently do in the case of JSAV). In that case, you need to supply a SPLICE object with implementations for the API methods and reroute them to whatever you are currently doing. If you only want to allow iframe embedding, you need to listen to the standardized iframe messages.

> Something else that I hope can solve: Right now, if an OpenDSA module page has a Code Workout exercise, that is a total black box. We can get the scores, but we don't get the event stream. That goes directly between the Code Workout exercise and the Code Workout server. We would like an architecture that everyone can use that would let the OpenDSA module runtime see the event stream from any smart content contained on the page that implements the protocol.

Yes, that is envisioned, by allowing the smart content elements to emit ProgSnap2-style metadata/events, both through the JavaScript API and the iframe protocol. We need to flesh out the details.

If it helps, I can supply a smart learning element that conforms to the strawman spec, and one of your students could do what needs to be done so that it can be included in a DSA page. Also, if someone wants to add a call to SPLICE.reportScores to JSAV, I can consume a JSAV element in the LTI bridge prototype.

Cheers,

Cay

[Cliff Shaffer]

Cay -- Thanks for the reply! This is a big help.

If it helps, I can supply a smart learning element that conforms to the strawman spec, and one of your students could do what needs to be done so that it can be included in a DSA page. Also, if someone wants to add a call to SPLICE.reportScores to JSAV, I can consume a JSAV element in the LTI bridge prototype.

Yes, please send us both a smart learning element (or appropriate URLs to access), and tell us where to find the repository for the current strawman spec implementation. I will add these tasks to Yemi's list. ;)

I can consume a JSAV element in the LTI bridge prototype.

This makes me nervous. It does not "smell" right that the LTI bridge needs to know anything about JSAV. I would expect that either JSAV or somewhere higher in our client-side framework would be calling the LTI bridge methods.