Feature Request for Graphing Calculator

Hello! I would like to request a feature for the full-size graphing calculator in any Desmos Activity based off this feature in the PolyPad:

I’m not sure what would go into creating that as a feature, but it is something that can be done using the hasResponse sink, and a variable that changes based on an action a student activates or a regression based on other variables changing. I could help with a specific example if you have a link.

I tried the hasResponse but it didn’t work for the graphing calculator :frowning: So here is what I was trying to do but then it seemed like it wouldn’t be possible so I requested this feature.

Desmos Activity

My school uses these review activities to prepare for state testing. Sometimes, students will skip past the slide where they show their work (like Slide 3) and just a pick an answer on the next slide and move on. What I’d like to do is have coverText on the slide where they select their answer (Slide 4) that hides the content unless they have typed into the previous slide.

I understand that there’s probably not a way to check that they showed the right work, but I just want to at least ensure that they interacted with the graphing calculator in some way before moving on. The way they are supposed to show their work is by typing in the problem and then all the answer choices and comparing the decimal results.

I know that the Dashboard can tell whether or not a graphing calculator screen has been interacted with–is that something I can call as a variable to use in employing coverText?

Ah I see! hasResponse is a sink that is set by some condition, but is not a source that can be referenced. It’s only function is to tell the dashboard there has been an interaction.

There is not a way to tell if anything has been added to a graphing calculator. Any condition used with coverText would have to be based on variables that already exist. Generally we wouldn’t recommend restricting a student using coverText, particularly if later screens are dependent on interactions with prior covered screens, if only because mistakes happen and bad code could lock a student out of the remainder of an activity.