WeBWorK: static preview for 2.16+ #1333
Conversation
|
Really nice. I love the way the correct answer "goes into" the answer blank.
|
|
Thanks for reviewing things. I may pick back up on this tomorrow.
Maybe, would that be your preference? The first time was the place where it chooses whether to write a div or an iframe, and I like how direct that was. Like, is there a server-url? If yes, that's what I need to write down now. The other instances came later.
Right now the Yes, it could just become "https://webwork-dev.aimath.org" and the "/webwork2" can be added where needed.
Maybe. What if you have a 2.15- server and you want to keep using this? Like Andrew R's thing? If we drop this experimental undocumented thing, we would need to tell Andrew to use the webwork-dev server until real 2.16 servers exist. And I can't promise it is usable 24 hours a day, 7 days a week. |
|
OK, now that I look things over, I think it is almost ready for more serious merge consideration.
I think that would be all for this PR, unless you see something more. The remaining work is in CSS_core and JS_core. |
I see what you mean. It was an accident that I deleted the lines that make that button. For now I put it back, for the sake of Andrew's project at least. |
<xsl:if test="foo:>
<xsl:value-of select="foo"/>
</xsl:if>But I also really like the idea of an (internal) version number on the representations file, independent of the server numbering. Just 1, 2, ... And the server name explicitly in that file. Your call.
<xsl:value-of select="substring-before($document-root//webwork-reps/server-url[1], '/webwork2')" />trades on the fact that <xsl:value-of select="substring-before($document-root//webwork-reps[1]/server-url[1], '/webwork2')" />Having written that, now I really am in favor of not discovering the server this way. ;-) One general UI question. Is there another way to make it obvious that the WW icon screams "Click me to go Live!". Yes, students will know quickly, but it is too nice a feature to be lost on casual browsers and potential adopters. Oh, now I see the "Make Interactive" button. No good reason, but I want to put it below the problem - maybe with very light styling (thin border, shaded background, drop shadow) around the problem (not This is going to be very nice... |
|
Missed this one:
Publisher switches are expensive and a PITA. This is so much better, I can't see a reason to keep the iframe way. Definite improvements, without authors' invovement, should always just happen. In tnhis case, itmight even just cause minor confusion. |
|
Got it. Will factor all this in, then lots of testing, then a force push. Something else though. Delivering through an iframe, if it is a server problem that has a coded hint/solution, the user sees those things no matter what the publisher hint/solution settings were. It's out of our control. Delivering through the div, our own javascript will intercept the rendered problem and has the option of omitting hint/solution from the rendering the user sees. Do we want to use this to respect those publisher settings now that we can?
Option 1 is easy to do. Do we care that it is easy to hack? Option 2 can also be hacked if someone researches the WW html2xml delivery method and/or peers into our js. But it's significantly more obfuscation. With 2, the technical details of getting it working on the WW server side feel like it may take many hours of experimentation. Is this worth doing? Is there a 3? |
This is a concern of mine. Not huge, but I think it should not be trivial to discover the answers.
ROT13? Seriously, what if the javascript (and WW server?) used a symmetric encyption algorithm? I'm not suggesting managing keys like it is DRM - just enough obsfucation that a user would need to discover the JS in use, get a shared key from somewhere, write a function... In the end, an enterprising student can spin up their own server, no? At least we now have a good scheme for PTX solutions to be kept private while still part of an open-source project. Having said all that - can you get (1) working and come back to (2) in time for 2.16? That'd let Brad experiment sooner. I'm thinking one-third of FCLA reading questions should become their (old, existing) WW-randomized, auto-graded versions on Runestone... |
|
I think I will follow that suggestion and just do (1) for now. I think I don't want to do (3) because it would probably just be a stopgap until I could do (2), and I don't want to make more than one PR to webwork about it. Got some accessibility feedback from PCC staff today. Will act on that too. |
|
What if I do (1) (for now) with a little ROT13 obfuscation? Like instead of the div having |
|
Sure. So long as it doesn't impact Brad. ;-)
…On 7/17/20 9:06 PM, Alex Jordan wrote:
What if I do (1) (for now) with a little ROT13 obfuscation? Like instead of the
div having |data-showSolution="yes"| it has |data-fubjFbyhgvba="lrf"|?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1333 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOLM4UXWCEAXBXMRYQXTETR4ENTLANCNFSM4OZGU2CQ>.
|
|
Option 4: The static preview is going to show hint/answer/solution knowls depending on the publisher settings in the usual way. So these are written into the HTML. The JS could peek to see if these knowls are there and infer whether it should show these things after the problem becomes live. And then on subsequent reloads (say from hitting the check answers or randomize button) it could similarly peek into the right places in the DOM to infer what is revealed on the reload. Still option 1 for the short term, catching up to where Brad can do more work. |
|
The representations file has this structure: It makes logical sense to put a version on the |
|
Add a single new peer of the reps, or better, put an attribute @Version on the single top-level overall element. Perfect.
Then is it hard to get? Or not?
…On July 18, 2020 3:31:09 PM PDT, Alex Jordan ***@***.***> wrote:
The representations file has this structure:
```
webwork-representations
webwork-reps
webwork-reps
...
```
It makes logical sense to put a version on the
`webwork-representations` rather than each of the `webwork-reps`. But
then how would the HTML extraction access that through the assembly
phase?
|
|
Right, I'm thinking the top-level element of the representations file has a But my question is how does |
|
OK, now I understand the question. Let me cogitate for a bit.
…On July 19, 2020 3:57:54 PM PDT, Alex Jordan ***@***.***> wrote:
Right, I'm thinking the top-level element of the representations file
has a ***@***.***`.
But my question is how does `pretext-html.xsl` access that? I feel like
`pretext-assembly.xsl` needs to see the ***@***.***` in the
representations file and insert something into assembled source at the
`docinfo` level. How would I do that?
|
|
Right. Not thinking clearly. Author's original source needs to validate. Assembled source does not need to validate. You could write version onto overall pretext element or into each enhanced version of a webwork.
Latter would be redundant, but easy and convenient. Am I off the rails again? On fone not looking at code.
Rob
…On July 19, 2020 6:57:14 PM PDT, Rob Beezer ***@***.***> wrote:
OK, now I understand the question. Let me cogitate for a bit.
On July 19, 2020 3:57:54 PM PDT, Alex Jordan ***@***.***>
wrote:
>Right, I'm thinking the top-level element of the representations file
>has a ***@***.***`.
>
>But my question is how does `pretext-html.xsl` access that? I feel
like
>`pretext-assembly.xsl` needs to see the ***@***.***` in the
>representations file and insert something into assembled source at the
>`docinfo` level. How would I do that?
|
|
If we are OK with that redundant option, we could just put the version inside each Putting the WW version as an attribute in the root What seems "right" to me is if the assembly added a child to |
|
Yes, |
|
This is ready for review. It requires a .js file that I put in the appropriate place on the aimath server. I'll open a PR for that soon to JS_core. I tested with Then I tested with This also includes the Runestone manifest bit. If you add the right thing to the publisher file, that also should be working. (It was working earlier when Brad did some testing.) |
|
Once this is reviewed and merged, I will try to build ORCCA HTML with a RS manifest for Brad to play with. Oh, I know there is discussion of this and that in the forum. Like putting "Correct!" to the right of the answer blank. That's all fine, and is controlled by |
|
Looking good. The cylinder graphic responds to the "Randomize" button! Not sure why that surprises me. ;-) The one source problem got split into two paragraphs. Then the LaTeX changed as: \begin{inlineexercise}{}{g:exercise:idp89}%
-There is math in each option for this question. Which expression is not a polynomial? \par
+There is math in each option for this question. Which expression is not a polynomial?%
+\par
+\par
\begin{itemize}[label=$\odot$,leftmargin=3em,]Is there one too many PR tip: Before/after testing is easier for me if incidental source changes (i.e. sample-chapter) are on their own commit, and they precede code changes. Then I can rollback with only code changes. And it is hard for me to split myself since I lose author information and then have to add that back manually. I have |
Clear. Phew! |
With that one, the HTML was not starting a new paragraph for the radio buttons, so the first button was coming out in a bad place. I edited source to start a new paragraph. Now I'm unsure if maybe radio buttons should just be expected to start a new paragraph? Either my edit is fine and the tex translation needs to lose a
Got it, I will try to remember. I normally would not do such edits at the same time, but here each thing appeared to be a bug/issue with the JS rendering of the problem, and cleaning it in source made it clear it was not a JS issue. But I can do such things in separate commits.
Phew! 👍 |
Go back to the source, as an author. Should an author need to know a radio-button problem needs a new paragraph? And only for that purpose? Or should they be "allowed" to plop down the "answer mechanism" in mid-sentence just like for a |
|
The <xsl:variable name="webwork-domain">is throwing its |
|
You could set the version to an empty string when there is no WW, then use that as a flag later. |
|
Last one - maybe. -html has |
This is not ready to merge, but it is ready for some testing and feedback. I'm going to be offline the next few days, and I wanted to get some eyes on this to see what you think. The only testing I did is making the sample chapter HTML with the webwork-ptx server and it seems OK. I didn't check a diff though. And then making the sample chapter HTML with the webwork-dev server and it seems OK too.
I haven't considered accessibility, but I will before this PR is closed and merged. There needs to be aria-live somewhere.
The Runestone stuff is on, which I think should not be the case for the final PR here. It makes some console errors when the book is not actually in Runestone. I intend for this PR to just be about the static preview -> live WW mode for HTML output. Not anything having to do with Runestone. When this one is squared away, I'm finally back to Runestone (@bnmnetp).
Also it loads a js file from my school's faculty server. That will need to evolve and go into JS_Core. And there will need to be some better styling.
A future commit (in a future PR) should ditch the traditional WW results table in favor of something better. Like marks of some sort right where the answer blanks are. But done accessibly.