CALMet99 Presentation

The Development of VISITview


by Tom Whittaker and Scott Bachmeier
Cooperative Institute for Meteorological Satellite Studies
University of Wisconsin-Madison
Madison, Wisconsin, U.S.A.

Abstract


The evolution of a distance-learning, collaboration tool named VISITview, which is being developed for use by the VISIT (Virtual Institute for Satellite Integration Training), will be discussed. Both technical and functional aspects will be described, along with observations about the efficacy of this development approach. Trade-offs between buying commercial software and developing on one's own will also be discussed. Portions of one remote, Web-based lesson will be used to illustrate these points.
 
 

Introduction

The Virtual Institute for Satellite Integration Training (VISIT) is a collaboration between NOAA Cooperative Institutes (CIMSS, CIRA and COMET) to produce training materials and provide lessons for U.S. National Weather service personnel.  This effort is part of a much larger national program, but focuses on the use of integrated multi-sensor data in the analysis and forecast process. During the past year, we have been developing a software tool to enable this training to be done remotely ("teletraining" is the term used to describe this).  This has become known as VISITview.

VISITview is a Java based, distance-learning tool that uses a client-server broadcast model.  Instructors produced lessons using GIF or JPEG images and provide specific information about these via HTML.  Lessons are taught in an interactive manner using the telephone for audio and VISITview for keeping everyone looking at, and interacting with, the same scenes.

The motivation

In early 1998, I was approached by Scott Bachmeier, an instructor for VISIT, about the availability of tools that might have better applicability to his particular training needs that the system currently in place.  The latter is a commercial product that requires a combination of software, a PC running Windows, a specialized modem to multiplex voice and data, and a speakerphone.  The main aspects of this system he was finding awkward was the inability to have a continuous loop of images and to annotate over more than on image at once. While he also did not like the duplex voice/data, his main emphasis was on the functionality.

I investigated commonly available Web-based collaboration and distance learning tools.  Since the Weather Service was also in the process of deploying the AWIPS system at the time, we felt it essential that a platform neutral solution would be preferred. What I found was a variety of "whiteboarding" and "chat room" applications, in addition to some sophisticated, business oriented conferencing software.  None of these really addressed the problems he described.
 

The start

At the time, I was actively involved in the development of Web-based tools for showing animations of satellite images and decided that it would not be difficult to modify this software to accept its commands to state/stop/step the animations via the Web.  Using a public domain framework for a broadcast client/server model, I spent a single day producing a sample for him.  After a few refinements, we decided to involve others in this to discuss whether this approach would merit continued development.

The crucial test at this time showed this model could support tens of users simultaneously.  It is worthwhile to note that at this point, the client software was written in Java as an applet so it could run in a browser without requiring any new software to be installed on the students' machines.
 

More functions

The early animator soon had the ability to draw lines.  It was important that these annotations show up on every frame, so consideration was made to provide a pleasing display that did not distract from the instructor or students' learning.  In a flurry of enhancements, we added: At this time, we also began a series of live tests with Weather Service Offices, and got out first big setback:  the variability of connections meant that some offices were getting images and commands in a timely manner while others were not.
 

Bandwidth and throughput

Teletraining stresses the communications in two ways:  first, many image files need to be transferred from the server to the clients in realtime which means a high bandwidth is needed.  Second, command information (start/stop loop, step frame, etc.) require fast response time.  What we found very early in testing was that the connectivity of offices to the Internet was so variable that it was impractical to do both during a training session.

We also had enough experience by now to know that the functionality of this tool was just what was needed for the VISIT program training.  The obvious approach at this point was to have offices download the image files prior to the training and then use the applet to read from the load disk.  Java security, however, prohibits an applet from doing this, so we were forced to either go the route of purchasing a signing certificate or distributing an application which was run locally but controlled remotely.

Since the largest volume of data in a lesson is the image files, we decided to just put a wrapper around the applet that would allow it to run as an application (and thus be permitted to read the local harddrive and communicate over the Internet to another site).

This approach substantially improved the situation; however, as I'll mention later -- it is still not a perfect world.
 

More and more function

As the instructors gained more experience and received feedback from their lessons, a barrage of changes were made to what had now become known as VISITview.  These included: The last bullet is quite an interesting application.  The RAMSDIS On-Line web site provides access to realtime satellite products through CIRA.  With their help, we created a VISITview "lesson" that consists of the scenes from their database.  Thus, it is possible for two remotely located people to share a view of data and, using the telephone, discuss what they see.  The model for this is that anyone connecting is a "master" (instructor) and thus can control all aspects of the session.
 

Making VISITview available

During this time, I was encouraged by the Unidata User Committee members to make VISITview available to the university community.  CIMSS decided that this was an excellent idea, and in late 1998, a VISITview Home Page was created and documentation supplied to allow anyone to get the tools and use them.  Our vision was that labs with many computer workstations would benefit from this.

During the month after the announcement was made to the Unidata universities, more than 100 individuals took a look, and about 20% downloaded the software.
 

What's next?

As of this writing, the list of enhancements from the instructors includes:

Risk factors

It is important during the development of any software to be used by an organization to assess the risks involved.  The Weather Service Training Branch is constantly monitoring and evaluating for all their efforts.  I want to talk about two sides of this as they relate to VISITview: We believe we have minimized the risk factors and maximized utility by doing this development in a closely coupled, spiral type process.  By involving more than one software developer, we have also started to insure that this can be maintained and enhanced beyond the involvement of the original people.
 

Final comments about teletraining

There are several non-technical issues related to teletraining.  While I do not want to dwell on them, I would like to highlight a few of the closely related concerns.  First is efficacy.  Our goal is to increase a forecaster's ability to do his/her job.  "Ability" may mean efficiency, but it may also mean accuracy.  Either of these is difficult to assess -- especially over the short term.  Common measurements of the effectiveness of learning, namely knowledge or skill testing, does not usually measure the long-term impact. In addition, teletraining is just one of several different approaches to training being used, and mainly as a substitute for some of the in-residence training (because of cost).

The second is related to pedagogy.  The very nature of Distance Learning means that some of the techniques used during in-residence training need to be changed.  For example, more emphasis must be placed on vocal interactions since other cues are not available to either the instructors or students.  In addition, more overt effort is needed to keep the students engaged; in some cases, this means different techniques are essential.

There are other issues related to teletraining, which I see mainly as challenges.  Those of us involved on both the technical and pedagogical side look forward to meeting these.