Transcript Porting a Standalone Intelligent Tutoring System to the Web

Porting a Standalone
Intelligent Tutoring System
to the Web
Sherman R. Alpert
Mark K. Singley
Peter G. Fairweather
Applied Learning Sciences Department
IBM T.J. Watson Research Center
POB 218
Yorktown Heights, NY USA
{alpert, ksingley, peterf}@watson.ibm.com
Porting an ITS to the Web
 Problems:
 Building intelligent educational software is difficult
and time-consuming
 Despite >¼ century of research and even technical
successes ITSs are, for the most part, in front of
only a handful of real students doing real work on
a regular basis (some exceptions, e.g., CMU
algebra tutors in Pittsburgh schools)
 Web offers unprecedented opportunity to deliver
ITSs to broad audience, in broader range of
settings (not just classroom) and amortize
development cost per student
Porting an ITS to the Web
 We had built a standalone ITS for elementary
algebraic equation solving (ran on Wintel platform - only)
 AlgeBrain focuses specifically on the skills and
knowledge involved in transforming and simplifying
equations toward the goal of solving for a particular
variable
 AlgeBrain offers a practice environment with the
benefit of a coach providing advice and remediation
Porting an ITS to the Web
 Standard problem: how do deploy our
ITS to reach real students and lots of
them?
 Solution: the Web
 But Problem: We’ve already built a
standalone tutor
 Solution: Convert existing tutor to be
Web-enabled
Standalone ITS
Porting our ITS to the Web:
Evolution, not revolution
 Our standalone ITS conformed to a popular,
widely-used, standalone-ITS architecture:
 Tutorial Module, the overall "manager" of tutorial interactions
 a cognitive simulation of an Expert Problem Solver for the tutor’s
domain; in our case, domain is equation solving, solver is rule based
 the code underlying the User Interface
 Student Model for maintaining information about the student’s
knowledge over time (full disclosure: we did not get to the point of
implementing more than a placeholder for the student model
component)
Evolving an ITS to the Web
 We wanted to reuse our existing infrastructure
and code as much as possible
 We decided that there were advantages to
having portions of the tutor reside in a
centralized location common to all users - e.g., single location for student model: though
students may log on from anywhere, the tutor
always knows each student’s current knowledge level
and position in the curriculum
 single location for code means everyone always uses
latest version; eliminate code delivery logistics
Evolving an ITS to the Web
 Wanted the UI component of the tutor
to be highly interactive, responsive,
and (hopefully) engaging, like the
standalone tutor
 required code running on the client machine
Evolving an ITS to the Web
 There are lots of choices for implementing a
Web-based app with distributed components
or single executable (see the paper)
 Due to all of the preceding constraints, we
chose to
 reuse as much of the standalone tutor code as
possible, wrapping that into an application server
 rewrite the UI component as a separate Java applet
that would run on client machines
Evolving AlgeBrain to the Web
 We started
with our
standalone
tutor’s
architecture
Evolving AlgeBrain to the Web
 Eliminated
the UI
component,
retaining the
3 other
components
essentially
as is
Evolving AlgeBrain to the Web
 Reimplemented
UI component as
a Java applet,
executable in Web
browser.
Incorporates
socket
communication
capabilities to talk
to server.
This forms client
portion of the
distributed
ITS architecture.
Evolving AlgeBrain to the Web
 Implemented
new module in
server that
"substitutes" for
former UI
component;
adds socket
communication
capabilities, and
communicates
with other server
components as if
it were the UI
module
Evolving AlgeBrain to the Web
 These 4
modules
-- very similar
to our original
standalone
design -- form
componentry of
server side of
the distributed
tutor
architecture
Evolving AlgeBrain to the Web
Internet
 Via
communication
over the
Internet, the
distributed
implementation
behaves as a
coherent whole
to users
UI Proxy Module
 Roles of the UI Proxy in the server:
 handles socket communication (send/receive to/from
"real" UI Module which now resides on client)
 UI Proxy in essence "translates" client requests and
sends requests to Tutorial Module in exact same form
as when sent by standalone UI Module, i.e., as if sent
by original standalone UI component (and v.v.: UI
Proxy accepts same input from Tutorial Module as did
former UI Module and translates for client applet)
• Hence, Tutorial Module behaves same as before -most code does not change!
• (Same for Expert Solver and Student Module)
• From standalone to application server with minimal
changes to existing code
Evolving an ITS to the Web
 Needed "language" for client/server to
communicate
 In standalone tutor, objects were in same memory
space and so could just be passed around among
objects (e.g., when user selects term(s) in eq, pass
term object(s) to rule engine (Expert Solver) along
with selected algebraic operation (e.g. "collect")
 In distributed implementation, needed a way to
communicate this sort of information between client
& server
Evolving an ITS to the Web
E.g., Client UI must inform server of student proposal
for next algebraic operation:
 Current equation, which is represented internally by a tree
structure, is linearized so each term has an ordinal position -same process performed in both client and server
 Then, when user selects term(s) and operator, client applet
transmits something like this to server:
op\collect\4\5
where "4" and "5" are the ordinal positions of the selected
terms, "collect" means 'collect like terms' op
 General form for student proposed operator/operand:
op\operator\operand1[\operand2[\operand3…]…]
Evolving an ITS to the Web
Other examples of client-server 'language':
 Client --> Server
"needHint"
"needGraph"
 Server --> Client:
”advice:<hint string>"
"neweq:<equation string>"
"right:<student proposal converted to a string1>"
"wrong:<student proposal string>”
1
e.g., "You proposed adding 20 to both sides of the
equation." These "right"/"wrong" proposal strings are
posted to History View for student to later review her
problem-solving activity.
UI Proxy Module
Again, serves 2
roles (actually 2
sub-components):
•network/socket
communicator
•translator
UI Proxy Module
 User interacts with
client UI (eg, pushes a
button); client sends
text msg to server
UI Proxy Module
 User interacts with
client UI (eg, pushes a
button); client sends
msg to server
 UI Proxy receives ASCII
message on socket &
sends translated msg &
data to Tutorial Module
as if sent by original UI
Module
UI Proxy Module
 User interacts with
client UI (eg, pushes a
button); client sends
msg to server
 UI Proxy receives ASCII
message on socket &
sends translated msg &
data to Tutorial Module
as if sent by original UI
Module
 Opposite direction
involves same sort of
translation by Proxy:
Tutorial Module sends
msg/data to UI Proxy,
which sends
"translated" msg to
Java Client
Standalone ITS
Browser-based Java UI
Alternative view of Web-based
architecture - (standard applet stuff)
Browser user surfs
to the URL for the
tutor
Browser issues
HTTP "Get"
request to server
HTTP server sends
HTML file -- with
embedded Java
applet -- to
browser
Alternative view of Web-based
architecture
Browser requests
Java code from
server and server
serves it up
Alternative view of Web-based
architecture
Browser starts
AlgeBrain Java
applet/client -applet retrieves
image and sound
files from server
Alternative view of Web-based
architecture
Java client opens
socket connection
with AlgeBrain
server component
for all subsequent
communication
Benefits of our approach
 Students can access the tutor from a standard Web
browser, need not own a copy of a standalone program
-- eliminates logistical problems of distributing software
to individuals
 Use latest tutor code from anywhere, anytime (not just
in school) (of course the "digital divide" impacts this,
but hopefully libraries and community centers can take
up slack)
Benefits of our approach
 Student model for all users resides in a single
location, on the centralized server, as opposed to
having students models for different individuals on
several different machines (within a school computer
lab, for example)
 Thus, though students may log on from anywhere, the
tutor always knows each student’s current knowledge
level and position in the curriculum and can use this
information to inform problem selection and help
content
 Argues against implementing entire tutor in single
client-based Java applet
Benefits of our approach
 Java gives us animation for free (GIF animations)
e.g., used
for animated
AlgeBrain
interface
agent
and
animated
examples in
Just in Time
Dictionary
Benefits of our approach
 Applet running on client allows for
highly interactive user experience;
e.g,:
intelligent selection of terms
directly in equations with
immediate visual feedback
interactive graphing component
that responds immediately to
user actions
Benefits of our approach
 Perhaps most importantly:
Web-based architecture we suggest
adapts and extends an architecture for
standalone ITSs that is in common
usage
Limited modification to standalone
architecture -- 3 of 4 modules remain
largely unchanged -- replace single (UI)
component
As such it should facilitate the migration
of existing standalone systems to the
Web
Closing comments
 Our architecture arose out of a project to convert an existing standalone tutor to a
Web-enabled distributed system
 The resultant architecture is certainly viable for constructing Web-enabled tutors from
scratch (starting with nothing)
 Nonetheless, remember that one of our subgoals was to reuse as much existing code
as possible
 If we were building a Web-enabled tutor from scratch we would consider the
following choices:
• Use the same architecture as we have used, but perhaps implement the server
component as a Java servlet (Java uses native OS threads for multitasking;
Smalltalk simulates multiprocessing itself and does not use native threads)
• Perhaps, experiment with shifting some
componentry from server to client:
• But, in any case, we would keep student
model on server so student can use the tutor
from anywhere, and tutor would have
continuous representation of her knowledge
and location in curriculum