A logic instructor game for the WWW

David Bueno, Ricardo Conejo, Alfredo Burrieza
Universidad de Málaga

http://www.lcc.uma.es/elcastillo/


ABSTRACT

There are two areas that can be related to get interesting results. On the one hand, the investigation about the development of Tutoring Systems (TS), and on the other hand, the WWW that is getting to more and more people everyday. Nowadays many people in the world are connected to this media that opens up unimaginable possibilities for distance learning.

The system described in this article is designed to teach the user to think in the right way using logic. One of the strategies of TS to get the motivation of the users, consists of masking the tutoring process as a game. This technique has been used here. The system is presented as a game where many logic problems, in the style of the famous logician Smullyan, are proposed to the user. Internally the system has a tutorial strategy, which generates the next problem to the user in function of the knowledge that he has about the way of solving problems.

The game is accessible through the WWW, and it has some new and interesting characteristics. The WWW lets the user move freely through the browser allowing him to go back to the other HTML pages he had visited before. This aspect interferes with the control needed to construct a user model and a tutorial strategy. This system incorporates a control mechanism to get a guided navigation through the WWW, and we show the advantages of this compared with other solutions. The system has some of the features needed to implement tutoring systems on the Net. Some of these features are (1) User profiles. - In every moment the system knows what each user is doing, having personalised information; (2) Multisession capabilities. - The user can abandon the browser whenever he wants, and the system will hold on to all the information about him, letting him continue in another session; (3) Help and topic hints about the way of reasoning; and (4) Problem generation strategies to adapt the problems proposed to the user.

The URL of this project is: http://www.lcc.uma.es/elcastillo/

Keywords: WWW, Internet, Distance Learning, Tutoring Systems, Logic, Guided Navigation


Introduction
Educatives aspects
Interface and tutorial strategies
General characteristics
System Description
Comparison with other structures
Conclusions
References
Authors


Introduction

The World Wide Web is becoming more and more important in the World, and it is reaching to many places. Distance learning can find this media very useful. It is needed to analyse how must be the communication between a client and a WWW serve r should be, because of the technical limitations of the communication between them. The main limitation is that the current browsers let the user move freely through the HTML pages, free navigation. This makes it difficult to have a tutorial strat egy and a control of the actions of each user. In this system this problem has been avoided and we use some techniques to get a guided navigation. In this way the program supervises all the actions of the user. If the user makes a mistake, the prog ram will tell him the right way of working.

Another interesting aspect is the instruction's objective. The system tries to help the user have a better way of thinking in two ways. Firstly by showing the students some techniques that can be useful to solve logic problems (in the help). And second ly by offering a series of problems organised in different levels of reasoning that will teach the user, in an incremental way, how to work with logic problems. The exercises proposed are in the style of those proposed by the famous logician Raymond Smull yan [SMULLYAN 78].

Logic is a difficult subject to teach because of the abstraction that the student can find on his first contact with the subject. That's why to get a better motivation of the student, the system masks the content of the instruction as a game. 

Educatives aspects

The program tries to offer the user knowledge about the use of the elemental logic connectives (negation, material implication, conjunction, disjunction and material equivalence) to analyse how the natural language sentences are linked. The aim is to get the user to use the connectives proposed, as tools needed to solve problems. For this reason, the student is exposed to training in the basic process of natural deduction of logic (absurd reduction, reasoning by cases, etc.).

To complete the knowledge of the users there is help where the logic particles are defined formally, each of them completed with examples in the natural language.

Interface and tutorial strategies

The program is presented to the user as a game. This game is composed of 72 screens grouped in 12 levels of difficulty. Each level has 6 screens and each of them presents a logic problem that the user has to solve (Fig.1) . The problem is presented in a scene where several characters or objects appear. They give information to the user that can be true or false. The information that the user gets with these sentences is enough to solve the problem exposed (for example, kno wing through which door he can go, the identity of a selected character, ordering the characters in function of a characteristic, etc.). The user begins with 3 lives or opportunities to solve the game.

Fig. 1. - One level of the game (the little princess and the genius always tell the truth).

The tutorial strategy of the game consists of showing the user a screen on the first level chosen randomly between the 6 possible screens on that level. If the user solves the problem, he goes on to another screen on the second level, selected, in the same way as before, among the screens available on this level. In the event of not solving the problem, the user will loose a life and the program will generate a screen that will expose in a detailed way, the way of reasoning that the user should hav e used to solve the problem. After this explanation, another screen on the level where the user failed will be displayed to check that the user has learnt the reasoning method exposed in the explanation.

Due to the dynamic generation of the phases, and to the number of options available in each stage, the possibility of finishing the game playing randomly is nearly zero.

General characteristics

In this part we will describe briefly some characteristics of the game:

Local access and through Internet. - The system works locally in a version for Windows´95 or through Internet using any graphic client of WWW.

Friendly Interface. - The way of using the program is very easy. During a game, the user should read what the characters say at each stage, and do what they say.

Multi-user. - The Internet version is designed to allow the users concurrent accesses, without any limitation on the number of these.

Multisession. - The user can leave the game in any moment of the game and when he will be back, inserting his password, he will automatically access to the stage where he was.

System Description

Fig. 2 represents the standard structure used in the WWW. It uses the client-server paradigm. Every time a user connects with an URL through Internet, the browser (client) sends a message to a process in th e server, called HTTPD (HTTP Daemon). This process will look for the document requested by the user, in the set of HTML documents existent in the server. When the page is found it is sent to the client. In this structure the documents are files of the fil e system of the server. Due to the characteristics of the connectionless of the protocol that communicates the client and the server (HTTP-HyperText Transfer Protocol) the connection is lost when the WWW server sends the documents to the client. The conce pt of free navigation appears here because the server doesn't control the sequences of pages that must be sent to the client, and he selects the documents that he wants. That's why it is difficult to control the actions of the user or to get a g uided navigation because each communication between the client and the server is independent of the others.

The system we have developed can't use that structure for two fundamental reasons. The first one is that it's needed to hold information about each user (user profiles) to make a curriculum to keep his actions, to allow the multisession, keep th e actual state of the user, generate the next level for the user, etc. The second reason is that the documents that are shown can't be static and must be personalised including state information; for example, the number of lives, the actual level, and som e dynamic information needed by the server, as the user identifier. The solution chosen is to use HTML templates, which have a general scheme of information necessary for each kind of document.

The way of managing these elements is done by the navigation control. It will take the user actions and it will analyse them to see if they are correct and it will generate HTML documents using the templates and the user profiles as well as brin ging the user profiles up to date whenever necessary. The structure of the system can be seen in fig. 3

The navigation control

This program is placed in the server machine and it's able to communicate with the HTTPD using the CGI (Common Gateway Interface). The CGI is a protocol that communicates programs with the HTTPD. Generally a program that uses the CGI protocol receives some parameters and returns an HTML document to the client. In our system, the parameters could differentiate the actions that the system should take. Some of them are: (a) Create the profile for a new user, (b) analyse a password to take an old user to h is level, (c) analyse the selection of a user in a level, (d) generate the next level, (e) receive the petition of showing the help, (f) take a user to his present level after the help, (g) show the records screen, etc. All these actions are codified in c all to the program like this:

 navigcontrol?level=2&sublevel=4&type=1&option=1&user=785&control=AzR6

 In the example there is a common level call in a scene where the user has selected one option among several possible. The information about the user is coded with a number, and there is a control field to validate all the other fields.&nbs p;

The navigation control will take the next steps: receive the string (like the one in the example above), validate the data with the control field and consults the user profile, after that it analyses the kind of action to take. It will make the necessa ry calculus to generate the next HTML document using the necessary template for that action, and finally, it will send the full document to the client.

The templates

The use of templates reduces the number of documents kept in the server, gives a lot of flexibility to create different HTML documents with a similar aspect, and lets the server move because isn't needed to keep absolute directory information. The temp lates have some special characters, that the navigation control will change for significant information to generate the documents.

We use special characters in the templates, for (a) the BASE HREF. - To make the template independent of the server (b) the CGI base directory, for the same reason, (c) the user identification. - Needed every time that a form or sensible map informatio n is sent to the server (d) the control information. - Different in each document to avoid false accesses to the program (e) the number of lives (f) different buttons. - In the same screen can appear buttons for: help, go back, restart, go on, etc.

 

Comparison with other structures

Keep information on the HTML file (1)

The first way of knowing what a user has been doing is a simple method used by some expert systems [ACQUIRE 96]. Let's think about a system, which needs to know every time the answers a user has given in order t o evaluate it, and generate the next question. (This is the way most of the expert systems works).

Suppose that the interaction between the system and the user is a form that is generated with each question by a CGI program. The method that the system uses to keep the information of the user is keeping a hidden camp in the form for each answer that the user has given. And with each new question that the server sends to the user, the document that the client receive will have all the steps that he has taken before. With this technique, every time that the system receives a form it doesn't need additi onal information because all the information is inside the form.

Using sockets and process (2)

An interesting way of controlling the actions of the users is having one process for each user in the server. There is a demon in the program that is always running. When a new user makes the first connection, the program will m ake a fork to create a process with an associated port. This process is the one that will control the entire interaction with this particular user. The only information that must go with the answers to the user, is the port number. All the knowledge about the user is kept in memory [TRELLA 97]

Comparison between the three strategies

Of the three systems the one that keeps information in the HTML file is the easiest to implement, but the less useful for Tutoring Systems. It doesn't allow multiples session and if a document is lost all the state information is lost too. The one that uses sockets is the most appropriated for Expert Systems, because if the knowledge base were very large, with the solution (1) the size of the document that keeps the working memory would grow a lot. With the solution (2) the size of the documents would be constant and the working memory shouldn't be initialised after each question. With the solution (3) (explained this article in System Description) if the working memory is kept in a file, this one should be read every time that a ne w question of the consult is received. For developing ITS, the most appropriated is the version based on user models and templates because it lets multiples sessions and keeps user information (3). The solution (2) could be used for ITS if it keeps some i nformation of the user in a file to let multiples sessions, that is, combining (2) and (3). ITS could be developed, where the user model and the screens would be generated with (3), and the expert system could be modelled with (2). The disadvantage of (2 ) is the memory space that can be wasted if a lot of users log on at the same time.

  

Conclusions

We think that the system offers something to the creation of tutoring systems on the WWW. The current tutoring systems (see [BELMONTE 96] , [VILLAMIL] , [CHRISTOPH] ), don't use the guided navigation characteristics nor have any control of the user actions or curriculum.

The structure of this system is easily expandable for developing Intelligent Tutoring Systems (ITS) in the WWW. Really this system has some of the characteristics needed for this kind of system. In an ITS there are five fundamental parts [POLSON 88]; the expert system, the module of diagnosis of the student, instructor o curriculum module, the instruction environment and the interface human-machine. All these parts are included in the system except one. The ITS is not complete due to the absence of an expert system to generate problems and solve them. That could be integrated in the server if the tutoring system required it. All the other parts are included.

References

[POLSON 88]

MARTHA C. POLSON, J. JEFFREY RICHARDSON (1988) "Foundations of Intelligent Tutoring Systems". Ed. Lawrence Erlbaum Associates, Inc.

[SMULLYAN 78]

SMULLYAN, R. "What is the name of this book?". Ed Prencince Hall 1978

[BELMONTE 96]

BELMONTE, M.V., BERBEL,J., CONEJO, r. "TEA: An Agrarian Economy Instructor System" in Computer Aided Learning and Instruction in Science and Engineering. CALISCE96 (320-330). Berlin (1996). Ed. Springer. http://www.lcc.uma.es/TEA/inicio.html

[VILLAMIL]

EDUARDO VILLAMIL, "Tutor de Lisp", http://www.cs.tulane.edu/ww/Villamil/lisp/lisp1.html

[CHRISTOPH]

CHRISTOPH U., "The Interactive Patient". http://medicus.marshall.edu/medicus.htm

[TRELLA 97]

TRELLA, M, CONEJO,R, "Dialog with an Expert System Through the Web". NAWEB'97

[ACQUIRE 96]

Acquire Inc (1996), http://vvv.com/ai/demos/whale.html



David Bueno Vallejo
Computer Engineer
Department: Languages and Computer Sciences
Universidad de Málaga.
Address: Dpto. Lenguajes y Ciencias de la Computación Campus de Teatinos 29071 MALAGA ESPAÑA
Email: bueno@www.lcc.uma.es
Web: http://www.lcc.uma.es/bueno
 
Ricardo Conejo Muñoz
Dr. Ing. Caminos, Canales y Puertos
Department: Languages and Computer Sciences.
Universidad de Málaga
Email: conejo@lcc.uma.es
Web: http://www.lcc.uma.es/conejo  
 
Alfredo Burrieza Muñiz
Dr. Philosophy
Department: Pholosophy
Area: Logic and Philosophy of the Science
Universidad de Málaga.
 
 

 


©,1997. The authors, David Bueno, Ricardo Conejo and Alfredo Burrieza, assign to the University of New Brunswick and other educational and non-profit institutions a non-exclusive license to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive license to the University of New Brunswick to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers, and for the document to be published on mirrors on the World Wide Web. Any other usage is prohibited without the express permission of the authors.