The problem with Epub. (quiz)

7 posts / 0 new
Last post

Hey.
I have a problem with Epub.

I have 3 pages with the quiz. (see link http://take.ms/aueCR) total 29 questions.
I want to on page 4 marked right or wrong answers, were summed a number of correct answers, and calculates % of correct answers (see link http://take.ms/I6OHc)

My problem is this-
Can I make this is by using Indesign?
How can I make such calculation? (scripts or programming.)

I really need help with this.
Perhaps there is a link to such a book or training course.

Any your help +1000 to karma.

THANK YOU

You might be able to do this by creating a plugin with Adobe Animate (or whatever they call it now).  Haven't tried it myself.  I would be very interested in how well it might work.  I use InDesign and insert scripts into the resulting EPUB but haven't found any way to do it from within InDesign itself.

Finally, EPUB requires an accessible declarative alternative for any scripted thing in a book, therefore one does not really need a script a all.
Assuming you have only yes or no as answer, you need for 29 questions about 536870912 documents in your book to solve the problem.
This is a lot, but you can use a script language like PHP to generate these static files and store it in the book archive.
It wil become a non linear book, the answers link to the next level of documents with the next question, the document names implicating the history.
Automatically on the last level or as last step, this results automatically in the number of correct answers in any bifurcation of the problem.

An accessible solution without scripting is possible, but because you cannot have a powerful tool like an own PHP server within the books, currently such content is something not really efficient for EPUB.
Better just to link to a web-server with such a quiz, using PHP to solve the problem online in an efficient and accessible way, available for everyone.

Hm.  Where did the number 536870912 come from?  Are you assuming that you need a declarative fallback because some EPUB Reading Systems don't support scripting?  Be aware that the EPUB WG (of which I am a member) is strongly leaning towards requiring that container level scripting (e.g. in an iframe) be a MUST in EPUB 3.1.

BTW, it is doubtful that any RS would handle millions of spine items.  I am pretty sure that Readium (for  example) would crash if it tried to load such a complex OPF. 

3.0.1 requires non scripted accessible alternatives for scripted issues, I think, this is a quite important feature of EPUB to be accessible for everyone, because one has always the complete information with a basic presentation, if one switches off CSS and JS interpretation in case of any trouble.
If this feature is dropped, such a book format would become a meaningless jam of bytes soon.

About the number of documnts: You do not really need such a number of documents, but number of links, if you do it declarative and therefore without calculation.
Because CSS styling can be switched off as well, further tricks with for example :target does not need to work as well.
The number simply results from two options for each question and you need the history at the end, if the reader should not know the number of right answers at any point, only at the end.
Knowing wrong or right after each question might be an option so get it simpler.

With frames - does it help?
May with a text input box, the audience can write down their number of right answers for each step?
But this is manual counting, not automatic.

Scripting with java-script in books?
Still it is XHTML+CSS(+ optional JS), this means, you have a layer model, the basic XHTML layer still has to provide all information, CSS and JS only add additional decoration and behaviour, no new information.
Would be surely the wrong way to rely on JS for any relevant information.
Something like noscript for firefox has always the control about this and several older viewers will have no optional script support anyway.

Obviously it is simpler to provide just a solution page with the correct answers and to leave the simple counting to the reader instead of generating a book of approximately terabyte size (uncompressed) to do the job in an accessible way.

With JS it can be simpler - but not accessible anymore.
Interactivity is not allowed for SVG content documents, therefore one has to restrict this to some simple XHTML.
With PHP on a web server it is accessible and only a few kB to get it work.

I have to correct myself.  We were strongly leaning towards making container-level scripting a MUST but have dropped it to a SHOULD due to concerns about security and privacy.  However, while the approach you are proposing is laudable, note that a fallback for JS is a SHOULD.  In my experience, if you have a complex EPUB and turn off CSS, the result may be accessible (may) but it will most like be almost if not totally illegible.  

re SVG and scripting, AFAIK (and I just reviewed the EPUB 3.0.1 spec) scripting is allowed in SVG documents.  SVG *animation* is strictly forbidden but scripting is not.  Of course, support for SVG animation is very uneven across the browsers anyway.

Scripting is allowed for SVG, but no interactivity, this means not events, it remains only linking, because this is a different chapter of SVG.

With declarative animation there might be a way to provide a graphical solution as well without any scripting for this task, but one does not get a really simple accessible number as result.
Similar decorative indication may be possible in the future, if CSS animation becomes a recommendations and CSS becomes a concept for events.
But of course, both not allowed anyway in EPUB.

Infogrid Pacific has an experimental EPUB with scripting and animation and without accessibilty concerns - that this really results in Byte jam in current viewers,
This happens, if essential accessibility features are dropped for EPUB.

Secondary menu