One key to building complex software, especially with others, is the ability to reuse code.
I want to discuss some of the advances in the reusability of Desmos Activity Builder (AB) components and screens and Computation Layer (CL) code, and some of the things that in my opinion still need to happen to unlock the potential of the community to create activities collaboratively, to build up a library of useful components and templates, and to expand access for teacher-users who are comfortable doing light editing for their pedagogical needs, but aren’t interested in getting arms deep into the CL.
First, let’s mention a few features of AB and CL which have increased reusability.
Let us praise Copy/Paste. The addition of copy/paste for individual slides to Activity Builder greatly increased the ability of activity creators to repurpose code from other activities. Before, you had to either copy individual code snippets and graph expressions, or copy an activity entirely. That made marrying different ideas difficult. The other copy/paste which made life easier for pasting a Desmos graph by URL. This means that you can share an animation or particularly useful graph feature independent of an activity. It also means that one person can develop the graph and another the interactive activity, as long as they know what the graph will expect and expose.
The feature of being able to name a component as a variable increased the ability to abstract out the particular names which are referenced many times, and easily change the reference in only one place near the top of the code.
Collections have also been a boon to collaboration and reusing of components. It has increased the ability for creators to share an ongoing project and others to follow it. Some collections are already developing into library of templates or examples. I think the self-checking and assessment collections we’ve seen come around recently are testament to the power of being able to group similar functionality.
Now on to the areas for improvement.
The key issue I see in the reusability of Desmos AB screens and CL is lack of encapsulation resulting in too many hidden dependencies when copying screens and code.
Consider the analogy of a library function from a procedural programming language. To use it, all the software author needs to do is import the function from the library, and then call it within their own code. They never have to open the function’s definition, and rename variables. The variables within the function definition are encapsulated. By contrast, when you copy a screen or CL snippet from another activity, there are many places where there can be hidden dependencies, all of which must be cleaned up by the author before they can rely on that component’s behavior within their new activity.
Suppose someone makes a Desmos activity that has interactions across screens. For example, say there is a Button called “button1” which must be pressed to reveal a question in a Note component on the next screen. Now if you want to copy that second screen, it will not work as is in your activity. The editor will probably flag your reference to a non-existent component, but what if you also have a “button1” somewhere in your activity? Your Note component will be hidden until you realize that line is there. Similarly, when I try to re-use code from the CL of some component I like, I have to first deduce all the dependencies (if they are not documented), then replace all the references. If I don’t want that button disabling interaction, I then have to remove that line of code. It requires a high skill level, probably beyond what most teachers have time to do if they want to mix and match tasks or pieces of an activity for their own use.
In the documentation, CL is referred to as being more like a spreadsheet than a procedural programming language. It is true that CL is mostly about components referencing values that live in other components, to facilitate interaction. These connections are similar to how cells in spreadsheets can reference each other. Anyone that has built or worked with extremely large and complex spreadsheets can attest that reusing formulas and changing references is a pain. People who use spreadsheets professionally have developed style guides which help to alleviate some of this pain. For example, in finance it’s common to put any input parameters to a model in blue, so that the user of the model knows what they should change, versus what is calculated by the model. There are also programmatic features to protect sheets and cells.
(On a side note, the clutter that happens in CL due to the lack of a loop or array construct is an eyesore. There must be some syntactic sugar to avoid things like having to fill each cell of a table with a separate line of code. Spreadsheets use array auto filling to make the user’s life easier when repeating the same formula along a range. CL needs something to handle that)
I don’t have a clean solution for the problem of encapsulation and dependencies. I will leave that to folks who design programming languages to hash out. My guess is that the inspiration for an answer will come from an old system like SmallTalk or HyperCard. Message-sending or event-handling might be better paradigms than declarative spreadsheet formulas. For now, better warnings and better style might be the only mitigation.
Finally, the last thing that is needed to really unlock the potential of the community of Desmos AB creators is an open source platform which is navigable. Every public user-created activity on Desmos is open source, but they are notoriously hard to find, especially for the uninitiated. The platform I imagine would be similar to GitHub, but simpler to use with probably limited features to start. Right now, if you have a link to someone’s activity, you can go to it, Copy and Edit, and you’re off. That to me is like forking a repository in GitHub. However, it’s very hard to see the entire history or what other projects forked from that same activity. Maybe I’m replicating work someone else did, but I would never know. Unless you happen across the link somewhere, like in the Facebook group or Twitter or one of the various workarounds that have been developed to create a searchable index of user-created activities, you won’t know who else built off that original activity.
I understand the desire for the Search box on the front page to only return high-quality results. Right now, that means vetted by the company. But as we know, a central authority like that won’t scale well. Tons of activities are being created, especially during the pandemic. They are naturally going to vary in quality and reusability. However, I propose that the community provides the feedback on quality, by metrics like how many times it’s been used with a class, how many stars or likes the activity has received, how many times it’s been “forked.” That way, we can still find everything without an external workaround, and it’s actually all there, instead of only the activities that people in the know have actively added to those external sites. Folks can still make activities private or shareable but not searchable, but it would unlock a level of collaboration that right now is hampered by not being able to find templates and examples without just asking the community directly.
This turned into a mix between a treatise and a list of feature requests. I don’t want to sound ungrateful, because the features that already exist in the produce are phenomenal and free. I think it’s important for all of us to think about what would really make it possible for any teacher along the spectrum of skill level in AB and CL to create or adapt activities for their classroom. We’ve seen in other settings what happens when people are empowered to build off each others’ work with little friction. I think that can happen with Desmos Classroom Activities, and I’m excited to see what else this community will create in time.
2 thoughts on “Reusability and unleashing the potential of the Desmos Classroom Activity Community”
Another note on reusability features that already exist, CL has special rules about scoping, which allow multiple components to have the same name. If I reference “button1”, CL will correctly resolve it to the button on the screen I am referencing it from, even if there’s a “button1” on another screen. We made this change to better support copy/paste.
Thanks for your thoughts!
Thanks, Denis! I wasn’t aware of this change. It makes sense to infer that “same screen” scope should take precedence. It does become problematic if you still have that name collision in the activity, because if yet another screen wants to reference that component with a collision, how would it decide? I have seen the editor flag the collision, but it’s a tricky issue. I wonder if the screen level scoping could be made more available to the user. What if we could reference screens themselves by a name, the way we do with components? For the current screen, a standard local scope could be handy. I’m thinking that you can already refer to the component you’re working on using “this”: what if you could reference the screen’s scope like “thisScreen.button1” within the CL. That would make the code safer to port. It doesn’t fix the problem of referencing other slides, but perhaps with more clear style guidelines, people would start making those explicit at the top of their code, and make it easier to anyone else to re-use it by just updating the references.