rezaferry lon-capa-cvs-allow@mail.lon-capa.org
Thu, 10 May 2007 15:14:04 -0000

This is a MIME encoded message

--rezaferry1178810044
Content-Type: text/plain

rezaferry		Thu May 10 11:14:04 2007 EDT

Log:

--rezaferry1178810044
Content-Type: text/plain
Content-Disposition: attachment; filename="rezaferry-20070510111404.txt"

Bridge Tasks (BTs) are open-ended, performance-based assessments.  BTs are based on a mastery-model of assessment and evaluated on a pass-fail basis.  You may use BTs in a variety of ways, from supporting the scoring of a final project, to individual lab assignments. See Introduction to Bridge Task {\ref{BridgeTask_Intro}) for a more in-depth explanation Bridge Tasks. The main features of a bridge task (\ref{BridgeTask_Features})section gives the differences between BTs and other assignments

An author creates a bridge task either by writing the XML code or by using the edit mode.  The course coordinator must then place the Bridge Task resource on his/her course's document list. The section on Bridge Task Creation (\ref{BridgeTask_Create}) describes how to author as well as set up these Bridge Tasks.

Once the course coordinator has set up the Bridge Task the student is able to open and use the bridge task. A Bridge Task handin process using the portfolio may be used by the instructors or students if they wish (See Handing In Bridge Task Files \ref{BridgeTask_Portfolio})..

There are multiple steps for creating a bridge task and setting the bridge task up so that the students is able to use it. The flow of the bridge task creation process is shown in figure \ref{BT_flowchart}.

%\begin{figure}

%\end{figure}

There are two ways of creating the bridge task. The first method is to directly edit the XML file being used (See Bridge Task XML Editing \ref{BridgeTask_XML}). The second method is to use the LON-CAPA online edit mode (See Bridge Task Mode Editing).

Once the bridge task is created and published, the course coordinator must insert the resource in the course's document list (See Setting Up Bridge Task \ref{BridgeTask_SetupResource}). The course coordinator may also create slots to limit the place/time the bridge task may be opened (See Using Slots in Bridge Task \ref{BridgeTask_Slot}). This resource may also be placed inside conditionals resources so that it is accessible only after a particular condition has been met.

There are many ways in which BTs differ from other assessments.

\begin{enumerate}
\item \textbf{Multiple Versions}. There are multiple versions of a BT. A person taking a BT may receive a different version than the person taking the same BT sitting next to him or her. To create BTs that have different versions, the instructors who created the BT will create multiple sub-questions. The BT engine then chooses one of the sub questions and gives that sub question to the student, thus creating multiple versions.
\item \textbf{Essay/task based}. Bridge task questions open-ended. Users create files which they upload and submit to the system.
\item \textbf{Rubric-Based Grading}. Each question in a bridge task has scoring rubrics, criteria, associated with them. These criteria are used as the basis of grading. The grading page provides the criteria checklist on which the grader enters whether a student passes or fails each criterion. This ensures inter-rater reliability among multiple graders.
\item \textbf{Mandatory and Optional Criteria}. Some criteria can be made mandatory, that is a student will fail if the student does not pass that criteria. Some criteria are optional and the student must pass a certain number of these optional criteria. Criteria are associated with questions, which can also be made optional or mandatory. LON-CAPA calculates whether a student has passed or fail based on the number of mandatory and optional questions the student has passed.
\item \textbf{Automatic Bookkeeping}. The system calculates whether the student has passed a BT or not and records it into the database. The system stores
\begin{itemize}
\item a complete record of the BT each student received
\item when each student’s BT was administered
\item the BT instance
\item the files the student turned in
\end{itemize}

\item \textbf{Sequential Bridge Tasks}. The system can be set in such a way that a student can only take a certain bridge task after passing the previous bridge task on the list. This is done using conditionals in LON-CAPA. There are other ways to use conditionals and bridge tasks to customize the usage of bridge tasks in a course.
\item \textbf{Slots}. Slots can be created to relate students with time and location. This allows control of where and when a student can take a bridge task.
\item \textbf{Proctor Authentication}. Slots also allow a particular proctor to be in a particular location for a bridge task. Each student who is scheduled to take the bridge task must be authenticated by the proctor.
\end{enumerate}

Bridge tasks consist of one or more individual tasks that describe what the student is to do, usually in the form of a problem to solve.  LON-CAPA supports the creation of multiple versions of each task, so that each student may receive a mix of randomly assigned tasks to perform. Students use LON-CAPA to view the bridge task.  LON-CAPA supports the scheduling of BTs to restrict access by IP address range and to allow students to schedule slots of time to take a BT.

When students complete a BT, they upload files they have created for grading. Files are uploaded using LON-CAPA's portfolio system.

LON-CAPA supports the creation of scoring rubrics associated with each individual task to guide graders and ensure inter-rater reliability among multiple graders in a course. Instructors specify criteria to assign an overall score to a BT based on the scores of the individual rubrics.

BTs are used in Michigan State University's CSE 101 course. The course is designed to teach computer competencies by having students solve problems using a variety of computer software  (MS-Word, MS-Excel, World Wide Web, and MS Access).  In CSE 101, BTs are used for summative assessment, the majority of students' grades are based upon the BTs.  Here, students must successfully pass a BT before attempting the next BT.  A student's final course grade is based on the highest level BT passed.  The CSE 101 class is quite large, approximately 2000 students per semester.  Students may take up to one BT per week; typically there are over 14,000 BTs administered per semester. Thus there is a need to quickly and accurately access students.  LON-CAPA successfully supports the load requirements.

After a student finishes creating the Bridge Task, the student must hand in the files. There are many ways to do this, students can email the files necessary, or students can email a link to the instructor that shows where his files are. LON-CAPA provides a way to upload file using the portfolio. The portfolio is a space given to each student which can contain files and is shareable.

The process of handing in files consists of:
\begin{enumerate}
\item Select the files to be submitted
\item Submit the files
\end{enumerate}

At the end of every bridge task there will be a box to submit files in the portfolio for grading. When the student click on the link "select portfolio files", a new window is opened showing the content of the student's portfolio. The student can create directories in the portfolio and upload files using the upload file buttons.

Once the files that are needed are uploaded, the student select (by checking the checkbox next to the filenames) of all files that he needs to submit to the instructor. Once all files needed are checked off, the student needs to press the "select checked files and close window" button.

By pressing the close window button, the student's portfolio window should close, and the student should see his or her Bridge Task Page. The text field in the upload files into portfolio should contain the list of names. The student must then press 'submit answer' to submit the answer to be graded.

If the student needs to resubmit the file, the student must repeat the process and check off all the files (not only new files) that needs to be submitted. Once a file is submitted, the student may not overwrite or delete the files.

The first step in making bridge tasks available to students is to include it in the document space. To do this:
\begin{enumerate}
\item Enter the course coordinator space for the course
\item Go to "Course Documents" and click on import. This page gives the list of files that you have created.
\item Select the bridge task and press import to insert the file to the list of documents.
\item After importing the document, you must re-initialize the course.
\end{enumerate}

Now the assignment is in the list of documents, but it is not available for students. There are two ways of making bridge tasks available to students. One method is by using slots (the default method), which restrict the bridge task document to open at certain time/place only. The other method allows students to take bridge task like any other Lon-CAPA assignments, that is at any time they want within opening and closing dates. This method does not restrict the access to particular computers or rooms.  Any student in the course may open the BT.

If you want to use slots, first create the slots (See Bridge Task and Slots \ref{BridgeTask_Slot}). Once the BT is imported (and slots are created) go back to the document list and click on the bridge task resource, this should take you to a page that shows the resource content. If you are not using slots, click on the bridge task resource. Whether using or not using slots, click on PPRM (a button on the top menu) to modify parameters for this resource.

Set the opening date and the due date (if any) in the for resource column. To do this, click on the * in the in course for resource column. A pop up should appear. Enter the date you want the resource to be available and click the store link.

If you are using slots:
\begin{enumerate}
\item Change the "Use slot based access controls" parameter to "Yes".
\item Change the "Slots of availability" parameter for the course in for resource column to the name of the slot that you created. You may need to change the input type (the combo box at the top of the popup) to 'String Value' instead of 'default'.
\end{enumerate}

If you are not using slots:
\begin{enumerate}
\item Change the "Use slot based access controls" parameter to "no" by clicking on the * in the for resource column
\end{enumerate}

The bridge task should now be available to students. To see the BT in the student view, switch to a student role in your course.  Navigate contents and click on the resource.

To restrict the when and where BT's can be taken, the slots feature of Lon-Capa is used. Slots allow the instructors to specify the room, the time, the students that can take the Bridge Tasks, and finally any proctors that will authenticate the students.

The LON CAPA .task format is an XML file used directly by LON CAPA. XML is a markup language, much like HTML.  A primer on XML is given in section 9. An XML file contains elements in tags, and elements may contain attributes. The syntax, spelling (including capitalization) of the XML file must be exact, otherwise the XML file will generate errors.

The online editor for the .task format is discussed in the next section. This section describes creating the .task file by simply using a text editor such as Notepad.

The .task format consists of four parts:
\begin{itemize}
\item Parameter information. This part consists of the possible values for various parameters in the Bridge Task (see .Task Parameter and Variable \ref{BridgeTask_XMLVariable})
\item Questions section. This part consists of the actual text the user sees as well as all criteria and questions (see .Task Question \ref{BridgeTask_XMLQuestion})
\item Footer section. This part consists of the actual text the user sees as well as all criteria and questions (see .Task Finishing Up  \ref{BridgeTask_XMLFinishing})
\end{itemize}

Once all parts are created, the author must publish the file so that it is accessible by course coordinators (see .Task Finishing Up  \ref{BridgeTask_XMLFinishing}).

The root node of the .task format is the task element, which is an XML element written as follows:

\texttt{$<$Task OptionalRequired='0'$>$}

The Task element signifies that this is a bridge task. The OptionalRequired is a mandatory attribute, and the value (0 in this case) determines how many optional questions the student must pass.

To create difference versions of Bridge Tasks for each student, parts of the questions are defined using variables. Each variable contains multiple instances of possible values and LON-CAPA randomly selects an instance to give to the student.

All variables are placed inside a Setup element. Each setup element has an id attribute which contains the name of the variable. The possible instances or values of those variables are placed inside the setup element inside an Instance tag. Each Instance element has two mandatory attributes, the OptionalRequired attribute which should be set to 0, and the unique id of that instance. The value of the id attribute can be any text as long as it is unique throughout the document.

The actual data of the instance is placed inside InstanceText tags. Currently the instance data is created with a loncapa/perl script. In this script the parameters of the variable are set. The syntax to set the parameter of a variable is '\$variableName \{fieldname\} = "fieldValues"'. The variable name is taken from the attribute id from the Setup element, the field name is the name of the parameter the author sets, and the fieldValue is simply the value of the field. The first parameter that must be set is the instance field, with the value being an identifier of the instance. The example below shows a portion of the bridge task XML file. This portion should be placed inside the task element :Lines between$<!--$and$-->$or$/*$and$*/$are comments and should not be typed into the editor. \begin{verbatim} <!-- Create a variable named entity Subject --> <Setup id="entitySubject"> <!-- The first instance. With id instanceHarry --> <Instance OptionalRequired="0" id="instanceHarry"> <!-- The parameters for this instance --> <InstanceText> <script type='loncapa/perl'> /* The first line must be the instance id */$entitySubject{instance} = "instanceHarry";
/* The two parameters. Personname = Harry and place=zoo */
$entitySubject{personname} = "Harry";$entitySubject{place} = "zoo";
</script>

</InstanceText>
</Instance>
<!--End of instanceHarry-->

<!-- The second instance. With id instanceBetty -->
<Instance OptionalRequired="0" id="instanceBetty">

<!-- The parameters for this instance -->
<InstanceText>
<script type='loncapa/perl'>
/* The first line must be the instance id */
$entitySubject{instance} = "instanceBetty"; /* The two parameters. Personname = Betty and place=park */$entitySubject{personname} = "Betty";
$entitySubject{place} = "park"; </script> </InstanceText> </Instance> <!--End of instanceBetty--> </Setup> \end{verbatim} The example above describes a variable question. It has two different possible values for the entity "subject", Harry and zoo or Betty and park. Variables can be placed inside the questions by using the variable name and field name. The first line$<$Setup id="entitySubject"$>$creates a variable named entitySubject (based on the id attribute of this line). The first instance of this variable is shown from lines 2 to 10. Line two$<$Instance OptionalRequired="0" id="instanceHarry"$>$marks the beginning of the instance element named instanceHarry (based on the id attribute). The OptionalRequired is given a value of 0. Lines 3-9 determine the actual value of this variable. Lines 3 and 4 must be typed as shown. Lines 5-7 define the instance properties, which must be of the form \$ $<$variable\_name$>$ \{$<$property\_name$>$ \} = $<$value$>$. The first line of the property must be the instance property (see line 5 of example), with the value being the id of the instance. Other lines (6-7) can be used for any attributes you wish to define. The closing $<$/script$>$, $<$/InstanceText$>$ and $<$/Instance$>$ tags must be typed as shown.

Line 12-21 shows the second instance with the same rules as the first instance. Line 23 $<$/Setup$>$ gives the closing Setup tag which must be as shown..
The example of the usage of this variable inside the question is this text: :
This is a test question. \$entitySubject\{personname\} went to the \$entitySubject\{place\}. .

The LON-CAPA engine will replace any instance of \<$variable\_name$>$($<$property\_name$>\$) with the correct value, depending on the randomly chosen instance.

Based on this code, two different questions are possible:
\begin{enumerate}
\item This is a test question. Harry went to the zoo
\item This is a test question. Betty went to the park
\end{enumerate}

--rezaferry1178810044--