IZI - easy tool for feedback

SYLVIE THOUESNY

School of Applied Language and Intercultural Studies
School of Computing
Dublin City University, Dublin, Ireland

Abstract

IZI - easy tool for feedback is a web-based computer-aided application for the provision of successful corrective feedback by language teachers in order to improve the second language learning abilities of the learner.

A series of tools are proposed to handle repetitive, time and energy consuming tasks. In doing so, the teacher will have the possibility to concentrate their effort on the errors that need more attention.

The implementation is designed in accordance with the reading and not restricted to one operating system or one language in order to be accessible to a large audience. The hardware requirements will depend on the number of students.

The short name IZI corresponds to the phonetic transcription of the word "easy" in "easy tool for feedback" and highlights the straightforwardness of use of this application.

We are convinced that learning is a search for meaning and we see learning as a dynamic process in which we construct our own understanding of the world, our own world. Constructivism refers to the concept that learners do not passively absorb knowledge but build it themselves. This philosophy of learning has consequences for teaching strategies and therefore for feedback strategies.



Introduction

We know that the absence of error corrections will lead to the fossilization phenomenon (Selinker & Lamendella, 1979) where the learner will stop the process before reaching the target language competencies. Non adapted feedback will lead to the exact same phenomenon. Error correction is one way to keep the learner focused. According to Mantello (1997), the correcting error phase of any second language teacher is one of the most frustrating tasks, correcting the same errors over and over again. But we have to keep in mind that feedback has an effect on learner uptake (Heift,2004). The more explicit the feedback, the more likely students will revise their errors. Since teachers work most of the time under pressure because of large numbers of students, there is therefore a need for a method to help them provide efficient feedbacks quickly.

Firstly, we will provide an overview of what an error is, since we are supposed to correct errors commited by learners. Boundaries between error, non-error and mistake will be fixed.

After clarifying the meaning of the word "error" , we will then discuss different types of errors and provide the user, i.e. the teacher, with a five error type classification.

Feedback will be then defined and different methods providing efficient corrections will be underlined.

In the following section, we will list the requirements to install IZI on a server and show that no additional software or extension is required for the user to access and use this CALL application. The system architecture and the configuration of the database will also be described in order to give an overwiev of the application's functionalities.

Finally, in the last section, the most relevant operations that run on this application will be listed and explained. We will show how cookies were used to store and retrieve information on the client's computer. We will discuss the integration of a platform independent web based Javascript editor. We will highlight the automatic actions performed by the computer when the teacher creates a new assignment, corrects a student's submission or asks for an error report. And finally, we will explain that removing a student from the database does not just imply a simple deletion.

 

In addition, the term "student" has been used in this report, as generic term for any individual who attends to learn a second language. This could be applied to anybody ( e.g. pupils or adults) and should not be restricted to individual for whom an education institution maintains education records. And the term "teacher" has been used to describe someone whose job is to teach.

What is an Error?

Error versus non-error

We are certainly not considering the speech of a two year old child as ill-formed or incorrect, so what is an error? In the case of second language acquisition, what we have to do, according to Ellis (1997), is to compare the learner's production with what seems to be the normal or correct sentence in the corresponding target language. Here is an example of a common error in German when trying to translate the sentence "he asked me for a favour" :

"Er bat *mir (must be "mich") um einen Gefallen".

The dative instead of the accusative case has been employed and in that particular example the error is clearly identified.

Errors deviate from the norm of a specific language. Some countries have instances to rule the use of their languages, some others do not. One of the particularities of a language is that it may have several dialects. A dialect is a geographical subdivision with particular characteristics in phonetics, vocabulary or syntax. For example, in south Germany they use the verb "kehren" for "to sweep" and "fegen" elsewhere; "kehren" and "fegen" are two words to express the same meaning depending on the geographical situation.

Another example is the use of the perfectly correct construct "after + verb in ing" in Irish English to indicate a recently performed action, such as "I am after doing it". This, though, will be considered by a native American English speaker as an ill-formed sentence.

A learner of English as second language will not be confronted to the differences between the several varieties of English, since the norm taught to foreigners is the Received Pronunciation, also known as Oxford English. The output produced by the learner will be considered as incorrect if it differs from the norm, even if the production may be right in one particular variety. Example: "my car needs washed" will be marked as incorrect since the sentence differs from the norm, which should be "my car needs to be washed". This however can be regarded as perfectly correct in Scottish Standard English. A learner of German will not be as lucky, since not all "Länder" agreed to the German Spelling Reform.

Error versus mistake

A deviance from the norm produced by a native speaker due to tiredness or emotional states will be considered as a slip of the tongue. In other words, an error that affects the performance rather than the competence of a speaker is an occasional error. Ellis (1997) distinguished between errors and mistakes, where errors represent gaps in a learner's knowledge and mistakes occasional lapses in performance. How to be certain to properly differentiate between errors and mistakes committed by foreign language learners? An error affecting the performance will be occasional or unsystematic, whereas an error affecting the knowledge or the competence of the learner will be described as systematic (Corder, 1967).

Errors are significant in several ways. They provide information about how far the learner has progressed and how a language is learned; finally they are indispensable to the learner in order to progress.

What we are interested in, in this paper, is to find from which kind of feedback are learners the most likely to learn from their mistakes and, to adapt the different types of feedback, we must first categorize the errors.

Error Categories

Global versus local error

An error can affect a whole sentence or a single word and even inside a word, a single morpheme. The first distinction to make is between global and local errors. A global error makes a sentence difficult to understand whereas a local error affects a single components and do not compromise the meaning of the sentence. The following example of global error is borrowed from Ellis:

"The policeman was this corner whistle but it was too late."

This sentence is difficult to understand because the basic structure is wrong (1997:20).

Type of errors

Several models of error classification have been proposed. Mackey & al (2000) suggested a four error type classification: phonological, morphosyntactic, lexical and semantic errors.

A phonological error refers to the pronunciation and is, in our case, not relevant since the errors to be analysed are written errors. A morphosyntactic error, according to Mackey & al, is about sentence formation and structure, and word order. The following example (2000:480) illustrates this type of error:

"There is a three bird my picture"

where the plural "s" and the preposition "in" have been omitted and an article "a" has been added.

A lexical error can refer to either a mispelled words or an inappropriate lexical choice. According to Suzuki (2004), the misuse of the word people in:

"Her mother gave birth to one people"

is not to be analysed as a number agreement error or grammatical error, but rather than to be considered as an inapropriate lexical choice since the word people may refer to baby.

A semantic error is a semantically inappropriate word in context.

"Colorless green ideas sleep furiously"

This sentence (Chomsky, 1957) is a perfectly grammatically correct sentence but whose meaning is absurd .

 

This project will consider five main categories of error types:

 

Syntactic error

A syntactic error will be related to the syntax of a sentence. Syntax can be described as the study of the rules that govern the word order in a sentence. Syntactic errors will not only refer to the order of components in the sentence but also include the omission or addition of elements in the sentence.

 

Morphosyntactic error

A morphosyntactic error will only be caracterized by an incorrect, misplaced or not present morpheme in a semantically correct word.

 

Misspelling

Misspelling will refer to lexemes that are semantically correct but incorrectly spelled. A misspelled word does not alter the meaning of the overall sentence in any ways.

 

Selection error

A selection error will refer to lexemes that do not properly transcribe the meaning that a student intended. Some errors of this type are the result of direct translation from one language to another.

 

Semantic error

A semantic error will refer to meaning representations of words. An error may be caused by ignorance of just one word, but could affect the meaning of an entire sentence.

 

We have to differentiate between morphosyntactic and syntactic errors, where the former suggests rather a wrong or missing inflection on a semantically correct word than a wrong order or an ill-formed sentence, which corresponds more to the latter.

Corrective Feedback

Definition

Lightbown & Spada defined a "corrective feedback" as:

"Any indication to the learners that their use of the target language is incorrect. This includes various responses that the learners receive. When a language learner says, `He go to school everyday', corrective feedback can be explicit, for example, `no, you should say goes, not go' or implicit `yes he goes to school every day', and may or may not include metalinguistic information, for example, `Don't forget to make the verb agree with the subject'". (1999:171)

Feedback is an indication to let learners know that their use of the language, either in the spoken or written form, is inappropriate in context. Should we correct every learner's error and how should it be corrected? Those questions, already raised in issues of error correction's reviews (Hendrickson,1978) are still relevant.

Lyster & Ranta (1997) state that the error correction's effect is related to the motivation. They add that students with low motivation perform better in oral with feedback whereas students with high motivation do better without correction. In our case, we will focus on corrections applied to written productions. Automatically generated or manually encoded annotations are two ways of producing feedback in a CALL application (Heift, 2003). Even if our application performs actions automatically, the feedback applied to errors has to be considered as manually encoded, since the teacher decides at any time of the feedback's form and content.

Types of feedback

We are convinced that an "explicit correction" (Lyster & Ranta, 1997) in written documents is never a good approach of giving feedback. It seems to be helpful at first but the rework will be too superficial with a "spoon feeding" method. Teachers however, should provide students with more or less meta-linguistics information to help them rework their text. The amount of help should really depends on the student's proficiency in language learning and the level of competency. Meta-linguistics feedback is, according to Heift (2004), the most elaborate form of feedback, in that the explanation of the error is provided without giving the correct answer.

In IZI, the error will be highlighted and easily located by the student. Error's comments however will only be accessible with either a rollover over the selection or a double click depending on the type of feedback, which allows students to decide whether they want immediate help.

 

We have determined three levels of meta-linguistics feedback in our application. The first type, called "Light feedback" , provides the student with few information, i.e. only the type of error made. This type of feedback is more adapted for advanced students rather than beginners. Students who receive this type of feedback will have to construct their knowledge by themselves and find out the right correction.

 
Figure: "Light feedback"

The second type of feedback, called "Medium feedback" , provides the student with little more information. Not only the type of error is given but an additional comment is also automatically attached to the highlighted word or group of words. This additional comment is editable and should describe an error that comes up often in the teacher's corrections. Not writing the same comments on error over and over again will save time.

 
Figure: "Medium feedback"

The third type of feedback, called "Heavy feedback" , provides the student with all information the teacher thinks is necessary for the rework. Not only the type of error and a more detailed description of the error are automatically given but also any extra personalised explanations the teacher thinks relevant. Full explanations about the error are more suitable for beginners (Heift, 2001).

 
Figure: "Heavy feedback"

According to Mackey & al (2000:494):

"If learners were able to correctly perceive all of the feedback that they received, this would results in a cognitive overload for them, if this is the case, then perceiving a limited amount of feedback is the optimal condition for the learner."

From a motivational point of view, the teacher should not overwhelm a student with too many corrections, and one specific feedback should only deal with one error in case of multiple errors in one word (Van der Linden, 1993).

Architecture and Data Description

System Architecture

IZI - easy tool for feedback is a CALL application to help teachers provide feedbacks in an easy and efficient way.

This application, installed on a server, is accessible with a url. The user can access the IZI application from any computer that has a WLAN or a LAN access if the application is installed on a local server, e.g. on the teacher's computer. The WLAN or LAN access is one prerequisite to be able to access the application.

IZI does not require the installation of any extensions, additional softwares or allocated space disk on the client since everything will be saved on the server. Even if the client has minimum ressources, users are still able to access the CALL application and submit their work. The application will perfectly run with Firefox (http://www.mozilla.com/firefox/) from version 1.0.7.

The basic requirements for setting up IZI is a system running a web server (we recommend Apache Web server software (http://www.apache.org/)), Perl (http://www.perl.org/) and MySQL (http://www.mysql.com/) from version 4.1.16.

 

The login page determines whether the user is a student or a teacher. Assuming that the user is a student, a list of assignments is displayed on the homepage. The student has the choice between submitting a production text according to the subject of an assignment posted by a teacher, viewing a feedback received from a teacher, or submitting an assignment for the second time taking into account the teacher's corrections.

If the assignment is not marked as completed by the teacher after the first feedback, the student must rework the initial production and submit it again for a second review. The assignment is then corrected again by the teacher and marked as completed.

A teacher, on the other hand, can either create, modify or delete an assignment and post it to the corresponding course, or correct submissions and sent them back to the students with appropriate annotations.

If the assignment needs to be reviewed, the option "marked as completed" is not activated and this will force students to resubmit their work. If there is no need for a rework, the assignment is marked as completed. The decision is left at the appreciation of the teacher. A five error type classification is provided to the teacher and each category may have error subcategories that are editable.

 
Figure: System Architecture

Since all data are stored on a server, they are organised with the help of a MySQL database. The next chapter will show the relation between the different tables in the database.

MySQL Database

The MySQL database (http://www.mysql.com/) has been chosen for several reasons. The main motive is because it is the most popular open source database with fast performance and high reliability. It runs on more than 20 platforms including Linux, Windows and OS/X and its ease of use is a great advantage. Furthermore the MySQL Reference Manual (http://dev.mysql.com/doc/) is well organised, clear and accessible for all levels of knowledge.

The figure below shows us the relation between the different tables and how they are interconnected to each others. All tables but the temporary ones contain a key, which is a unique auto-incremented number. The key of the "person" table is the main connector for the whole database.

 
Figure: Relation between tables

The "temp" table allows a connection between a user with valid username and password and the application. To make sure that someone could not access the account of someone else just by using information on the url; the date and time of access and the unique key of the person are temporarily stored into the "temp" table. The unique key of the person is encrypted with the AES_ENCRYPT function (128 bits encryption) using the time of connection as key.


$dbh->do("INSERT INTO temp (encryption) VALUES (aes_encrypt('$id','$time')");


Since some information are passed on the url, they are readeable and easy to understand. The CGI Environmental QUERY_STRING Variable retrieves all information passed via the url after the question mark. The string obtained is then splitted and encrypted using the same method as described above and then compared to the initial encryption stored in the "temp" table for this particular user.


my $query = $dbh->prepare("SELECT id_human FROM temp where encryption=aes_encrypt('$i','$t')");


where "$i" corresponds to the supposed user's unique key and "$t" to the suposed time of connection. If both strings are identical, the user is recognised as a valid user, otherwise the access to IZI is denied and username and password are requested again. This system seems to be secure enough, but we have to keep in mind that if there are codes, there are hackers somewhere.

This system allows more than one connection at a time and each connection will have its entry in the database. In order to limit the size of the MySQL database, the entry for a connection will be automatically erased if the user logout. However, if the connection is terminated before or without logging out, the entry will be erased after three days.


$dbh->do("DELETE FROM temp where DATE_SUB(CURDATE(),INTERVAL 3 DAY) >= today");


The "human" table recognises whether the user is a teacher or a student and stores basic information such as firstname and surname, and login and password in an encrypted format. The language field stores the user's favourite language for the interface and the courses fields resumes all courses the person is registered for.

The "subject" table corresponds to the list of all assignments created by all teachers. An entry contains a subject, a detailed description of the assignment and a due date, also attached to this entry, the date of insertion, the course and the unique teacher's key, who created this assignment. Each entry has a unique key and this key is inserted into the "assignment" table.

The "assignment" table contains an entry for each student, who follows the same course as the one stipulated into the descriptif of the assignment in the "subject" table. Each time a student submits an assignment or a teacher a feedback, the content of the submission is inserted into the "assignment" table. The student and the teacher have the possibility to save an incomplete document in a temporary table before submitting it. Once the submission or the feedback is posted, the entry in the temporary table is automatically deleted.

The "error comment" table is linked to the "error type" table and gives teachers the possibility to edit their own error's subcategories under fixed error's categories. Each entry in the "error comment" table is linked to a teacher.

 

To retrieve specific data and link tables to other tables, we use queries and sometimes queries in queries.


$dbh->do("INSERT INTO temp (id_human,language) VALUES ('$id',(select language from human where id='$id')");


where "select language from human where id='$id'" is a subquery in the main query. Subqueries are well supported by MySQL from version 4.1. However there are several ways of writing subqueries and the one we mostly used in the implementation is not supported before version 4.1.16.


my $query = $dbh->prepare("SELECT list_assignments.subject, list_assignments.content FROM list_assignment,assignment where((assignment.id_assignment='$id_assignment') and (list_assignments.id_listAssignment='$id_subject'))");


where "list_assignments.id_listAssignment='$id_subject'" is a subquery in the main query. This has been a major issue during the testing of the installation phase to find out why IZI could not write into or retrieve information from the database.

Functionalities

This section describes a range of some of the most important operations that run on IZI and that are transparent to the user.

TinyMCE Editor

TinyMCE (http://tinymce.moxiecode.com/) is a platform independent web based Javascript HTML WYSIWYG editor control released as Open Source under LGPL by Moxiecode Systems AB. It has the ability to convert HTML TEXTAREA fields to editor instances. It has been integrated into IZI to allow users, i.e. students or teachers, to edit text in a user friendly way. It has common features found in most text processors. Teachers and students do not have the exact same set of tools to edit their text, the "underline" and "strikethrough" styles are reserved for correction purposes.

 
Figure: tinyMCE editor

Since tinyMCE is 100% Javascript, the first step taken before its integration was to learn and understand Javascripts.


<script language=\"javascript\" type=\"text/javascript\"
src=\"../tinymce/jscripts/tiny_mce/tiny_mce.js\"></script>
<script language=\"javascript\" type=\"text/javascript\">
	tinyMCE.init({
		mode : \"exact\",
		elements : \"teacherFeedback\",
		language : \"$language\",
		theme : \"advanced\",
		content_css : \"../styleEditor.css\",
		browsers : \"msie,gecko,opera,safari\",
		width : \"100%\",
		height : \"330\",
		...
	});
</script>

Retrieving information from tinyMCE editor is the exact same procedure as retrieving the content of any text area. Special characters in teacher's or student's submissions are then converted into HTML entities to avoid misinterpretion by browsers, which ensures a clean display of all characters even if the character encoding configuration is not set to "Unicode UTF-8".


$input=~s/à/&agrave;/gi; #à
$input=~s/á/&aacute;/gi; #á
$input=~s/â/&acirc;/gi; #â
$input=~s/ã/&atilde;/gi; #ã
$input=~s/ä/&auml;/gi; #ä
$input=~s/å/&aring;/gi; #å
...
Cookies

Cookies are information stored on the user's computer by the web browser at the request of the application. We use cookies to keep variables active when navigating through the application, such as the language of the interface.

 


# Place cookies on the user's machine
$cookie="language=$language; path=/; expires=$expDate; $secure";
print "Set-Cookie: ".$cookie."\n";

#read cookies
$rcvd_cookies = $ENV{'HTTP_COOKIE'};
@cookies = split /;/, $rcvd_cookies;
foreach $cookie(@cookies){
	$cookie=~s/ //gi;
	($key,$value)=split(/=/,$cookie,2);
	if($key eq "language"){
		$language=$value;
	}
}

Since IZI uses cookies to store temporary information, we have to make sure that the user's browser is set up to accept them, otherwise the application will not run properly.

New assignment

Teachers can submit new assignments by simply selecting a course, inserting a subject, a content and a due date and they may decide to inform their students about it via e-mail.

 
Figure: Due date and email

Before sending an assignment into the database, the assignment is date-stamped, the content of all fields is required, the due date format is checked to make sure it corresponds to the database format and it is also compared to today's date to avoid impossible deadlines. When all these requirements are validated, the content and the subject of the assignment are then checked for HTML entities, the unique identification number of the new assignment is attached to the unique identification number of the teacher and of any student that follows the course selected by the teacher. A new entry is created into the database to store future submissions and feedbacks. If the "send E-mail to students" box is checked, then each student is informed about the new assignment via e-mail.

 

Insert the assignment into the database:


... $dbh->do("INSERT INTO list_assignments (subject, content, courses, duedate, datecontent, id_teacher) VALUES('$subject_s', '$newAssignment_s', '$codeCoursesTeacher[$j]', '$dueDateDB', '$today', '$id')");

#retrieve the code of this assignment
my $query = $dbh->prepare("SELECT id_listAssignment
	FROM list_assignments where id_teacher='$id' and
	subject='$subject_s' and duedate='$dueDateDB' and
	datecontent='$today' and content='$newAssignment_s'
	and courses='$codeCoursesTeacher[$j]'");
...

 

Link students to the new assignment:


...
if($codeStudent eq $codeCoursesTeacher[$j]){
	$dbh->do("INSERT INTO assignment(id_student,id_subject)
	VALUES('$ids[$i]','$id_subject')");
...

 

Send e-mail if the corresponding box is checked:


...
if($emailCheck eq "1"){
	$mailtype = "content-type: text/html";
	open ( MAIL, "| /usr/lib/sendmail -t" );
	print MAIL "$mailtype\n";
	print MAIL "From: $mailTeacher\n";
	print MAIL "To: $mails[$i]\n";
	print MAIL "Subject: $codeCoursesTeacher[$j]\n";
	print MAIL "\n";
	print MAIL "<!DOCTYPE html PUBLIC \"-//W3C/
/DTD HTML 4.01 Transitional//EN\">\n"; print MAIL "<html>\n"; print MAIL "<head>\n"; print MAIL "<meta content=\"text/html;charset=
ISO-8859-1\" http-equiv="Content-Type\">\n"; print MAIL "</head>\n"; print MAIL "<body>\n"; print MAIL "... print MAIL "</body></html>\n"; print MAIL "\n.\n"; close ( MAIL ); } ...

"Sendmail" is an electronic mail transport agent, which does not provide a user-friendly interface, it is used to deliver pre-formatted messages. The language of the email's content will be the same as the teacher's interface.

Correction

The correction phase, the core of this application, is designed not only to help teachers provide effective feedback, but also to help them correct their student's submissions quickly. The student's submission is displayed in the editor. The teacher simply highlights the word or group of words that needs to be reviewed by the student and chooses a type of error to be applied to the selection.

 
Figure: Type of error

If the text in the editor corresponds to a second submission, then the first feedback is displayed on the right hand side of the screen as a reminder of what had to be reviewed.

Each comment's error requires a unique identification number, which is used by Javascripts to make it hidden or visible.

 

hideObject and showObject functions:


function hideObject(id){
	document.getElementById(id).style.visibility=\"hidden\";
}

var zindex=1
function showObject(event,id){
	...
	var obj=document.getElementById(id);
	obj.style.left=event.clientX+Xpos+\"px\";
	obj.style.top=event.clientY+Ypos+\"px\";
	obj.style.zIndex=zindex;
	obj.style.visibility=\"visible\";
	++zindex;
} 

The incrementation of the unique identification number stops in some cases, such as logging out of the session. When the user comes back to continue the correction's phase, the incrementation must restart where it stopped. The editor's content is then scanned to retrieve the last number.


#retrieve windows identification if any
$highest=0;
$tempEditor=$text;
@editorWords=split(/\s/,$tempEditor);
foreach $editorWord(@editorWords){
	if($editorWord =~m/id=/){
		$editorWord=~s/id=\"(.)(\d+)/$1 $2/;
		if($2>$highest){
			$highest=$2;
		}
	}
}

When clicking on the "apply a correction to the selection" button, the error comment, type of error, identification number and additional comment are passed as arguments in a Javascript function that links a hidden box (HTML <DIV> tag) to this selection. This hidden box will be revealed with a rollover over the selection.


<input type=\"button\" name=\"$name\" value=\"$value\" onclick=\"errorType('$value', '$errorLetter', '$highest', form.$predefined.value)\">


The Javascript "errorType" function attaches the comments to the selection as determined by the teacher.

The following code shows a part of the "errorType" function and the replacement of the selection by the selection itself attached to the hidden window that contains all teacher's comments for this particular selection.


...
var replacement=\"<a class=error onClick=window.open (\'popup.pl?\" + additional +\"\',\'comment\', \'height=150, width=300, top=100, left=100, status=yes, toolbar=no, menubar=no, location=no, resizable=yes\'); onmouseover=showObject (event,\'\" + type + num + \"_\" + idComment + \"\'); onmouseout=hideObject (\'\" + type + num + \"_\" + idComment + \"\'); >\" + text + \"< div id=\" + type + num + \"_\" + idComment + \" style=position:absolute; left:10; top:10; z-index:1; visibility:hidden; >< table width=150 cellspacing=0 border=0><tr> <td align=center class=topnote> <font class = titlenote> \" + title + \"</font> </td> <td align = right width = 24> <img src = \'../images/plus.jpg\ '></td></tr> <tr> <td class=note>< font class = textnote> \" + comment1 + \ "</font></td> </tr> </table> </div> </a> </form>\";
...


The personalised comment is displayed in a popup window after a double click on the selection. This window will be automatically closed with the "onBlur" event that calls the "self.close()" Javascript function.


<body bgcolor=\"#b7b7b7\" onload=\"window.focus();\" onBlur=\"self.close();\">

Error report

An error report may be seen at any time during the correction phase by the teacher with a click on the "error report" button. This report sums up all error's categories and subcategories, and computes their frequencies in the student's submission. This report may be attached at the bottom of the assignment depending on the teacher's decision by simply checking the "attach report" box and make it visible to students.

 
Figure: Error report

if($box{'errorLog'}==1){
	#retrieve count of error according to the type
	$tempEditor=$teacherFeedback;
	foreach $errorLetter(@errorLetters){
		$count{$errorLetter}=
		&getCountEachErrorType($tempEditor,$errorLetter);
...
	@errors=&getIdErrors($tempEditor);
	%hashReport=&getReport(\@errors);
	$reportToInclude=
	&getStringReport($allCounts,\%hashReport);
...

#return the error type and its id from database
sub getIdErrors{
	local $input=$_[0];
	local @editorWords;
	local @result;

	@editorWords=split(/\s/,$input);
	foreach $editorWord(@editorWords){
		if($editorWord =~m/id=/){
			$editorWord=~s/id=\"(.)(\d+)_(\d*)/$1 $3/;
			push(@result,"".$1."@".$3);
		}
	}
	@result;
}

For each error encountered in the document, the application checks the type "$1" and increments the count of this particular error, its description is then retrieved from the database with its identification number "$3" and the report is displayed on the screen or stored into the form of a variable and attached to the assignment.


$teacherFeedback_s=$teacherFeedback_s."<br><br><table class=\"maintable\"width=\"100%\" height=\"100%\" align=\"center\" border=\"0\">".$reportToInclude_s."<tr><td> &nbsp;</td></tr></table><br>";

Deletion of students

Only an administrator can delete students from the admin pages. One or more students are simply selected and then removed from the database. The function does not just imply the deletion of their surname and firstname but also implies a backup to a text file of all their works since their registration.

Information about all assignments (submissions, feedback, due date, content, subject, grade, date of submissions, teacher) is printed into a file and then permanently removed from the database.


open (OUT,">$file");
my $query = $dbh->prepare("SELECT Sub1,Sub2,Feed1,Feed2,dateSub1,dateSub2, dateFeed1,dateFeed2,grade,id_subject FROM assignment where id_student='$toDelete[$i]'");
...
my $query = $dbh->prepare("SELECT subject,content,id_teacher, courses FROM list_assignments where id_ListAssignment= '$subjects[$j]'");
...
#print OUT information
...
$dbh->do("DELETE from human WHERE id='$toDelete[$i]'");
$dbh->do("DELETE from assignment WHERE id_student= '$toDelete[$i]'");


Conclusion

The aim of this project was to build a CALL application to help teachers correct the submitted productions of their students via a web page without the need to install extensions or softwares on their computers. Teachers make annotations according to proven methods by using customised tools.

Firstly, we have defined the meaning of the word "error" and proposed a five error type classification. Each category may have subcategories that are fully editable by the user, i.e the teacher.

We have then discussed the three different methods of feedback called "light", "medium" and "heavy feedback" .

The system architecture of the application has been explained, all requirements for a proper installation detailed and the major components of the database and their interconnections highlighted.

In the "functionalities" section, we have explained some of the most important features of this application, features that are automatically computed and fully transparent to the user.

 

All these components should help improve the acquisition of a second language. We insist on the word "should" because the testing phase has been realised in a judgemental way. The evaluation is based on a pre-determined set of examinations (Chapelle, 2001) such as "Is the application accessible to computer novices?", "Will students learn more about the target language through the use of this application?", "Will teachers have a positive approach to this tool?" .

The practicality of this application is unquestionable. It has been tested with very young children, who have no special abilities at computing. All "testers" succeed in writing, loading, saving and submitting an "assignment" whitout further explanations. Furthermore, the online help was not yet implemented at the time of the test. Icones have been designed to be meaningful on their own and all graphics have a contextual help.

About the impact of the application on students, IZI received good "feedback" and has been judged as efficient and pleasant tool to use. It has been proposed that IZI should not be restricted to second language learning only. However, no one really has had the time to test it more carefully because of examination preparation period.

IZI received a good appreciation from teachers, and valuable improvements have been proposed such as the possibility to edit the main error's categories; the five error type classification might not suit every teacher's point of view. It has also been suggested that having a global report for all assignments of one student or all student's reports for one particular assignment would be useful to detect particular aspects of language teaching.

 

The next tasks will be to implement all these recommendations to improve the functionability of IZI and to evaluate the application empirically in order to measure the real impact on student's learning abilities.

 

The aim of this project was also to demonstrate our ability to planify a task, to solve problems with already acquired or new competencies, to understand new area of computing and to adapt ourselves to strict deadlines.

The ability of programming in Perl and implementing efficient subroutines have been significantly improved. Consequent progresses have been made in the learning of the MySQL database, or more particularly in the domain of encrytion and requests to access, create, alter or drop information. The knowledge of Unix and the use of the command Shell to directly communicate with the operating system have been an important step during this project. "Introduction to Linux" by Machtelt Garrels (http://tille.xalasys.com/training/tldp/) is still a bedside book. How cookies work has been easily undestood and adapted to the application.

But more important than all significant improvements and learning outcomes described above, has been the learning of Javascripts. They were a complete unknown and abstract domain of knowledge. Javascripts are sometimes less convenient than subroutines in Perl and requires more code lines for the exact same result. However events on mouse, such as click or rollover are really usefull and not so complicated to implement.

Acknowledgement

Many thanks to Françoise Blin, who has supervised this project from the beginning and who has dispensed very useful pieces of advice about teaching, to Trude Heift for having sent valuable papers on feedback, to Karine for having corrected the most obvious errors in English, to Raphaël for having tested every function, every button, every thing to track bugs and for his graphical abilities and finally to Fany for having performed the first test in real condition and for her precious comments.

References

  1. Chapelle, Carol. A. (2001). Computer Applications in Second Language Acquisition. Cambridge University Press.
  2. Chomsky, Noam. (1957). Syntactic Structures. The Hague/Paris: Mouton.
  3. Corder, S.P. (1967). The significance of learners errors. IRAL 5: 162-169.
  4. Ellis, Rod. (1997). Second Language Acquisition. Oxford University Press.
  5. Heift, Trude. (2001). Error-specific and individualised feedback in a Web-based language tutoring system: Do they read it?. ReCALL 13(1): 99-109.
  6. Heift, Trude. (2003). Multiple Learner Errors and Meaningful Feedback: A Challenge for ICALL Systems. CALICO 20(3): 533-549.
  7. Heift, Trude.(2004). Corrective Feedback and Learner Uptake in CALL. ReCALL 16(2): 416-431.
  8. Hendrickson, J. (1978). Error correction in foreign language teaching: Recent theory, research and practice. Modern Language Journal 62: 387-398.
  9. Lightbown, P. M. & Spada, N. (1999). How languages are learned. Oxford University Press.
  10. Lyster, R. & Ranta, L. (1997). Corrective Feedback and Learner Uptake. Studies in Second Language Acquisition 20: 37-66.
  11. Mackey, Alison, Gass, Susan, & !McDonough, Kim. (2000). How do learners perceive interactional feedback? Studies in Second Language Acquisition 22: 471-497.
  12. Mantello, Maria. (1997). Error correction in the L2 classroom. Canadian Modern Language Review 54(1).
  13. Selinker, L. & Lamendella, J. (1979). The role of extrinsic feedback in interlanguage fossilization: A discussion of "rule fossilization: A tentative model". Language Learning 29(2): 363-375.
  14. Suzuki, Mikiko. (2004). Corrective Feedback and Learner Uptake in Adult ESL Classrooms. TESOL & Applied Linguistics 4(2). Retrieved 26/02/06, from http://www.tc.columbia.edu/academic/a&hdept/tesol/Webjournal/archives.htm
  15. Van der Linden, E. (1993). Does feedback enhance computer-assisted language learning? Computer & Education 21(1-2): 61-65.