[edutex] Report/Thoughts on the 08/14/09 with Frank
story at uakron.edu
story at uakron.edu
Tue Aug 18 13:44:25 CEST 2009
The following is Ross' reply to my message, some private discussion removed.
On 14 Aug 2009 at 19:44, Ross Moore wrote:
> On 15/08/2009, at 3:26 AM, story at uakron.edu wrote:
>
> > Frank and I met together for about two hours, the following are some
> > points made in the meeting.
> >
> > 1. I went into the meeting thinking that exerquiz was to be used in
> > this new system. After Frank described what he want to do, I've
> > decided that exerquiz will not be used, other components of AeB
> > such as insdljs and eforms will be used; however, a new package
> > needs to be written to implement Frank's syntax. The form fields
> > will be essentially dumb fields, so its a simple matter of
> > defining some commands, consistent with his syntax to receive
> > the student's input.
>
> Sure. With TeX would should be able to implement any reasonable syntax.
>
> >
> > A separate PDF is generated with the typeset solutions to the
> > generated test. A link, possible a button, will allow the
> > student to jump to the solutions. For non-credit, no evaluation
> > of the responses are required, it is up to the student to
> > compare his input with the solutions. The button will remain
> > hidden until the student is finished and presses the submit
> > button, one of the functions of the submit button is to freeze
> > the students' responses, make them readonly so they cannot be
> > changed.
>
> MacQTeX has solutions in the same document. Originally we had them
> hidden crudely with an opaque button. Then we changed it so that the
> solutions became the image for a button field. I think that is how
> we still do it -- Fran?
> Of course this limits what can go it solutions; e.g. hyperlinks
> would not work, with having extra buttons on top of the main one.
>
> Putting the answers in a separate document has several advantages.
> An important one is that the solutions and questions do not need
> to be created together, thus reducing the number of TeX runs when
> producing the question PDFs.
>
> >
> > 2. A MAJOR PROBLEM. Frank says that the state requires that the
> > tests to be saved. For PDF viewed in the Adobe Reader this is a
> > major problem. I suggested two possible solutions:
> >
> > a. When the user submits (credit or non-credit), the form
> > field data is merged with the particular PDF the student
> > is using; there are application for performing a
> > server-side merge of form data with the PDF. This
> > populated PDF is saved by the application, passed on,
> > and moved to the designated area on the server. It might
> > be nice to flatten this copy of the students work to
> > definitely freeze everything. I'll have to do some
> > research on the web for such applications, the cost may
> > not be too prohibitive.
> >
> > b. Here is the potentially very expensive solution. You can
> > buy from Adobe a large scale application to add extended
> > reader rights to a PDF document. Such an application can
> > give the PDF save rights and rights to make comments.
> > (Frank also said he wanted a way for the students to
> > markup their own practice tests. (See item 3)
>
> I think that there is another solution.
>
> c. For approx. $2000 per year, one can license the ability
> to unlock features that are already inside Adobe Reader,
> for use with a specialised plugin.
>
> This is how Design Science's "MathPlayer" plugin gets access to the
> Accessibility view of a Tagged PDF's content.
>
> The license fee is levied on the software distributor, as a 1-off fee
> per year. It is *not* a per-user fee.
> Furthermore, they *might* even waive this fee during the development
> phase, if they can see a prospective advantage for themselves in what
> the plug-in is doing --- and not conflicting with their own projects.
>
> These are just the views that I've formed from emails with Neil Soiffer.
> I may have stated some things incorrectly.
>
>
> Of course the downside of this is the need to provide a working
> installer for the plugin, on each platform that the students use.
> But this would be true also of a 2b solution.
>
> >
> > 3. Commenting. Frank wants the students to be able to write sticky
> > notes, or at least comment, on their own efforts at solving
> > problems. One solution is to have a dumb text fields after each
> > problem (multiline). If solution 2(a) is used, any text entered
> > into these boxes are submitted to the merging application on the
> > server side, and they would be saved along with the student's
> > responses. For solution 2(b), the student can use sticky notes
> > and save the document with save rights.
>
> Maybe we can use 2c. to enable Adobe's own Commenting features,
> and ability to save the comments (and filled Form fields)
> with a copy of the PDF.
>
> >
> > Some things Not Discussed, and other Thoughts.
> >
> > 4. Frank said that for a given test (practice or for credit), they
> > create 10,000 instances of the test, apparently using Mathematica.
> > Frank will write some additional routines for taking the output
> > and
> > creating two LaTeX files, one for the test questions, and one with
> > the solutions.
> >
> > a. Filesize: Using the number 10,000. Two PDFs are created
> > (questions and solutions). These will be small PDFs, so lets
> > assume each file is about 100K. So 20,000 x 100KB is
> > 2,000,000KB; that's 2 GB of storage space per test. I don't
> > know, but there may be a large number of practice tests over
> > a smaller amount of material. This space using quickly adds
> > up.
>
> Disk space is very cheap now.
> Yesterday our sysadmin was telling one of my colleagues about Tera-byte
> devices, as a possible solution to his storage requirements.
> (It was academic, as he didn't need anything like that much!)
>
> >
> > b. PDF Creation Time. Frank said that he can generate 10,000
> > tests in just a matter of minutes. That will change now.
> > Let's assume each PDF takes 10 seconds to build. How long
> > will it take to build 20,000 PDFs (tests and solutions);
> > that's 20,000 x 10s = 200,000 s = 333.3 m = 55 h. So it
> > would take more than two days to build the 10,000 PDFs.
> > If we use Adobe extended rights application, 10,000 PDFs
> > would have to go through this application taking an
> > unknown number of minutes per PDF.
> >
> > Probably 10,000 (x 2) is too many to be practical for PDF.
>
> But seriously, when do you need 10,000 files within minutes?
> Why would 2-3 days not be enough lead-time for a real-world test?
>
> >
> > 5. The form data of a PDF document is lost (in recent versions of
> > Reader) if the user navigates to another page (using a browser)
> > then returns. Therefore, any external link one the test page
> > that references resource material on the Internet needs to open
> > another browser window. One way go guarantee this is to use the
> > JavaScript method app.launchURL("url", true). This function came
> > into existence with version 7.0.
>
> Again, this could probably be addressed with a 2c. plugin solution.
>
> >
> > Comments welcome.
> >
> > Don
>
>
> Hope this helps,
>
> Ross
> ------------------------------------------------------------------------
> Ross Moore ross at maths.mq.edu.au
> Mathematics Department office: E7A-419
> Macquarie University tel: +61 (0)2 9850 8955
> Sydney, Australia 2109 fax: +61 (0)2 9850 8114
> ------------------------------------------------------------------------
>
>
>
>
--
Dr. D. P. Story / Dept. of Theoretical and Applied Mathematics / The University of Akron /
Akron, OH 44325 / dpstory at uakron.edu /
Personal URL: http://www.math.uakron.edu/~dpstory/
AcroTeX PDF Blog: http://www.math.uakron.edu/~dpstory/pdfblog.html
AcroTeX Web Site: http://www.math.uakron.edu/~dpstory/acrotex.html
http://www.acrotex.net
More information about the edutex
mailing list