Need ability to duplicate a model #40

Closed benloh closed 1 year ago

In GitLab by @jdanish on Aug 10, 2020, 10:41

There are a couple of cases where making a model and then creating duplicates of it (that then have new names and can be edited will be really important / useful).

@benloh How hard would this be to implement as a button in the admin interface or model viewing interface (or both).

In GitLab by @jdanish on Aug 10, 2020, 10:56

Our presumed use case is something like this:

Create a model that will be used as a starting point for all of the students
Duplicate the model once for each group
Assign each copy to a specific group

Note that it'd be fine if 2 and 3 are combined in some way, or separate is fine.

In the case of SEEDS, this would be because we are thinking of creating two imperfect starting models (in one file) and having students begin with those and edit them rather than start from scratch.

This probably isn't straightforward. Two tricky aspects to this:

1.the database calls use an update/merge cycle similar to D3's.

you'll have to properly request IDs from the database.

But I'd have to dig into the code some more.

In GitLab by @jdanish on Aug 12, 2020, 08:48

Gotcha. Hm...

Fleshing out the design a bit...

Creating the Canonical Model

Models can only be created by users currently. So a teacher would have to first create either a special classroom (e.g. "Teacher-only" or "Templates" or "Originals"), (and a special user for themselves or can they just use their own login?) and then create and edit the model.

Currently teachers actually can't create a new model with their login because of a missing group id (it's a bug). This will have to be addressed.

Cloning the Canonical Model

Once the model is crafted, it can be cloned. There are two clone targets:

a. Clone for every group in a class

b. Clone for one group

This suggests that maybe we have a "Clone" dialog that allows the user to select the target? The dialog would have to allow:

[ teacher v ] [ classroom v ] [ group ]

That way models can be cloned between teachers as well. Also, the group selection would be optional. Or perhaps the first option would be "All Groups".

Student's Cloning

Students can clone their own models from their own model list page. Their clones would simply result in a duplicate model appearing in their models list. They cannot move models between groups. Only the teacher can.

Issues

[x] Teachers can "Create New Model" using a special teacher group.
[x] Teachers can move a model to other classrooms, teachers.
[x] Delete a model
[x] Show classroom in Teacher model list.

In GitLab by @jdanish on Oct 14, 2020, 06:45

One reason to have a special teacher group is that that would allow them to work on models and revise them prior to sharing them. However, if that adds a bunch of work it can wait until a future grant.

I like the idea of the target dialogue and having the option to copy to all, though if that is a hassle, doing it repeatedly is fine.

Number 3 implies (I assume) that teachers also have a "move model" option that is always available.

If you need other clarifications let me know, but otherwise we are assuming we'll be the teachers for now, so are more concerned about students' experience than teachers (so long as it is relatively logical).

Good point re moving. I'll add that.

I feel like we've always cut corners on the admin interface side, so we may as well at least do this one little thing to make things easier for you.

@jdanish One more question: How heavy duty do you think the cloning will be? For example, do you anticipate cloning more than, say 20-40 at a time?

The reason I ask is because ALL of our data operations are currently client-side. The server side is essentially a dumb database implementation that knows nothing about the data. The "proper" way to implement cloning is to move at least some of the data operations to the server side. But this would be pretty significant rewrite. I was hoping that we could tackle it, but taking a closer look, this would basically eat through the budget and not leave us time for implementing a UI and addressing the other things on our list.

If we can live with lightweight cloning, an asynchronous client-side clone of say, less than about 20 models at a time, where it may take 5 seconds or so walk through all 20, then we can do this cheaply and efficiently. So for instance, you would create a model, then you select clone, then you can select to clone it for a single group, or for a whole classroom (assuming a classroom is less than say 40 groups), and then wait as it walks through the cloning one by one.

When you use this in your IU classes, how many groups are there?

If necessary, we can add some kind of batch operation that can handle a few hundred clones at a time, but I don't think we're talking about such heavy duty cloning are we?

You can try it out on the new clone branch.

Log in as the teacher (e.g. msbrown-vyfz), click "CLONE" next to a model, then select a classroom with a lot of students. See how long it takes to clone. (This doesn't yet work from the admin view).

In GitLab by @jdanish on Oct 16, 2020, 13:02

Hey @benloh:

Yes, we are looking at a single classroom at a time currently. So that'd be 25 models if we make one for every kid, or like 10 if we make one for each dyad.

My IU use is my grad class so there are only 2 groups. So that's fine.

Testing now ...

In GitLab by @jdanish on Oct 16, 2020, 13:08

@benloh The demo looks spot on to me. Thanks!

Awesome, thanks! We'll go with this solution then!

Regarding a special "Teacher Group", I'm actually thinking right now that leaving that functionality out makes the most sense.

Here's how teacher template editing could work:

Define a Admin Teacher and Admin Classroom

For each new server instance, you would create an "Admin" Teacher and an "Admin" classroom.

Define author groups.

You would use the author groups the same way you use student groups based on the access needs.

Depending on who's authoring templates, you could define a single "Admin" group, and add individuals to that group, e.g. "Joshua" and "Cindy", so they each log in individually and you could use the comment system to discuss the template. And everyone can work on any of the other templates.

Or you could define a single "admin" user for that group that everyone shares. You'd lose the ability to have individual comments, but it simplifies the user administration.

Or, if you have multiple separate author groups, e.g. you're working with two separate teachers and you want them to work independently, you could define multiple author groups. As with students you could allow them to see each other's work, but they can not edit each other's work.

Pros

This groups all templates into one place, rather than being scattered across different teachers' accounts.
Since we need to separate teacher login to comment on a read-only model vs teacher authoring anyway, this provides a clear delineation between doing teacher-as-author work vs teacher-as-assessor work. (Currently logging in as a teacher grants you view-only + comment ability on all projects across all classrooms).
Depending on how you set up the groups and authors, you can collaborate on a template with some degree of author attribution.
Since clones can be copied to any teacher or classroom, template authoring can happen with any teacher/classroom/group/user combination.
We don't need to build anything new.

Cons

You would have to manually add an "Admin" teacher/classroom/group to each new server instance. We could bake it in, but that would restrict you to a particular approach.
You would need to remember to use a separate login to do template authoring. On the other hand, you could never author directly from the admin interface anyway (since we need to tag any model work with a teacher, classroom, and group author, you would have to designate that somehow via some kind of login).

@jdanish any thoughts on this?

In GitLab by @jdanish on Oct 19, 2020, 10:26

@benloh, I agree, that seems like a lot of work to give us some simple abilities, and it seems like we'd be better off getting the other features for now. Then, if / when the next grant is funded we should re-prioritize and spell out what we need in terms of admin and do it all at once. I think we can find something simpler at that time if we adapt the whole model with some more thought to actual classroom setups.

So, as things stand right now, the not-so-clean-but-workable solution is that the teacher can create a group for editing templates where they only create one student which is a version of them. Then they can create them and clone away using their original teacher login. It's a bit awkward but works.

The alternative (if it is not too hard) would be to give the teacher edit / creation access when they login in teacher mode. That way they only need one login. They'd need to choose to either create their template in a student group (if they don't care) or make a separate no-student group anyhow and add it there. This would be ideal short-term, though we can live with the prior option.

Either way, if the teacher REALLY doesn't want students to see their draft, they'd need to either create a separate classroom or just not have "see other models" turned on. I don't think that case currently exists, but at least there is an option.

So, I think we get what we need (it's relatively easy for teachers to create and then clone or move a model) with either of the two above solutions without dedicating the time needed for your proposed solution, which can wait until later. That'll let us focus instead on some of those other features that were nice-to-have but not as high priority.

Did I miss anything?

A few nuances:

You can clone from the admin interface, which is probably where you would do most of that cloning work anyway (unless teachers never use the admin interface?)
Having a separate admin/teacher login + classroom + group gives you the ability to have a list of projects that are purely template projects. Otherwise, logging in as a teacher you would see all projects from all of your classrooms (unless we built out functionality to really put you into these two separate modes of work).

I did at first try to add the ability to give the teacher special edit/creation when they log in, but because all models are tied to a groupID (and by extension, a userId and classroomId), we would have to hack around a lot of areas of the tool to make this work. It felt like a messy solution that would complicate our lives later. There might be an approach that I'm missing, so I'll ponder it some more, but I suspect that completely redoing teacher logins (e.g. change teachers to be a real user with a group designation and not just an exception case) and creating a separate teacher interface is probably the way to go. But those are more involved.

In GitLab by @jdanish on Oct 20, 2020, 04:31

Both good points. Right now we are only using one model per study and I’m the teacher, so I think let’s go with the quick and dirty approach. Revisiting a full teacher interface in a future project makes sense to me. Thanks!

added 18h of time spent at 2020-10-20

added 16h 30m of time spent at 2020-10-20

subtracted 18h of time spent at 2020-10-20

theRAPTLab / meme