Language Interactive Guide

Language Interactive: SCRIPTING GUIDE
Web Scripting for Language Learning

This guide provides a starting point for language teachers interested in adding interactivity to their own or student-generated Web pages. Please send additions, corrections & suggestions.
Shortcuts --> What? - Why? - How? - CGI Scripting - JavaScript - Resources & Tools
Companion Pages --> Scripting Archive / Program Linking / Index

What are Web forms?
Many language teachers are finding that the World Wide Web is a treasure chest of authentic language materials and are actively integrating on-line realia and other resources into their classes. Useful Web sites have been collected and annotated...
--> FL Resources on the Web [by Steve Thorne/Berkeley]
--> Languages [CALL Lab/Ohio U.]
...as well as put together with suggestions for using them in language instruction...
--> Teaching with the Web [by Lauren Rosen/UW-Madison]
--> Foreign Language Teaching Resources [by Jon Cardozo/Oregon]
Language teachers are likely to be interested as well in the potential of the ever-increasing number of interactive Web or Web-launched sites and programs such as "Moo"s, "Chat" sessions or audio- and video-teleconferencing...
--> Interactive Internet Language Learning [by Jon Cardozo/Oregon]
--> More about Moos [by Steve Thorne/Berkeley]
A powerful instructional use of the Web is for teachers to put their own language learning materials on-line, creating home pages through using the language of the Web, HTML (Hypertext Markup Language)...
--> Home Page Construction Kit [from GNN]
--> A Beginner's Guide to HTML [from NCSA/Illinois]
There are actually many options now available for Web page creation, including use of an HTML editor such as FrontPage, PageMill, or HomePage. Once you are familiar with the basics of creating Web pages, you can take the next step and make your pages interactive, by providing feedback to the user, or by collecting & storing information sent. This can be done in a number of ways. What we are looking at is doing it through the use of HTML "forms" which are processed by a Web server. Writing the HTML code that will display a form on a Web page is no more difficult than other facets of HTML and is covered in most on-line HTML guides (such as the HTML Quick Reference) or books on HTML.

Look at one sample form or another to get an idea of what's involved. Remember that you can always see the HTML coding for any Web page, including one with form fields, by using "View source" on your browser. Keep in mind that writing the correct HTML to display the form on a Web browser is only the first step; a script or application on a Web server must then process the form (covered in How?).


Why would language teachers be interested in Web forms?

Language teachers inevitably supplement textbooks with handouts, containing tutorials, additional exercises, readings or other materials. Electronic handouts through the Web offer several advantages...
--Exercises can provide immediate feedback to the student, including links to on-line tutorials.

--Access to materials is not time, place, or computer-platform dependent.

--A variety of help can be offered at different levels, allowing for individual customization; this includes students with special needs...

--> Instant Access Treasure Chest [by Sonja Moore/VCU]
There are no studies I know about which show the effectiveness of using the Web for language learning, but it stands to reason that if you are using the Web to make language documents available, making those materials interactive tends to activate students more. Web forms, for example, can contribute to student-centered learning by allowing students to add sites to a list of internet sources supplied by a teacher; students with Internet access are going to surf the Web anyway -- we might as well try to channel that time into something useful.

There are of course many other ways to create computer-based interactive learning, both on the Internet or with stand-alone applications such as HyperCard, Toolbook, or Authorware. Web forms are not the be-all, end-all of computer-aided instruction. Local applications can often provide more flexibility, speed and reliability than interactive Web pages and may be better choices in situations in which remote access, platform independence and centralized file management are not important. However, watch in the near future for added speed and interactivity on the Web itself through new approaches such as Java or Shockwave. For some ideas on linking programs to Web pages, you might take a look at the Program Linking page of Language Interactive.

Whatever development tools you decide to use, be prepared to spend some time learning the basics before you're ready to create your own interactive learning materials. Computer programs and operating systems are getting easier to use all the time, but it still takes work to develop something of your own. But if you do it yourself, it's tailored to what you want and you can change it anytime and any way you like. A canned program created for you by technical folks may not be easily updated or customized if you have little idea how it was put together. Of ccourse, the important reason is that you have the teaching experience and knowledge that is indispensible in creating programs for language learning. One important factor in choosing your electronic tools and toys is the degree of local support you have. It can be invaluable to have a local guru nearby who can help you over the first inevitable stumbling blocks. As with much else, getting started is the most difficult part of the process.


How do I use Web Forms?

You will need...
...a basic knowledge of HTML (to write forms)
...access to a Web server (to serve pages & run scripts)
...an ability to create/modify CGI scripts (to process forms)

None of this requires being a rocket scientist, but it does require a certain degree of technical know-how. Fortunately, the medium you'll be working in -- the Internet -- is one which carries with it a tradition and philosophy of actively supporting self-starters (mostly for free!). You may find that the hardest requirement is gaining access to a Web server. Web, or more properly HTTP (Hypertext Transfer Protocol) servers run on a variety of platforms, but most commonly on Unix computers, whose administrators are notoriously leery of allowing regular folks to run scripts on their systems.

Unix isn't the most friendly environment to be working in anyway and fortunately there are other server options. Inexpensive HTTP servers are available for Macintosh (MacHTTP) and Windows (Windows httpd) computers, although Windows 3.1 is not a recommended choice -- by me, others disagree -- (WindowsNT and Windows95 are viable alternatives). It is by no means an inconceivable task for a language teacher (or lab director) to set up a departmental Web server. My experience in setting up and operating a Macintosh-based Web server has convinced me you don't need someone wearing a white lab coat to do it for you...

--> Creating a WWW Site [by Jon Wiederspan/Washington]
--> Classroom Internet Server Cookbook [by Steven Collins/Minnesota]
Once you've gained access to a Web server and have dutifully written your HTML form, you'll need to have the server hosting your pages actually do something with the data the user sent in submitting the form. This is where a "CGI" (Common Gateway Interface) script comes in; is it either a (complied) program or a script which runs on demand when a form arrives at the server. It takes the data from the form, such as user's name, comments on a page or answer to a question and sends some response back to the user (like "Thanks for the input" or "Wrong again, Dummie") and can also save the data into a text file, send it to someone by e-mail or pass it along to somewhere else such as a data base.

CGI Scripting

How CGI scripts are written depends on what flavor of server you're running, since scripts tend to be platform-specific. The most widely used options for Unix servers, Perl and C, however, can also be used on other platforms. Visual Basic is often used on Windows servers, as is AppleScript on Macs.

If you're undecided on what kind of server (and therefore what kind of CGI scripting) to consider, I would recommend for non-programmers starting off with AppleScript running on MacHTTP (or its big brother, Webstar) for a couple of reasons:

--Learning curve not as steep as for Perl or Visual Basic
--Friendly types running servers & willing to share ideas
--Excellent on-line tutorial on CGI's by Jon Wiederspan
--Server easy to set up & maintain yet high performance
--Active mailing lists for serving, scripting and authoring
--Many helpful tools for maintaining sites & using scripts
My recommendation of a Mac server/scripting solution comes despite being a long-time (and continuing) Windows user -- I happily use the 486 on my desktop daily. However, after experience with both Windows 3.1 and Unix Web servers, I am convinced of the greater ease of use and performance of MacHTTP. Unix, of course, is the main-stream solution, but not recommended for the faint of heart, and for normal volume sites may not be worth the hassle or the security concerns Unix embodies. The CGI set-up described in this guide mostly assumes use of a Mac server, not -- I hope -- out of arrogance that it's the only way to go, but as an example which has parallels on the other platforms (and because that's the set-up I'm most familiar with).

Whichever CGI scripting language is used, you will need...

...knowledge of its basic syntax in order to use scripts
...access to the appropriate editor/compiler
...enough memory to run the HTTP server & CGI's
A good starting point for learning the basics are introductory books, which often double as reference manuals. I would recommend Randal Schwartz's Learning Perl or Danny Goodman's AppleScript Handbook. You should at least skim through such manuals first before tackling CGI scripts. Look at the simplest sample programs provided and make sure you understand how (and why) they work before you move on to looking at CGI scripts. As mentioned above, a great advantage of using AppleScript is the availability of Jon Wiederspan's extensive tutorial materials (which are inMacBinary form). After gaining a basic acquaintance with AppleScript (possibly through Goodman's book), I would recommend working through the tutorials and only then taking a look at the language learning scripts in the Archive.

The actual editors or applications you will need to create or modify CGI scripts are as a rule free (that lessens the pain somewhat). Perl is available over the Net; the Script Editor for AppleScript comes with System 7.5 and later. In most editor/compilers, you can save in a variety of formats; make sure you learn which is the one you need for CGI scripting. In AppleScript, for example, you save your script as an "application".

On the Mac side, by the way, you may notice that some CGI scripts have a "cgi" suffix, while others are "acgi"; the difference is that the second category runs independently of the server. CGI scripts on the Mac may be written in a variety of other languages. Principal among these are MacPerl and Frontier. MacPerl offers very good text handling capabilities as well as compatibility with Unix servers. Frontier, in its "Aretha" rebirth, is now free (as is MacPerl) and an increasingly popular choice for CGI's due to its speed and multi-threading capability. Another possibility is HyperCard, which can now be used with AppleScript (as well as HyperTalk) in writing scripts.

It is certainly possible to run on the same server CGI's written in different languages. For example, you might use AppleScript to links to other programs, such as Filemaker Pro and use MacPerl for text-handling CGI's. You will need, of course, sufficient memory (RAM) on your server to be able to run all of that, or even to run a series of CGI's written in the same language. One trick to save memory is to have your CGI's quit immediately after running (or after a set delay). Many of the scripts you can download are heavily commented, providing very useful information on usage and customization.

<soapbox = it's the pedagogy not the technology>
Of course, this discussion pertains only to the mechanical side of using CGI scripts. The more challenging -- and interesting -- side is the pedagogy: how to use CGI and the Web to enhance language learning. This is where your experience as a classroom langauge teacher is invaluable. Harnass the same creativity you use in the classroom to language learning over the Web and you've got a powerful combination! Helpful as well is some knowledge of the basic principles of second language acquisition. Once you become familiar with CGI scripting, don't just keep to existing models -- you'll be operating in a very powerful and richly enabling programming environment which will allow invention of new paradigms for doing things. Use the power but don't fear it -- computers can never replace human beings in a discipline involving human communication in all its cultural and linguistic dimensions.</soapbox>


JavaScript

The scripting discussed to this point has been server-based -- for HTML forms to be processed, the data from the forms is sent back to a server where a CGI script parses the data, does something with it (saves it to a file, e-mails it, etc.), and sends some feedback to the user. There is, however, another kind of Web scripting which simplifies this circuitous process. With client-side scripting forms can be processed by the Web browser on the user's local computer, without recourse to a server at all. One of the scripting languages currently available is JavaScript, developed by Netscape Corporation (requires Navigator 2.0) and Sun. Microsoft is also developing a scripting language, called Blackbird.

JavaScript is not the same as Java. Java is a full-fledged programming language allowing for creation of "applets" or mini-programs which can be run inside of Web browsers such as Netscape Navigator. Although applets appear to be integrated into the Web page displayed, they are actually independent programs and in fact Java can be used to create programs divorced from Web pages. Java applets are not part of the HTML which displays the page, although some parameters of Java applets may be set through the use of HTML. Java must be compiled (translated into computer code) before running. JavaScript on the other hand functions as an add-on to HTML and appears as text alongside familiar HTML codes; JavaScript code is interpreted and run by the Web browser when a user retrieves the Web page, it does not need to be compiled into a program.

So what's the interest in using JavaScript? Let's look at some pros and cons --

Advantages of client-side scripting:

  1. fast processing, generating immediate feedback to user
  2. more options in providing feedback to user
  3. local execution avoids vagaries of network access & allows for non-networked interaction
  4. does not require access to a Web server or knowledge of server-browser interaction

Limitations of client-side scripting:
  1. for non-programmers learning curve can be steep
  2. source code is not secure - can be seen alongside traditional HTML of page
  3. does not allow for submission or tracking of student work to server
  4. scripting not universally recognized by Web browsers (although other browers besides Netscape have announced support in the future)

So which is better CGI or browser scripting? It depends. The best advice may be to find the right tool for the purpose you have in mind. If you want to set up some comprehension self-testing or grammar drills for your students, for example, JavaScript would be definitely worth looking into -- faster, network-independent and more flexible in providing feedback to the user, as in a sample quiz (requires Netscape Navigator 2.0 or other browser with JavaScript interpretation) which illustrates different kinds of feedback (through messages in form field, in an "alert" window and in a frame window). JavaScript provides richer and more varied interactivity, approaching that possible through programs such as Authorware or HyperCard. On the other hand, if you want to do any kind of formal assessment over the Web, you need access to a server and use of a CGI script.

Of course the best of all is two have both available -- you could have JavaScript for example do some preliminary checking before a form is submitted. Another possibility is to send "cookies" (another Netscape innovation) containing, for example, encoded answers which can then be processed locally when the JavaScript page is run (see example in No-brainer quiz 2). A third option combining CGI and JavaScript might be to use a CGI form to create a customized interactive JavaScript page, as in a sample short answer quiz creator which demonstrates this kind of functionality.

If you're interested in trying out JavaScript, I would recommend looking at the HTML of the examples Netscape supplies or others that are out there. In contrast to CGI scripts, JavaScript code can be seen, dissected and borrowed using "View source" on your browser. Be forewarned - JavaScript code is computer code and despite Netscape's contention that it derives from (reasonably comprehensive) scripting languages such as HyperTalk, it definitely is geektalk and any similarity it has to English is just a passing coincidence. The documentation Netscape provides will get your started, but it's skimpy and if you're seriously interested, I'd recommend checking out Danny Goodman's forthcoming book or the others on their way.

To get started with JavaScript try first copying and pasting some JavaScript you find -- keep it simple. Next substitute your own data -- just plug in your own questions and answers, for example, in the sample quiz. Then try to customize it a bit -- change how feedback is provided to student, how many correct answers, etc.. If your Web page displays without an error message, you're entitled to go out and buy a propeller beanie.


Resources & Tools

Learning HTML is made much easier by the ability in web browsers to "View source" and find out just how that clever person created that splashy Web page. Unfortunately for those learning CGI scripting, there is no equivalent "View script" that will allow Web surfers to take a gander at how a form is processed (although you can see JavaScript in that way). This is the purpose behind the Language Interactive Archive, to provide some sample scripts to learn from. The forms and CGI scripts collected are meant as starting points -- examples of the kinds of things one might think about doing to support language learning on the Web. For the most part they only scratch the surface of what is possible with CGI scripts; your imagination and teaching experience will likely suggest many other potential uses. Scripts developed for other purposes can often be used in language instruction. Of particular interest may be scripts that help manage collected input from form, store student records in data bases and interface your Web pages with e-mail.

You will normally need to modify to a lesser or greater extent existing scripts in order to adapt them to your system. This will entail at least changing path names (and names of computers or hard drives). It may mean making more extensive changes if your system and set-up or your needs are significantly different from those of the script's author. You should see these scripts as garments to be tailored, not as ready-to-wear acquisitions. They should provide at least some basic frameworks around which to build your own creations.


Language Interactive --> Index / Scripting Archive / Program Linking
VCU - Foreign Language Department - >International Trail Guide
© 1995 Robert Godwin-Jones
rgjones@vcu.edu