[Anonymous]

We have just started looking into CODAP with the goal of building a “MathNet” kind of collaboration around it.  And we are looking at a first step to get a sense of things…

The first scenario we wanted to try involved having students receive, edit, and publish the state of Sampler Data Interactives.  There are many other (potentially more complex) things we will eventually want to explore in CODAP, but this seemed like a good a first step in that it looked both tractable & interesting.

To do this, we need to know how to (a) programmatically load a CODAP document into a CODAP instance.  (b) programmatically load a Sampler’s (or any Data Interactive’s) configuration, and (c) programmatically get the current state a Sampler (or any data interactive) as a configuration description.

Is there any documentation of CODAP’s (high level) API beyond what’s immediately obvious in GitHub?

Is it clear what the intention is here?  The teaching and learning scenario for this first step is mostly “classroom sharing” ->

(i)  Teacher “sends” a CODAP document to the class, which has a Sampler  => Functionality (a)

(ii) Students set up the sampler to model something, optionally doing all kinds of things PRIVATELY in their instance of CODAP with it.  => (native CODAP functionality)

(iii) When ready, students “send their sampler” to the teacher. (pressing a button that is ‘external’ to CODAP)  => Functionality (c)

(iv) The teacher receives a whole collection of student samplers.  One by one, she loads a sampler she wants to discuss  => Functionality (b)

(v) She uses native CODAP functionality to see/show what the sampler does.  => (native CODAP)

(vi) The class gets interested in Student X’s sampler.  Teacher then sends this sampler out to the whole class for them to explore.  On each student’s CODAP, this selected sampler replaces the one that was there before => Functionality (b)

This workflow does have some value, and it also leads to lots of other ones that might be more complex (sharing data, sharing displays, etc etc)  But those are more entwined with the innards of CODAP rather than just the configuration of data interactives.

So, we thought that starting with (a), (b), and (c) could be a good way to get “feet wet”

Do you see our logic?  (Does it make sense as a first step?)

And, if so, is there documentation of what would be needed to “wrap” CODAP in order to achieve (a), (b), and (c)?

Thanks!!

[Anonymous]

Regarding (a)

The teacher can share a link to a shared view of the document. Students open this link and get their own copy to work on.

Regarding (c)

Students create a link to a shared view of their document and send this link to the teacher.

Regarding (b)

The teachers has shared links from the students and clicks on them one by one. (Changes she makes do not affect the students’ documents.)

[Anonymous]

That would be GREAT news (that this ‘phase’ of the scenario would only require “sharing links to create COPIES of shared documents” — can you explain how CODAP deals with shared documents

Also, how a DATA INTERACTIVE’s link encodes its state ?

[Anonymous]

 

1. “programmatic” control: Generally, there are three programmatic touch-points for CODAP: (a) the Data Interactive Plugin API, (b) the Cloud File Manager API, and (c) URL query parameters.

The Data Interactive Plugin API is useful for plugins, such as the Sampler. It allows plugins to participate in the CODAP environment, as nearly as possible, in the same way as a native CODAP component. A plugin can define and create data, query for data, select cases, find out what cases are selected, participate in Undo and Redo activities, and create or manage other components. It does not allow plugins to open different CODAP documents or save them. This API is documented here.

The Cloud File Manager (CFM) API is for document management. CODAP itself is designed to have no native interactions with servers. It cannot natively save or restore documents, nor authenticate users. It relies on the Cloud File Manager for all these services. It would be possible to extend the existing Cloud File Manager to integrate with a new cloud service or platform. It would also be possible to create a new from scratch implementation of the API. The code for the CFM is here.

URI Query parameters are for configuring CODAP at startup. You can specify the starting CODAP document or starting plugin in URL query parameters, as well as a number of other configuration parameters. I don’t have a document handy that describes these options in detail, but in most cases specifying the document should be sufficient.

2. CODAP document sharing: To be clear, this is a service of the CFM, not CODAP. (The menu items in the “hamburger menu” in the upper left hand corner of the CODAP screen are all CFM processes)

A shared document can be thought of as a snapshot of a “regular” CODAP document.

The “Share …” submenu of the “hamburger menu” provides the UI for creating or updating a shared document.

A user shares a document by creating it in the dialogs started from the above menu. He or she is gets a URL that they can send to other users, similarly to a Google Docs shared document.

Behind the scenes, the shared document is stored on a Concord Consortium-managed server. The original document could have been one saved in a user’s Google Drive account or saved in the user’s local file system. Or indeed, the original document does not need to be saved at all.

There is currently no way for a Data Interactive Plugin to manage sharing of documents.

3. How CODAP manages state Data Interactive Plugin’s state: Plugins communicate their state to the document in which they reside, and they get the state back if the document is saved and reinstantiated in another instance of CODAP. From CODAP’s point of view, a plugin’s state is simply a blob of data, though in practice it is usually a JSON object. There is no mechanism provided by CODAP for a plugin to be configured except in the context of a document and that configuration is merely an echo of what the plugin has previously told CODAP about its state. This being said, a plugin is just a web page, and there is no reason it could not communicate with a server to become configured. The solution that Bill proposed manages all these interactions by encapsulating the state of the plugin in the CODAP document. The initial state of the sampler would be in the CODAP document that the teacher shared with the student, and the student’s state would be in the document that the student shared with the teacher.

You mentioned MathNet. I am not familiar with this environment. You can probably appreciate that the original solution would work without any other infrastructure. It just works through the invocation of URLs. One hopes that, being technology neutral, it would work in the context of any technology, but it is a Black Box approach. Would a more active involvement by the surrounding environment be necessary?

BTW, are you familiar with the Concord Consortium Portal/Lara environment? This is a relatively simple curriculum sequencer with a teacher dashboard. CODAP can be run as an integrated tool in this environment, capable of all the items you outlined in the scenario in your original email.

Hope this helps. Please contact me if I can clarify anything.

[Anonymous]

I am NOT familiar with the Lara/Portal environment.  Is it possible to get an account to try it out & see if it does everything in this “first step” scenario?

The fact that it’s a “first step” scenario indicates that there are further collaborative pieces that we would like to support – including the sharing of COLLECTIONS and the sharing of SCREENS.

But the “first step” scenario is a good way for us to understand how documents are copied in sharing.  That’s not super clear to me, even with your explanation – but it’s likely that I have an incorrect ‘mental model’ of some part of the process, which is interfering with my understanding.

[Anonymous]

Concerning the Lara/Portal environment, yes, you can create an account and try it out here. Its free to use. Here is a guide to the Portal. I am attaching a copy of a document on authoring Lara sequences. I believe it is on the concord  It includes sections on including CODAP. This may give you an idea of what integration is possible at this point.

[Anonymous]

What’s a good activity in the learning portal that uses CODAP?  I don’t see a way to make new materials, and it’s not clear from the titles which of the materials presented involves CODAP. ?  Thanks!

[Anonymous]

Here is one. The CODAP link will be on the third page. This is the ‘old’ way of incorporating CODAP in a sequence. Pressing the CODAP button launches a new page, in this instance. A recent capability permits CODAP to be inlined, but I don’t have an example of that.

[Author]

Posts