Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Allow hiding element by ID until block execution #184

Open
egenn opened this issue Apr 5, 2024 · 4 comments
Open

[Feature]: Allow hiding element by ID until block execution #184

egenn opened this issue Apr 5, 2024 · 4 comments
Labels
t: feature-request Request the addition of a new feature
Milestone

Comments

@egenn
Copy link
Contributor

egenn commented Apr 5, 2024

Feature Description

Hi -

The goal is to allow revealing a hidden div by id when a webr code block is executed.
In my case this is for building code exercises.

See minimal demo here.

I've done this by using a reveals webr block option and extending the definition of qwebrExecuteCode here.

This is the first step towards supporting active learning modules.

@egenn egenn added the t: feature-request Request the addition of a new feature label Apr 5, 2024
@coatless
Copy link
Owner

coatless commented Apr 5, 2024

Cool progressive reveal structure in the demo! I'm sure it would be a great feature and a great way to slow down students.

Thinking about uses cases here... We also need to support RevealJS presentations.

  1. How would this option work in a presentation?
    • Potentially, you may need to have a progress bar or an insert on the slide saying "please complete the prior slide's activity to unlock this slide."?
  2. Could this option be named progressive-reveal instead of reveals to avoid running afoul of the reveal CSS class?

One other question: How accessible will the new feature be with screen readers?

No worries if you can't answer immediately, I can ping JooYoung Seo for a formal review/tips on working with screen readers.

@egenn
Copy link
Contributor Author

egenn commented Apr 6, 2024

Thank you!
In the context of a book, like in the demo, the goal is much like learnr's.
You would most likely limit the hiding/revealing within each page, which would be teaching a specific concept/topic,
and you would be free to navigate around to different pages.

In a RevealJS presentation, you can do the same within each slide.
If you then also want to disable advancing to the next slide, you could disable advancing until the last code block is executed, for example. I imagine this being set by a separate, independent option, though.

I don't see why the reveals code block option would interfere with the reveal CSS class. It could be something similar like unveils or unhides.

I don't have experience with screen readers - I tried VoiceOver briefly.
I understand dynamic pages can be a challenge. I wonder if the fact that content is only appended at the bottom may make it a non-issue or that would still be a problem, in which case there might be an option to disable hiding altogether.
Would love to hear from an expert on this. Accessibility is a top priority. This is eventually intended for a large very diverse audience of learners.

@coatless
Copy link
Owner

coatless commented Apr 6, 2024

@egenn no worries on the screen reader part. Again, we thankfully can ping an expert on it. We'll also probably have someone from UIUC's DRES group take a look as well.

If you'd like, I can ask him to take a look at the demo page. He's usually pretty fast (~48-hour turnaround M-F).

On the navigation, I think we might run into a problem with exercises resetting as we're not storing any state information into a browser's localStorage. This might be a bit problematic with longer tutorials as a result.

Regarding the option naming, I think two things might want to happen:

  1. Setting an opt-in for this kind of tutorial unlock at the document level, e.g.
webr: 
   progressive-reveal: true
   show-startup-message: false
   cell-options: 
     autorun: true

This would automatically register the progressive reveal option for any interactive cell that is exposed to the user.

  1. For a cell-specific option, I'd like to avoid reveals or reveal as it can get messy with RevealJS's use of reveal in a few places. We've had clashes previously with user/extension-defined CSS classes or IDs.

Naming-wise, would any of these options work?

  • staged
  • phased
  • unveil (previously suggested)
  • cascade
  • layered
  • stepwise
  • sequential
  • gradual
  • iterative

@coatless coatless added this to the 4.x milestone May 5, 2024
@egenn
Copy link
Contributor Author

egenn commented Jul 1, 2024

Thank you and sorry for the extended radio silence! Been working on grants and other deadlines - some related to this work. I'm preparing to convert a large existing R book (https://rtemis.org/pdsr/) using this format and also writing a new ML book with the same interactive learning modules. Also found that webexercises makes it easy to provide MCQ and fill-in-the-blank type of exercises that combine nicely with the interactive code execution (https://rtemis.org/pdsx/filtering.html)

I've changed the option to "unveil", I think it makes sense.
I agree that both document-wide and cell-specific options would be great.

Would you be interested in a PR?
For the cell-specific option, I've added a few lines in qwebr-cell-initialization.js and qwebr-compute-engine.js, and of course it could be done differently if you prefer.

All the best

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
t: feature-request Request the addition of a new feature
Projects
None yet
Development

No branches or pull requests

2 participants