Gallery restrictions on project functionality

[amyjko]

What are you trying to do that you can't?

One common problem that teachers have is controlling what programming language and API features student have access to, and when. When there's too much complexity, it can be overwhelming. It also prevents teachers from being able to control sequencing of learning. Sometimes teachers also don't want certain features to be available (e.g., sound output, which can be annoying), or want to foster creativity through constraints.

Some systems and curricula have tried ways of managing these challenges. For example, Code.org systems often hide language constructs until later units; students report being annoyed that they can't access advanced features. The Bootstrap project has used a language levels feature, which hides features of languages. But this isn't something easily configurable by teachers.

What is your idea?

Adrienne and I had the idea of having galleries optionally specify functionality constraints on the projects in a gallery. For example, there could be a section that lists all of the language features and APIs. There could be two different levels:

• hiding, which puts features in an advanced section of documentation
• restricting, which disallows features in a program, and filters them out of autocomplete and menus

There would be many sections of the interface that this would affect, if a project were in a gallery with these restrictions:

• The Guide would be filtered
• Autocomplete would be filtered
• The Editor's glyph chooser would filter shortcuts
• The Evaluator runtime would fail on disallowed features

[BoyanLu1008]

Hi Amy!
I’ve did a bit of research to see how similar systems handle feature gating:
Code.org locks entire categories of blocks until a level is reached, Scratch hides advanced blocks behind curated starter projects, and MakeCode uses “skill maps” that expose APIs step by step. All of them hard-code progression into the curriculum rather than the environment itself.

Maybe our Wordplay’s gallery could store these constraints in each project’s metadata, so they travel with the project and stay relevant across different teaching setups. And that raises some design questions:

1. Should restrictions live only at the gallery level, or can individual projects override them? (That scope probably affects how teachers reuse or remix assignments.)
2. Could there be different “modes” of restriction? like hidden, disabled with explanation, or more others?

I’d love to explore this further and happy to learn whatever’s needed to contributing and make it work!

[amyjko]

@BoyanLu1008, would you like to be assigned to work on this design? If so, it would be your job to answer those design questions above, proposing a design that meets some of the requirements laid out in the description above.

[BoyanLu1008]

Sure! I’d be happy to work on this!

[amyjko]

Okay, assigned to @BoyanLu1008. Talk to Adrienne, ask questions, ideate, and let's see what you come up with!

[BoyanLu1008]

Hi Amy Hi Adrienne,
here’s how I’m recently day's thinking about gallery restrictions on project functionality.

Our Current State:
Teachers cannot control what programming features students can access in a gallery, it cause:

• Beginners get exposed to the full language surface immediately, which can feel overwhelming.
• It’s hard to scaffold learning (like week 1 only text+simple motion, no camera/sound yet).
• Teachers can’t really prevent access to “annoying” or off-task features like sound output.
• There’s no way to align visible features with a particular curriculum or unit.

Our Goal:
Enable galleries to specify restrictions on project functionality, so that a gallery can shape:

• Which parts of the Guide / concepts / examples are visible.
• What shows up in autocomplete.
• Which things appear in editor shortcuts / glyph chooser.
• Which features are actually available at runtime (with conflicts instead of silent failure).
  The idea is, if a project is “inside” a gallery, the whole editing + runtime experience should respect that gallery’s feature rules.

So maybe we can have two decision:

Decision 1: Scope of Restrictions, this is the first big fork: where do the restrictions live?

Plan A: Only gallery level

1. A gallery stores a set of feature rules
2. Every project inside inherits them
3. Projects outside galleries behave like they do today

Pros:
Simple mental model for teachers: “This assignment has these rules.”
Consistent experience across all projects in the gallery.
Easier to implement and maintain (only one place to look for restrictions).
Easy to teach/explain to students

Cons:
Not flexible enough for mixed-ability students
No “unlocking” of features across projects
Might require multiple galleries to represent multiple levels

Plan B: Gallery defaults + optional project overrides

1. The gallery still defines default restrictions.
2. Individual projects can optionally override them (probably only by teachers/curators).

Pros:
Supports progressive disclosure (start restricted, then “unlock” features in later projects).
Allows advanced or challenge projects inside the same gallery
Can better support mixed-ability classrooms.

Cons:
Harder for students to understand: “Why does this project behave differently?”
More UI and logic complexity
Requires conflict resolution between gallery vs project rule

Plan A is more simpler and B is more flexible, so my recommendation is tart with PlanA, add B later if we need. It keeps things predictable for teachers and easier to test. We can always introduce per-project overrides in a second phase once the core experience feels solid.

Decision 2: Restriction Modes

The second decision is how a feature can be restricted. I’m imagining 3main modes that line up with Wordplay’s goals around accessibility and conflicts instead of hard errors.

Mode	Behavior	Use Case
hiding	Feature completely invisible (Guide, autocomplete, shortcuts)	Hide concepts not yet taught
restricting	Visible but disabled with explanation when used	Show what exists but prevent use
disabled	Completely non-functional (fails at runtime if somehow used)	Safety restriction (like prevent Camera access)

Also we can consider some more modes:
disabled_with_explanation: like disabled, but requiring a teacher-written reason
readonly: students can read examples that use a feature, but can’t add new uses of it themselves (could be interesting for “peek ahead” lessons).
We wouldn’t implement these right away, but they might be useful to keep in mind

The following content is in attachment: “Gallery 11.19 update”:
Gallery 11.19 update.pdf

So, above that, we have some open questions need to talk about,

1. Should we start with gallery only (Plan A), or do you see strong cases for Plan B already?
My current thought: Start with A.
The mental model (“everything inside this gallery follows the same rules”) feels clean for teachers and easier to test.
But maybe I‘m underestimating classroom variation, so very open to hearing whether Plan B is needed earlier.

2. For a restricted feature, do you prefer “fully hidden” or “visible but locked”?
My current thought: Both are good, but if had to choose one, I was slightly toward hidden, since it reduces cognitive load for beginners. “Visible but disabled” seems great for intermediate groups or when teachers want to foreshadow upcoming concepts.
This feels like something where teacher preferences might differ a lot, Curious what you both prefer pedagogically.

3. Should restrictions be coarse (e.g. all Camera), or fine-grained (e.g. Camera.record() vs Camera.detect())?
My current thought: Start coarse (entire concept/feature), because a fine-grained system might require a lot of UI and could be confusing. But for long term, fine-grained could unlock interesting lesson designs (“use Camera only for still frames, not recording”).
Not sure how common those use cases are in real classrooms.

4. Should teachers edit restrictions only from the gallery settings page, or also while inside the editor?
My current thought: Only from gallery settings, at least initially. It's cleaner and avoids mixing teaching configuration into the student-facing editor experience.
But if teachers often modify assignments while inside the editor, in-editor controls might actually be helpful.

5. Would presets like “Text-only”, “No audio/video”, “Beginner mode” be useful?
My current thought: Presets seem potentially valuable, especially for new teachers or those teaching short workshops.
Even just “text-only” and “no camera/mic” might save a lot of manual clicking.
But maybe teachers prefer fully custom control instead of presets, I don't know, not sure how often they reuse the same restriction sets.

And of course, feel free to disagree with any of this!!!! I’d love to hear your perspectives, and iterate!!

[amyjko]

This is a great start, thank you @BoyanLu1008. A few thoughts below.

First, a process note: avoid attaching PDFs; they aren't screen readable by default, and so people who cannot access them cannot know what's in the content. Use embedded images with image descriptions instead, if an image is unavoidable.

I agree with the two key decisions: this is about 1) what dictates restrictions (gallery, or gallery plus other things), and 2) what "restriction" means, in terms of granularity and control. I think your analysis of the design spaces and tradeoffs for both are thorough. You raise many good questions about all of these.

Re: your attachment, it lays out several forms of restriction logic, and potential ways of representing it. I think this is a good start, but it's actually much more complex than you've laid out, as there are many, many different features that could be filtered. I think the main list we're talking about are all of the programming language features (see NodeTexts.ts), all of the APIs (see InputTexts.ts and OutputTexts.ts). Those can show up in project code, they can show up in the "concepts" section of the Guide, and they can show up in "How to" examples in the guide. The questions about granularity are whether we define restrictions on each of the programming language constructs and input/output APIs entirely, at the level of their individual functions, or with higher level groupings.

Another challenge is that certain features depend on each other. Camera, for example, uses List, and so it wouldn't make sense to restrict List but allow Camera. So it's not just a flat list of language and API features, but a tree of dependencies, where restricting one feature might mean restricting others implicitly.

Ultimately, now that you know the design space of possibilities, the design process question is how to decide which part of the design space best meets teacher and student needs. That means trying to better understand teachers' needs, and deciding based on our best understanding of those needs. One challenge with learning about their needs is how to talk about these possibilities with teachers. I'd recommend the following:

• Create a concrete prototype (or two) of what this functionality would look like for a teacher. What would the interface for Gallery curators look like? This will help make concrete how overwhelming the interface might be, what functionality might be helpful or unhelpful, what might be missing. Having multiple alternatives will allow a teacher to consider their tradeoffs in concrete terms.
• Adrienne comes to most Wordplay meetups. (The next is Dec 3rd). You could ask her for input there, or I meet with her tomorrow at 1:30, and I can get her input then.

Once we have that insight, then it will be reasonable to select from these various options.

[amyjko]

@BoyanLu1008 Are you still working on this issue?