OPEN SLATE PROJECT

Chalk Dust


 
Back to Open Slate Home Page Date: 2002.09.22 (2007.11.21)


Introduction

Chalk Dust is the name of content portion of the Open Slate Projet. A Chalk Dust application can be a stand-alone application, such as a language drill or a music creation exercise, or it can consist of data formated for delivery by a standard application -- typically a web browser -- or by way of the Open Slate's own presentation software, Super Chalk Board.

Background

Open Slate is about putting mobile personal computer capability into the hands of every member of an organization. The target organization is a high school, although there is no limit to the kinds of organizations that could benefit from such a system.

As this is being written, many pieces of what would be Open Slate exist, but several key technology bits are missing. More significant, the social and cultural changes that must take place for the concept to succeed in schools have barely begun. Hopefully, people will someday read this and wonder why there was ever any doubt.

A guiding principle of Open Slate is to utilize the tools and capabilities that made the Internet a successful on-line community. Tools such as mail, news, the World Wide Web, and chat make up the core applications, and to the greatest extent possible, proven, widely used open-source applications should be used. We do not want to re-invent the wheel.

These well-known applications will be augmented by a few more that are targeted specifically at learning. Two important members of this group are an advanced form of a network-enabled white board, called Super Chalk Board, and Azimuth, the progress monitoring database.

Challenges

Success in an educational setting demands more than the above mentioned core applications. In particular, what is needed is a large group of applications which provide focused learning. This is not a new concept. There have been countless attempts at developing curriculum for delivery via a personal computer, and some have been successful. The most familiar variety are apt to be self-study applications delivered via CD-ROM. These are available in topics such as math, science, reading, and foreign languages, just to name a few. The new face in town is distance learning, which relies more on web pages than CD-ROM.

There are a number of factors which conspire to deter widespread acceptance of educational software. Quality, suitability, and support are all critical factors in determining the success or failure of educational software titles, but nothing presents as daunting a challenge as cost. To acquire a variety of commercial titles for every computer in a lab is an expensive proposition -- to outfit every student in the school presents a monumental obstacle.

Closely related to cost is the piracy issue. When expensive software is distributed in a copyable format, cash-poor educators will find it hard to resist the temptation of making extra copies. When vendors respond with copy protection schemes, honest customers encounter problems getting the software to run. Add the threat of legal action and schools find it necessary to devote substantial resources to monitoring, yet cannot eliminate the risk of lawsuits. Clearly, in such a hostile environment the risks can outweigh the benefits.

Chalk Dust proposes to remedy the problem of cost, and to make an effort to deal with quality and support. The suitability issue will be solved indirectly, as a result of solving the cost problem.

To be fair, Chalk Dust faces its own set of challenges. For starters there is the challenge of explaining what it is. The concept is so foreign that people are apt to misjudge it, to pigeonhole it into an unsavory category derived from previous experience. Then there are those who react the opposite way, who burden the concept with the promise of saving our schools, who will accept whatever the results are because of the process by which the ends were achieved. Chalk Dust applications must stand by their own strength, and at the same time not have their worth increased or diminished by how they are made.

The Open-Source Model

Compared to today's educational software market, what makes Chalk Dust special is that the applications and content are developed using the open-source model. The most obvious result of this method, and the most controversial, is that the applications are available at no cost.

Chalk Dust provides a development process and an approval process. As a result, it offers a high level of quality assurance. Just how good a specific Chalk Dust application is depends on the development team and the feedback provided by its adopters. Given adequate amounts of thoughtful feedback, and a responsive team, excellence will prevail.

Chalk Dust development teams

A Chalk Dust application is built by a team. The ideal is to encourage various levels of expertise, so that for many team members the project becomes a learning experience.

The team should include at least one person from each of the following categories:

Before we go on, it needs to be said that there will be many more members of the development team. Honorary members, to be sure, but vital to success. Those are the students who use the application. The process by which they participate will be explained more fully below.

The suggested team structure is offered as a guide. In some situations, a different arrangement will be better. Every project will have to find its own best arrangement. What is important is the intent. A successful Chalk Dust application will require computer technical skills, knowledge of a particular subject, and knowledge of effective instructional strategies. Given the billions of people inhabiting the planet, there are bound to be a few people who are good at all these things, but success will be more likely if we embrace specialization.

TAs to tea masters

The Chalk Dust development process model is derived from three existing examples. While none of these parallels exactly the Chalk Dusk process, they demonstrate adequately that such an approach can work.

The first example comes from college. It has become common practice to hire graduate students to teach introductory undergraduate courses. These graduate assistants are not just turned loose to develop their own content, lesson plans and exam questions, they work as a team under the supervision of experienced professors. This approach allows graduate students to develop teaching skills, and oftentimes the responsibility for teaching a class forces a student to re-learn in greater detail the subject matter being taught. A less tangible but equally important effect is the way this process allows the graduate student the opportunity to give something back, to inspire and mentor younger students.

The second example comes from open-source software development. Large applications, such as the Apache web server, are the work of a large number of people. Even small, narrowly focused applications that appear to be the work of a single individual rely on the contributions of many people.

The third example is taken from a method of music instruction common to many cultures around the world. Such a system consists of a hierarchy, with a master teacher at the top, a group of expert teachers below, and at the bottom, apprentices who have demonstrated adequate mastery of the tradition to teach beginners. The same basic organization is widely used in Japan in subjects as diverse as flower arranging, martial arts, and the tea ceremony.

Traditional American -- perhaps "western" would fit -- teaching follows a similar pattern. A master practitioner writes a textbook. Aspiring students go to college to study with the author, then take what they have learned, and the textbook, back to their classroom where they teach what they have learned. Typically the process is not so direct; many college classes are taken, and the textbooks ultimately used may have no connection to the educator's college experience. Despite the disjointed methodology, the overall effect is the same.

Textbooks as quaint artifacts

One of the ways that Chalk Dust is different is that there is no concept of a textbook. This is not to say that Chalk Dust will be used in addition to textbooks; rather, Chalk Dust will, eventually, replace textbooks. More accurately, Chalk Dust will make textbooks seem as quaint as a charcoal heated bed warmer.

The bulk of the effort of developing Chalk Dust applications will be performed by students. In the recommended model, these students come from three distinct areas of specialization, subject matter, computer science, and instructional design. The work they perform will typically be on-going. It is hard to name a field of study immune from the need to have textbooks revised to incorporate new discoveries. (Anatomy, perhaps?) A Chalk Dust application is by design a dynamic vehicle, easily modified, updated, and corrected. Updates can be implemented without concern for rendering the existing inventory of textbooks obsolete.

The role of the faculty team members will vary depending on the makeup of the team. At a minimum, the faculty members perform a quality assurance function. However, there is nothing to prevent faculty members from taking a more active role, like defining objectives, outlining the presentation, or providing content. While not having any students on the team will be permitted, it should not be forgotten that developing Chalk Dust applications provides a rich, rewarding, concrete learning experience, so student involvement is encouraged.

Monitoring with Azimuth

Every Chalk Dust application must include the ability to transmit data to a management database, called Azimuth. The structure of this database has yet to be developed, but will contain data to identify the student, the instructor, and the student's progress. There will be a central account setup on the slate which defines where the reporting database is located, so that in day-to-day use the operation is transparent. The use of this feature must be optional -- the application must operate equally well with or without the reporting function turned on. Access to the data will be determined by school policy. Typically, teachers and councillors will have access to all details, and nobody else will have any access.

The primary objective of the monitoring process is to provide data to teachers that traditionally comes from reviewing classwork, homework, and test results. Done right, this will result in a significant decrease in teaching workloads, especially of the drudge work variety.

An additional, and very important, objective of the monitoring process is to provide feedback to the application development team about where improvements need to be made. This is one of the processes by which quality is managed. In a sense, every classroom can be treated as a test lab. The more data is available, the better the corrections will be.

Delivery

Distance learning has placed a great deal of emphasis on using web sites to deliver content. This may turn out to be an effective choice for Chalk Dust applications as well, but there is much to be said in favor of applications that run on the slate. Such applications will probably be developed using Perl, Python, or Tk, with the Tcl library of user interface widgets. Other possibilities are Smalltalk, especially the implementation called Squeek, and Java. Of course there is nothing to prevent someone from using C or C++, or any other language.

The benefits of using local applications rather than web-based content are responsiveness, network loads, and the ability to work without a LAN link.

The developers of PLATO, the first on-line educational system, determined that responsiveness was a key factor, and implemented what were, at that time, exceptionally stringent constraints on how long a delay would be tolerated between a key press and the corresponding response.

The ability to operate without a LAN link may seem to contradict the reporting requirement described previously. In fact, the reporting mechanism will be designed to operate in a manner similar to a good mail MTA. A Chalk Dust application running on the slate will send reporting data to a local agent, which will hold the data in a queue until such time as a LAN link is available. It may turn out that an established MTA such as Sendmail or Postfix running on the slate will perform the delivery task. Fudging the numbers is easily avoidable through the use of public key encryption, which in itself will be a foundational component of the Open Slate design.


 
Gary Dunn



To Open Slate Home Page