Use of the Internet in the Florida Learning Support Systems
##AUTHORSPLIT##<--->
Most of the attention that schools have devoted to the Internet so far has focused on accessing information by surfing Web sites. It has been left pretty much up to individual teachers to decide how best to integrate the use of the Internet into the classroom, and the match between Web resources and the curriculum and the quality of those resources has been spotty.
Now, however, a number of publishers are beginning to experiment with using the Internet as a new distribution channel. As a result, the quality of curriculum materials is likely to increase dramatically this year and we certainly can expect increasing numbers of students and teachers using Internet resources regularly.
Yet in the flush of suddenly having access to nearly limitless information resources, an equally important advantage of the Internet has been overlooked. Most school-based Internet activities so far have involved people (i.e., students and teachers) communicating with other people or with machines. These are human initiated and require the time and attention of people. But the Internet can also support communications between applications running on different computers without human intervention, and ultimately, this type of "background communication" enables development of new kinds of instructional and information systems for schools.
Let's consider a common problem today. A teacher wishes to use a gradebook program that runs on a desktop computer. This software needs all of the students' names and ID numbers to be entered into the program. How d'es the teacher do that? Typically the individual teacher will type it in themselves, because it is just too complicated to download the information from the Student Information System (SIS).
Now that more and more classroom computers are being connected to the Internet, isn't it a shame that this transfer of data can't just happen automatically across the network? It would save a lot of time if the computers (and the applications) could just talk to each other. The "Data Flow Controller" (DFC) being developed as part of the Florida Learning Support Systems™ will help that happen.
Part of Florida Schoolyear 2000
The Florida Schoolyear 2000 Initiative is involved in the design and development of networked systems for schools in the next century. A joint initiative between the Florida Department of Education, Florida State University and participating school districts, its goal is to design a new system of schooling for Florida that effectively uses technologies, particularly information technologies.
The Initiative began in 1989 when the Learning Systems Institute at Florida State University was asked to help conceptualize this new learning system. One of our concerns is that the widespread introduction of personal computers into schools during the 1980s and early ‘90s has so far had a disappointing and limited impact on educational outcomes. One of the reasons for this, we feel, is that computers and information systems have typically been applied as an extra layer on top of existing practices and policies. Schools embrace a group or classroom model of instruction, but computers work best when used to promote individualized learning.
In designing the Florida Learning Support Systems (FLSS), design teams made up of Florida teachers, administrators, business experts and parents were asked to forget about existing traditions and constraints and imagine how modern information technologies should be used to enhance learning and improve school practices. Every effort is being made to take a systemic view in developing the blue- print for these systems.
In 1992 when this design process began, it was already clear the Internet was going to grow rapidly. We realized that the inevitable growth of networks in schools, particularly of networks supporting TCP/IP, would enable the development of distributed client/server systems. We saw that computers would be able to communicate with each other and work together, regardless of distance.
Distributed Client/Server Design
The concept of distributed client/server systems built on an Internet foundation is critical for a number of reasons:
- Developing a system as comprehensive as the Florida Learning Support Systems demands a modular design. It is necessary to design the system so components can be built over time, each "plugged in" as they are completed. The client/server approach as enabled by the Internet permits this type of development.
- The rapid advancement of computers we have witnessed over the last 15 years is likely to continue. Who can predict what type of computers we will have in five years? By basing the FLSS on a distributed client/server design, it will be much easier to integrate new hardware as it is developed. For example, suppose a new student notebook computer is developed that is inexpensive but uses a whole new operating system (not Windows or Mac OS). All that will be needed to quickly integrate it into the FLSS is to develop appropriate client software for the new device. It can then interact with all of the applications and resources on the network.
- The Florida Learning Support Systems are designed to be "scalable." This means as new applications and use of the system grows over time, hardware can be added to increase the total power of the system with no fixed upper limit.
- Existing applications, such as library circulation systems, student information systems or payroll systems, can become an integral part of the overall system.
We believe it is inevitable that the divisions that now exist in so many school districts between academic and administrative computing services will dissolve over time.
Who's Developing the FLSS?
Development of a comprehensive system of this size is clearly beyond the resources of any single school district. At the same time, it is rare for any one educational corporation or development company to have the broad base and systems view that is needed.
Fortunately there is legislation in Florida that permits the investment of state funds in the joint "codevelopment" of needed educational materials and products with commercial partners. Once developed, Florida receives a royalty on sales of resulting products outside the state.
The Florida Learning Support Systems are being developed under a codevelopment agreement with: Encyclopaedia Britannica Educational Corp. and its associate partners Chancery Software Ltd., Information System of Florida, Inc. (ISF), Learner First, Inc. and Bolt, Beranek and Newman (BBN), Inc. The first elements of the system are scheduled to be deployed during 1996.
Glossary TCP/IP is an acronym for "Transmission Control Protocol/Internet Protocol" and it is the set of communication standards through which different kinds of computers on the Internet communicate with each other. One might say it is the "language" of the Internet that computers speak. A client/server system is a set of computer applications (programs) in which two or more computers work together. Generally there are one or more computers with large amounts of information called servers. Clients are other computers that execute applications that communicate directly with the server(s). Part of the processing is done on the client computer, while the server concentrates mostly on storing and delivering the information to be processed. Any human user of the client computer may or may not be aware of the interaction between the client and server, which occurs often invisibly in the background. | General Anatomy of the FLSS As mentioned earlier, the FLSS will consist of many different platforms and applications all tied together through the Internet. Individual servers may serve single schools or entire districts and, in some cases, several districts simultaneously. Figure 1 illustrates the relationships between the major components of the system. The boxes on the left represent applications that will run on end-user devices. I have carefully avoided using the word "computer" here, as we believe there will be different kinds of intelligent devices in schools and homes in the future. In addition to desktop or notebook computers similar to those of today, we expect smaller, less costly, more portable, limited-purpose devices. Indeed, within months "Internet appliances" will be on the market selling for less than $500. We can expect future television sets to have built-in network capabilities -- perhaps in as little as 18 months. All of these devices will be able to connect users to the Florida Learning Support Systems from home or school. While I can't offer a full description of the entire FLSS (not enough space), I can explain how it will generally work. There will be client software that logs in users in a manner appropriate for their age level. Server software will then identify the user and invoke other components of the FLSS to deliver the desktop environment, appropriate tools and information unique to that user. There will be a set of common "tool" applications -- word processor; e-mail client; graphic, audio and video viewing and editing programs; etc. -- available on end-user devices. Most of these tools will be commercial off-the-shelf applications. It will not be necessary for every workstation to have the same suite of tools. Ideally, a library of tools will reside on servers, possibly using the new Hot Java language or something similar. If a tool is required that is not on a specific platform, it can be accessible immediately over the network. By the way, if you haven't heard about Java yet, you soon will. Java is a language very much like C++ that can be delivered over the Internet. The idea is that Web browsers of the future will have Java (or similar) interpreters built in. A Java application can then be loaded over the Internet and interpreted on your computer. This means it d'esn't matter if you have a Macintosh, a Windows computer, or even a UNIX machine. Your Web client interprets the Java code so that your computer can understand it. The same Java source code will execute on any computer that has an appropriate browser. This promises to revolutionize many of our existing concepts about computers, software and networks. Databases That "Talk" to Each Other It is expected that the FLSS will use a large number of databases of different types. Some of these databases already exist, such as the Student Information System (SIS) found in nearly every school. Other databases will be created by some of the new applications that are being developed as part of the FLSS -- such as the Curriculum, Instruction and Assessment (CIA) Manager. The CIA Manager, which will manage each student's progress through curricula, will use databases of desired outcomes, learning activities, resources and assessments. These multiple databases will be stored on many different servers. Some records may be kept on servers in an individual school or classroom; others will be kept at the district or state level. Very early on, we worried about how existing databases could be integrated with the new applications and databases we were designing. It was clear that we could not ask directors of administrative computing in school districts to throw out legacy systems and start from scratch. What we needed was a way of automatically sharing data between different applications and which would also permit new applications to be quickly and easily added to the network as they are developed. We were disappointed to discover there d'es not exist any widely accepted standard permitting data to be exchanged among different educational applications. It is clear that schools would benefit enormously from the flexibility that would result from the development of such a standard. Let's go back to the problem posed earlier. A teacher has a desktop computer with a gradebook package and wants to use data from the school's Student Information System. At the same time, a media specialist just has purchased a new library management system for the school's library and it needs information about students enrolled, home addresses, etc. Much of the information needed by these two applications is the same, but is stored locally in different formats. The two applications, written by different companies, both would like to receive data from the SIS, which is probably written by a third company. The Data Flow Controller is the new key to make that happen; but how? |
Vendors representing approximately 80% of the educational software market agreed to support the development of DFC standards. | How the Data Flow Controller Works The DFC will basically handle electronic mail messages from one application to another. These messages will take place automatically. To see how it will work, let's take the example above. If the teacher has purchased a gradebook program that is Data Flow Controller Compliant, it will recognize when installed that it needs initialization data. If connected to the Internet, it will send a message to the DFC asking for a list of student names and ID numbers for that teacher's classes. The DFC will have access to a table of information that identifies what application "owns" the requested data -- in this case the district's Student Information System. The DFC will then generate a data set request for the SIS and store the request until such time as the SIS asks the DFC for any pending messages. At some point in the near future -- a few minutes or perhaps several hours, whenever the Student Information System has some idle time -- the SIS will send another electronic message to the DFC asking, "Do you have any requests for me?" At that point the DFC will send the pending request to the SIS. The SIS will then process the request, packaging the requested data in a format that can be understood by the DFC. The data will then be sent to the DFC as a series of electronic messages. The data will be stored by the DFC locally until the gradebook application on the teacher's desktop is ready to receive it. It may be, for example, that during the time the request was being filled, the teacher turned off the desktop computer and left for the day. In that case the requested data will be stored by the DFC overnight. The next morning, when the teacher arrives at school and turns on the desktop, it will "check in" with the DFC (through an electronic message) essentially asking, "Do you have anything for me?" At that point the DFC will send the requested data -- still in DFC format -- to the requesting application. The gradebook package will then convert the data from DFC format to whatever format it wishes to use internally. The concept of the "DFC Format" is essential for all of this to work. For example, the gradebook package may want the following variables for each student: LAST NAME, FIRST NAME, MIDDLE INITIAL, ID NUMBER, ADDRESS. The SIS might store this information in a different format; perhaps the first and last names and middle initial are all combined into one data field, such as SMITH ROGER B. But it d'esn't matter, provided both the SIS and the gradebook package are able to translate from their internal formats to and from the agreed upon standard format used by the DFC. The gradebook package only needs to understand DFC format, as d'es the SIS. The advantages of this should be clear when we now consider the new circulation program the media specialist just purchased. That application needs much of the same data, but likely has entirely different data formats. But it d'esn't matter, because again, the only thing it needs to understand is DFC format. Once an application can communicate in "DFC standards," it can request and share data with any other applications that are DFC compliant on the district's network. Of course, there are security issues. You don't want grade information being sent to just any requesting application anywhere! Very good security measures will be built in to ensure that sensitive data is shared only with those applications that have authority to access it. Making It a Reality Making the DFC work is more of a strategic rather than a technical challenge. The technical design of the Data Flow Controller is well in hand. But for it to work, a large majority of developers of educational software must agree to support the DFC standards. There must be agreement on what data elements should be shareable, how those data elements can be tightly defined, and how they should be formatted. Each vendor must then develop an Application Protocol Interface (API) as part of their application that will communicate with the DFC according to these agreed upon standards. Such applications can then be labeled as "DFC Compliant" and schools will be able to purchase them knowing they will quickly and easily integrate into the existing information structure. So how likely is it that this will become a reality? Right now it looks promising. A group of leading educational software publishers were invited to a meeting last fall hosted by Encyclopaedia Britannia Educational Corp. Invited vendors represented approximately 80% of the educational software market. After the basic concepts of the DFC were explained, they were asked if they were willing to support the development of DFC standards. Without exception they agreed. But the hard work is ahead. The concept is very attractive, and it is fairly easy to see how it can work with clearly defined data like student names, addresses and phone numbers. It is more difficult to imagine how curriculum and assessment data can be shared among applications. For example, if a student scores 85% on some computer-based quiz in a CAI lesson on "adding 3 four-digit numbers," how can that kind of data be defined well enough so that it will have meaning to other applications? Should we even try? We have some ideas on how this might be done, but it won't be easy. |
Once an application can communicate in "DFC standards," it can request and share data with any other applications that are DFC compliant on the district's network. | The Data Flow Controller is being developed by Information System of Florida, Inc. (ISF) and will be in beta testing during the summer of 1996. One of the advantages to our design is that everything d'es not have to be done at once. The entire FLSS is organic and has been designed to be evolutionary. Components of the FLSS -- including the DFC -- will evolve and improve without fundamentally changing the underlying system design. What should be clear, however, is that this system would not be possible without the Internet. n For more information about the Data Flow Controller or Florida Learning Support Systems, visit the Schoolyear 2000 Web site at: http://www.cet.fsu.edu Owen Gaede is associate director of the Center for Educational Technology at Florida State University and a computer science professor. He has been involved with computer-based education for over 20 years. A former high school chemistry and physics teacher, his doctorate is in secondary education. E-mail: [email protected] Companies and products mentioned:
Bolt, Beranek and Newman (BBN), Inc., Cambridge, MA, (617) 873-4277, www.bbn.com
Chancery Software Ltd., Vancouver, BC, (800) 999-9931, www.chancery.com
Encyclopaedia Britannica Educational Corp., Chicago, IL, (312) 347-7900, www.ebec.com
Java; JavaSoft, Palo Alto, CA, www.sun.com/java
Information System of Florida, Inc. (ISF), Jacksonville, FL, (904) 724-2277, [email protected]
Learner First, Inc., Birmingham, AL, (205) 934-9182
|
This article originally appeared in the 04/01/1996 issue of THE Journal.