Distributed Development and Teaching of Algorithmic Concepts: Connecting to ICampus

1
Distributed Development and Teaching of
Algorithmic ConceptsConnecting to I-Campus

• Seth Teller
• MIT Lab for Computer Science and Computer
  Graphics Group
• lcs.mit.edu graphics.lcs.mit.edu
  fusion.lcs.mit.edu

2
Context and Basic Idea

• When material moves on-line
• Teachers become more remote from students,
  material being taught
• Timely feedback weakened or lost
• Certification/accreditation componentbecomes
  less certain
• Our basic idea augment on-linelearning with a
  simulation substrateproviding feedback to
  student,and diagnostic info to staff

3
Initial Goals

• Limited domain algorithmic concepts
• Students demonstrate mastery byexhibiting
  correct algorithm for concept
• Increase efficiency of teaching staff
• Less administration more involvement
• Web distribution, evaluation, feedback
• Templated development kit
• Distributed creation of new modules
• Later general simulation WebLab
  semi-automated taxonomy of effort

4
Foundational Work

• Algorithm animation
• Zeus (Brown 91) Interactive Illustrations
  (Trychin 97)
• Data-flow software architectures
• Conman (Haeberli 88), AVS (Upson et al. 89)
• Web-based teaching
• WebCT (Goldberg et al. 96), JScheme (Hickley
  97)
• Web chat, whiteboard, video, etc.
• Vat, Wb, Vic (McCanne 94)
• Stages of learning
• Perceiving structure integration acting
  feedbackreflection (Laurillard 93) Each stage
  mediated by simulation substrate

5
Fusion system Contributions

• Web-based curriculum distribution, coursework,
  evaluation, feedback
• Guided sequence of pedagogical modes
• Exploratory Manual Reference Student Verify
• Shared lab bench metaphor for student, staff
  work interaction
• Authoring kit to facilitate module development by
  other educators

6
Student Perspective

• Concept Module
• Represents algorithm, its abstraction
• Pedagogical modes
• Exploratory (algorithmic choices)
• Reference (correct, black box)
• Manual (non-algorithmic)
• Student (implement, white box)
• Verify (validation, witnesses)
• Feedback (diagnostics)

http//www.cs.usm.maine.edu/graph/popup.html
http//fusion.lcs.mit.edu
7
Data-Flow Desktop Framework

• Data-Flow metaphor supports
• Data-typed input/output ports
• Concatenation of modules (chaining)
• Aggregation of modules (abstraction)
• Per-student state (persistence)
• Network transparency
• Test suites, event logging, etc.

8
Interaction mechanisms

• Avatars for each student, staff person
• Visual status, location of person
• Mechanism for message exchange, etc.
• Desktop sharing (e.g., with a TA)
• Allows selective/wholesale state sharing
• Mechanisms for distributed data-flow
• Logging, checkpointing of student work
• Forms-based feedback, grading

9
Staff Perspective

• Instructors select and organizecurricular
  material (as usual)
• Monitor and guide student progressthrough
  assignments
• Provide feedback on performancewith inferred
  diagnostic information
• Administer course through per-sistent web
  database

10
Technical underpinnings

• Client-server architecture
• Server-side compilation
• No development environment necessary on client
• All code in Java for cross-platform,
  cross-browser use server retargeting
• Integrated editor, chat, whiteboard (now),
  debugger, video (planned)

11
Connections to Other Efforts

• FusionScheme (Amarasinghe, MIT)
• Assisted Exploration (Boothe, USM)
• Automated Visualization (Axen, WSU)
• HST Simulation (Gray, Freeman, MIT)
• WebLab (del Alamo et al., MIT)
• Discussions with Vablais, Gupta et al.

12
Farther-out Ideas

• Automatic visualization (w/ Axen)
• Datatypes, operators, broken constraints
• Bi-directional debugging (w/Boothe)
• Interface through direct visualization
• Success/failure taxonomy (w/Amarasinghe)
• Characterize behavior on vector of inputs
• Taxonomize connect student to archive,or to
  relevant staff/other students

13
Connections to I-Campus

• Soundness/breadth of approach
• Applicability to training, other domains
• Plans for credible assessment
• Diagnostic substrate
• Graphics, HCI, Machine learning
• Architectural issues
• Network services, protocols, authoring
• Sustainability model
• Open-source, licensing, etc.

14
Conclusions

• Framework for algorithmic pedagogy
• Semi-automated diagnostics, feedback
• Various collaborations in progress
• Visualization, infrastructure, interface
• Architectural issues coming to fore
• N/w services related content authoring
• Connections to I-Campus
• Framework extensions development assessment

15
Further Information

• Educational Fusion
• http//fusion.lcs.mit.edu
• Computer Graphics Group
• http//graphics.lcs.mit.edu
• Relevant publications
• http//graphics.lcs.mit.edu/seth/pubs/pubs.html

16
Future Directions

• Improved learning curve, interface
• Synergy with other educational efforts
• Increased collaboration capabilities
• Authorization security improvements
• Debugging and reverse debugging
• Expanding breadth of current modules

17
slide 5 (student perspective) call up
bresenham module show reference mode
show manual mode show implement mode
type in two lines of code to draw
endpoints evaluate it
run code show difference modes
show difference with above two lines
then switch versions to (previously
typed) correct version, show
that difference is null.
18
slide 6 (dataflow framework) show
scan-conversion concept graph show data
coursing through system to generate polygon fill
image show a connection being re-routed to
cause interesting variation -- say, to
render in wireframe rather than fill?
19
slide 7 (interaction) show avatars
how ? show sharing how? show
feedback from staff call up poly-fill
module call up grading form fill
in grading form, with fill module running nearby
submit grading form