Hi All, We just open sourced a proctoring solution for Open edX https://github.com/perpetualny/proctoru-xblock
Thanks, -Amish On Friday, June 5, 2015 at 11:27:44 AM UTC-4, Chris Dodge wrote: > > Hello, > > Our team has embarked on a new feature to do proctored timed exams (we're > hoping to support timed exams without proctoring, should be possible but > not our primary use case). > > It's on a short development cycle as it has a hard delivery date (late > July/early August) for a customer's course launch, so we don't have a lot > written up on this right now. I'll see if I can write up a public Wiki > page. I'll try to remember to swing back to this posting and give a link to > the page. > > Best wishes, > > - Chris > > On Friday, June 5, 2015 at 3:45:31 AM UTC-4, shubham rawat wrote: >> >> Any chances of this feature being added in the near future? >> >> On Wednesday, 30 April 2014 22:28:44 UTC+5:30, stv stnfrd wrote: >>> >>> The following is a draft proposal for a new platform feature. >>> Please feel free to reply with feedback. >>> >>> Abstract >>> ======== >>> A previous Stanford class required a timed exam, so we built enough platform >>> support to be able to run timed exams in the course, but we didn't build a >>> general solution. In particular, the functionality provided was the ability >>> for an instructor to set a time limit (in minutes) for a single problem >>> component in the "Settings" of the component. The functionality of having >>> more >>> than one question on the exam was provided by creating more than one >>> response >>> in the problem component. The system then rejects any submissions made more >>> than that number of minutes after the student started the component. >>> >>> But additional support is needed to make this feature robust and usable for >>> students. In particular, students need an interstitial with a chance to >>> back >>> out before they load the exam, they need a visible countdown timer on their >>> timed item, and if a student hasn't submitted by the time the timer reaches >>> 0, >>> their last saved version should be submitted. >>> >>> We'd like students to lose work as infrequently as is feasible, and we'd >>> also >>> like the system to be transparent to students and easy to understand, with >>> buttons performing expected features (e.g. "save" button doing what a >>> student >>> expects that it will do). >>> >>> >>> Terminology >>> =========== >>> Instructor >>> a course creator >>> >>> Student >>> a course enrollee >>> >>> Client >>> a user's web browser >>> >>> Server >>> an edX instance >>> >>> Problem Component >>> A single problem (advanced or basic) that has one or more responses. >>> >>> >>> Proposed Functionality >>> ====================== >>> >>> Setting a time limit >>> -------------------- >>> >>> Functionality >>> ~~~~~~~~~~~~~ >>> An instructor should be able specify a time limit (number of minutes) for >>> completing a problem component. A student must not be able to submit work >>> after the deadline expires. >>> >>> Implementation >>> ~~~~~~~~~~~~~~ >>> A setting (``minutes_allowed``?) can be stored per problem component. >>> >>> Rationale >>> ~~~~~~~~~ >>> An instructor should be able to assign a desired time limit per problem >>> component. >>> >>> >>> Interstitial Warning >>> -------------------- >>> >>> Functionality >>> ~~~~~~~~~~~~~ >>> A student will be presented with an interstitial confirmation dialog before >>> viewing a timed problem, so that they have a chance to back out if they >>> didn't >>> intend to start the timer. >>> >>> Implementation >>> ~~~~~~~~~~~~~~ >>> After accepting the confirmation, the server will log the time at which the >>> student began the problem. This will be used to prevent a student from >>> circumventing the deadline by editing JavaScript, HTML or any local code. >>> >>> Rationale >>> ~~~~~~~~~ >>> A student could load a problem component, not knowing that it is timed. >>> This >>> dialog will explain how much time will be allotted to complete the problem, >>> so >>> that the student can begin once they are prepared. >>> >>> >>> Countdown Timer >>> --------------- >>> >>> Functionality >>> ~~~~~~~~~~~~~ >>> A student should see a countdown timer indicating the time remaining. >>> >>> Implementation >>> ~~~~~~~~~~~~~~ >>> Once a student begins a timed problem, the client is responsible for >>> displaying >>> the amount of time remaining; i.e., the client should not constantly poll >>> the >>> server to determine time remaining (though, the server does have a record of >>> this). The client will synchronize its timer with the server each time the >>> problem is opened, refreshed, or saved. >>> >>> Rationale >>> ~~~~~~~~~ >>> A student must know how much time they have remaining, in order to complete >>> and >>> submit their work. >>> >>> >>> Manual Saving >>> ------------- >>> >>> Functionality >>> ~~~~~~~~~~~~~ >>> A student must be able to manually save the current state of their work. >>> >>> Implementation >>> ~~~~~~~~~~~~~~ >>> Clicking a save button must save the current problem state in the browser to >>> the server. >>> >>> Rationale >>> ~~~~~~~~~ >>> While automatic saving could be convenient, a student should always have the >>> final say on which version of their work is submitted. A student will feel >>> more comfortable if they can save their work when they want to, knowing >>> that if >>> they were to lose connectivity before the end of the exam, their last saved >>> version would be graded. >>> >>> >>> Automatic Submission >>> -------------------- >>> >>> Functionality >>> ~~~~~~~~~~~~~ >>> The client should automatically submit work when the timer expires. >>> >>> Implementation >>> ~~~~~~~~~~~~~~ >>> If it exists, the most recent manual save should be used. >>> >>> Note: As a client may lose connectivity after saving (manually or >>> automatically) but before time expires, the server must be able to properly >>> handle these case. At grading or re-rendering time, if a student has saved >>> state in an expired problem, that saved state will be submitted and graded. >>> >>> Rationale >>> ~~~~~~~~~ >>> If a student has saved work but has not submitted before the timer expires, >>> we >>> don’t want them to lose all of their work. >>> >>> >>> Manual Submission >>> -------------------- >>> >>> Functionality >>> ~~~~~~~~~~~~~~ >>> A student must be able to submit their work before time expires. >>> >>> Implementation >>> ~~~~~~~~~~~~~~ >>> Multiple submissions and submissions past the timer expiration must be >>> rejected. >>> >>> Rationale >>> ~~~~~~~~~ >>> Students should complete and submit their work before the timer expires. >>> >>> >>> Desired Analytics >>> ----------------- >>> - Distribution of time taken >>> - Number/percentage of automatic submissions (time expired) >>> - Number/percentage of non-submissions (exam started, never saved, no >>> answers >>> attempted at time expiration) >>> >>> >>> Deferred >>> ======== >>> - Warnings: It'd be nice to warn students (flashing? beeping?) shortly >>> before >>> the time is up. This could either be at a fixed interval (e.g. 1 minute >>> before the end), or configurable per item by course staff. >>> - Per-student time limit adjustments (e.g. for a student with a disability >>> requiring extra time). >>> >>> >>> Implementation Approach >>> ======================= >>> Most, if not all of the functionality will be implemented by adding >>> functionality to the ``CapaModule`` class and associated templates. For >>> possible reuse in other module class, the functionality may be isolated in a >>> mixin class. >>> >>> -- You received this message because you are subscribed to the Google Groups "General Open edX discussion" group. To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/9f81b01d-288d-42e0-a92a-4ebd9f0251f9%40googlegroups.com.
