I seem to have an issue that I feel should be solvable but has me stumped.
I have an image placed in a graph and do not want it user-draggable, however I can’t seem to prevent this behaviour.
Settings I’ve tried are:
In fact engaging or disengaging the “draggable” option has no effect whatsoever seemingly.
Here’s an activity illustrating the issue: Image Issue
Any ideas would be most welcome!
Try defining a center point, C. Use C for the image center, and set the point to be undraggable. Other options are to add a restriction to the coordinates. I use {1=1} in the width and height when I don’t want an image to be resized as well.
Awesome, thanks so much!
I would suggest to the Desmos team that this sort of thing should not be required when there’s a “draggable” toggle in the image controls itself. So, Desmos team, if you’re listening…
And a “resizeable” toggle while they’re at it.
Placing the image in a folder and closing the folder prevents modification.
Another one to put in the toolbox.
Hmmm, thanks @JayChow that is good to know. But… it’s a bit of a hack? I mean, is that in the documentation anywhere? Does it have that functionality for a particular reason?
On the other hand, is there some reason/purpose behind the drag toggle and it not actually affecting whether an image can be dragged? I’d like to understand that more as it seems like there’s something I must be missing.
Its not well documented, but its purposeful. Putting an object in a closed folder is used to prevent any modification to an image.
Draggability is a bit different. Whereas the five point adjustability of an image is to edit the image for size and placement, draggability allows images to be used as positionable objects by a student (who’s coordinates we can detect) without the need for a draggable point to be placed on top.
Makes sense.
But why then when draggability is not enabled, the image can indeed be dragged by the student?
I feel like there’s something here I’m just not seeing with respect to that.
Draggability turns the image into a draggable object.
The ability to drag an image without turning it into a draggable object is for ease of editing for the graph creator.
Does that make sense?
Only somewhat. It doesn’t sound particularly semantic in the context of Desmos Activities, but I do understand.
I think the larger issue here goes back to documentation. Is this documented anywhere?
Not to be overly critical but… and I’m trying to say this in a really considerate way… but the lack of documentation is a major source of issues for platform adoption and it drives people away. It’s consistently the number one barrier when I’m trying to sell this to other teachers.
This issue we’re discussing here is a pretty superficial example, but it illustrates the point. I use Desmos a lot and I could not find any information about this issue. There’s not even a search UI on the documentation page.
Take this in the kindest way possible. Many of the questions here and countless hours could be saved were things documented well. You’d just see far far increased adoption, happier users, and far increased leadership capacity.
I’ve mentioned this before so I don’t want to just keep repeating myself, but it really does matter.
I totally understand and please know that documentation is something we’re thinking through very thoroughly.
As for hidden features, I can sympathize. Sometimes hidden features are fun (try typing “table” or even better “betchacant” into an expression line). Sometimes like in this case it leads to users coming up with their own hacks for things we can control really easily and reliable. For example, I used to cover my graphs with a giant transparent image to prevent any dragging and didn’t learn about the folder trick until I began working at Desmos.
If its any reprieve, if you’re ever in doubt about the recommended way to do something, just ask. We’ll be happy to share the method we use in our graphs and activities.
You’re more than helpful, it’s great, believe me.
The issue I’m speaking to is more in line with how others will ultimately decide if Desmos is - or is not - for them.
And it’s about project health, maintenance, and long-term education community support… or not. Documentation is the soul of any code-based project - how(or if) - it’s maintained and loved is almost always a strong predictor of the long term success or death of any such thing.
It’s excellent that things are being developed that I might discover by accident. That’s great. What’s not great is attempting to explain to someone else that their issue is because of a ‘feature’ not documented anywhere that you may or may not have learned about on a messageboard at some time in the past, and to which they’d have no hope of discovering on their own.
This place should not be a triage for what went wrong with documentation fundamentals in the first place. That probably sounds harsh, as this place is really very giving and helpful, but… although it’s getting better, that’s frequently what’s going on.
I’m sure you’re incredibly busy Jay and I can only imagine the time you could have and what you could do with it, were things just a little different.
So, that said, I’m cautiously glad to hear some careful thinking is going into this and that some progress is being made from previous moments when this issue has been raised.
I know you’ve mentioned the documentation frequently, but creating new, original content takes a lot of time that teachers don’t always have. I would argue that is in the top five for reasons why teachers don’t use Desmos. Another reason is change. I frequently share activities with colleagues but they don’t get used because those teachers are a little nervous to dive into a new technology. These activities require zero edits. I know it can be frustrating that everyone doesn’t see the benefits of this tool like we do, but I don’t think it’s fair to point to one thing as the reason why it’s not used.
I don’t disagree with any of that. Those are all significant barriers to entry and success and I see that too every day.
However, I’m thinking from a high-level framework point of view. Just look at the swath of frameworks and libraries that have become defunct on, say, Github. It’s usually down to usability of said framework, and while that usability comes in many forms, documentation is frequently a common denominator.
Is Desmos user friendly overall? Yes, for sure. They generally listen and make things easy for the user. But documentation is critical. You multiply your user base if you just empower them with the ability to learn and teach themselves - that ability does speak to what you’re mentioning here, but documentation is a critical component as well.