Tracking Functionality Changes in IRI: A Distance Education Software System C. Michael Overstreet, Kurt Maly, Ayman Abdel-Hamid, Ye Wang Old Dominion University Norfolk, VA USA

Outline  Background of IRI system  Supported functionalities What was changed What was changed  Some lessons learned

IRI Classroom-1995 Key concept: Virtual Distributed Classroom Students in different classrooms connected by networked workstations, each with video, audio, tool sharing.

IRI Chronology  Project start  Used for “regular” semester class – 1995 Multiple specially equipped classrooms Multiple specially equipped classrooms UNIX workstations, special video cards UNIX workstations, special video cards Design concern: speedDesign concern: speed “Autostart” “Autostart”  Redesigned and reimplemented – 1998 Goal: increase reliability & modify functionality Goal: increase reliability & modify functionality  Current version completely in Java – 2003 Goal: multiplatform & modify functionality Goal: multiplatform & modify functionality

Initial Design Concerns  Ease of use For both presenters and students For both presenters and students  Classroom management When and who gets to talk, uses tools, shows image When and who gets to talk, uses tools, shows image  How to make classroom more interactive Heavy prep workload for presenters? Heavy prep workload for presenters?  Performance System must be responsive System must be responsive

IRI-Easy  IRI-h (heterogeneous) is a multi-platform, multi- network environment scalable system (available from  IRI-h prototype successfully used to teach a semester-long computer science course across 2 sites 20 miles apart  IRI-h prototype deployed in actual home user scenario using a cable modem connection  IRI-Easy, most recent version of IRI

 Fully implemented in JAVA (multi-platform)  Simple on the fly setup of collaborative sessions  Audio, and video (Java Media Framework JMF)  Tool sharing (Interactive Program Video IPV)  Annotation and pointer  Application-level gateway  “Group of groups” communication paradigm  Individual multicast-disabled participants  Recording and playback  Note taking and notes-server  Call student, site video IRI-Easy features

IRI-Easy, discussion mode

IRI-Easy, presentation mode

Reasons for IRI changes  Faster, cheaper hardware (processors and networks) Prestaging of materials no longer needed Prestaging of materials no longer needed Video compression/decompression faster Video compression/decompression faster  Users more computer knowledgeable Systems needs to do less for them Systems needs to do less for them  More interesting: what changed due to student and instructor use of IRI

Functionality Analysis - 1 Desirable CharacteristicsIRI-Easy Support Present prepared material Shared tools for slides, simulations, graphics, pointers, annotations Because of the tool sharing engine used, IRI-Easy may not perform well with rapidly changing presentation images Presenter audio and video: Presenter video; audio only if speaker not is same room Audience audio and video Multiple audience videos and audios, but no audio from other people in same room

Functionality Analysis - 2 Desirable CharacteristicsIRI-Easy Support Attendance records:Not available Audience list & location: Participant list and locations Autostart for large group: If machine and participant list is provided, IRI-Easy can be started for all uses by a single user

Functionality Analysis - 3 Desirable CharacteristicsIRI-Easy Support Recorded sessions:Available for replay during a regular class or privately outside of class Notebooks: Private on-line notes available after class Feedback to presenters: 1. Video of remote classrooms 2. Instantly tabulated surveys & quizzes 3. Participant initiated direct feedback tool

Major Functionality Changes - 1 Functionality DescriptionReason for Change Participant clicks hand icon for attention; instructor could respond by turning on that student's audio and video Inhibited classroom discussion; better controlled verbally by instructor Instructor controlled all student audio & video Delayed interactive exchange; better controlled verbally than electronically; made quick relevant student comments difficult

Functionality Changes - 2 Functionality DescriptionReason for Change Machine Lists, Room Configurations Earlier versions used in established classrooms; these facilitated automatic start-up. Now participating machine not dedicated. Participation ListsInhibited spontaneous use by different groups

Functionality Changes - 3 Functionality DescriptionReason for Change Instructor had to explicitly give control of a shared tool to a student Slows down change of control; quicker and more natural to tell a particular student to take control with audio channel.

Lessons Learned  Excessive presenter control: Inhibits spontaneous interactions Inhibits spontaneous interactions Too much work for presenters Too much work for presenters “Nontechnical” controls often effective and more natural, e.g. “Nontechnical” controls often effective and more natural, e.g. ask students to start their videos rather than starting it for themask students to start their videos rather than starting it for them  Feedback important: Technical (e.g., is everything working?) Technical (e.g., is everything working?) Instructional (e.g., is everyone following?) Instructional (e.g., is everyone following?) Substitutes for reading facial expressions, body languageSubstitutes for reading facial expressions, body language  Students create their own solutions, e.g. Students “queue up” to ask questions or comment Students “queue up” to ask questions or comment Students use personal cameras as document camera Students use personal cameras as document camera