Open egenn opened 3 months ago
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.
progressive-reveal
instead of reveals
to avoid running afoul of the reveal
CSS class?
learnr
is progressively showing and tracking content.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.
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.
@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:
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.
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?
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
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 ofqwebrExecuteCode
here.This is the first step towards supporting active learning modules.