|
Different pieces of software facilitate different learning experiences. The inclusion of software into a school's curriculum should be based on its capacity, when used appropriately, to contribute to the promotion of learning experiences that are in concordance with that school's educational aims. Whilst a wide variety of software products are available, schools can benefit by the in house development of titles. Such programs are sensitive to the philosophical stance, curriculum requirements, teachers' and students' skills, and hardware facilities of the school involved. This paper addresses and considers the practicalities of' the development of software on campus and suggests ways in which projects can be devised and realised. The experiences of the authors in devising titles currently used and those in the pipeline at John Paul College, will be discussed.
Computers are no longer isolated machines to be used in a fixed place at a fixed time, for a fixed purpose. Educators are realising their potential as powerful tools in, and across all disciplines, capable of providing learning experiences that could not be provided in any other medium. With the information age gaining momentum, learners must be entrusted with. and able to take control of the technology to access, manipulate, and communicate information. The computer is not the teacher's tool, through which information is to be poured, but is the learner's tool, through which knowledge can be sought.
When computers were introduced into schools, school personnel naturally viewed the devices as just one more machine to deliver instruction... Instead of maintaining a primary goal of information transfer, the use of computers as tools moves toward a goal of students acquiring analytical skills. (Berge, 1993, p168)
If computing is to be integral part of education, software must be viewed as curriculum. Combined with teaching expertise, software is far more the determinant of quality educational experience than is hardware, (which has been the focus of many debates in the past). Content and structure both explicit and hidden is the experience, and therefore it is the curriculum. As different pieces of software facilitate different learning experiences, we believe the inclusion of software into a school's curriculum should be based on its capacity, when used appropriately, to contribute to the promotion of learning experiences that are in accordance with that school's educational philosophy and aims.
Sandra Wills, the Director of Interactive Multimedia Learning Unit at the Centre for the Study of Higher Education (University of Melbourne), categorises software as follows:
|
The classification of a piece of software into one or more of these categories helps us envisage the type of learning experience it generally promotes. (We say generally because we have seen creative teachers take even the least thought provoking titles and incorporate them into a purposeful experience.) Software designers must be aware that whilst the various types of software have their place, it is fair to say that there is a growing demand for software which is intuitive, interactive, learner centred, non-linear, and open ended.
Information communicated as facts loses all its contexts and relationships, while information communicated as art or as experience maintains and nourishes its connections." (Bender, in Laurel, 1991, p119)One of the most significant benefits of producing software 'in house' must be the designer's ability to react to, and provide for, the current educational philosophies of the school. Software which encourages exploration and reflection may be more difficult to produce than drill and practice titles, however ideals must not be compromised by limited expertise. Programming in house should not take place 'because it was there', but because it can advantage the learners.
When debating the viability of school based software production, there are many considerations. After identifying a need, it is worth investigating all possible commercial products. Whilst they may appear expensive at first, weigh this against the value of staff time or the cost of a contractor (see table 1). Remember that large corporate producers have massive resources at their disposal. If a program already exists and does the required job, why reproduce it?
| ||||||||||||||||||||||||||||||||
On the other hand, school based software which responds specifically to a need identified by the 'users to be', will no doubt be well employed. Similarly, software written for such a specific purpose can be more concise and user friendly than generic alternatives. Users want to see software as the answer to a problem, not a problem in itself.
Having recognised the need to develop a piece of software, it is vital to plan carefully to ensure available resources are used effectively. The composition of the production team will depend greatly on the size, scope, and nature of the project. Although a single person may adopt more than one role, it is helpful to clarify responsibilities from the outset. The crucial role must be that of the project leader, who maintains an overview, facilitates communication, and sets target dates. Action necessary in the establishment of a workable infrastructure includes:
Creation of production teamThe process that sees each piece of software from conception to reality should follow planned steps. The temptation to rush straight into programming should be avoided. This will allow time for users' demands to be reconciled with actual possibilities, and for specifications to be agreed upon. The following sequence describes a workable process:
- project leader
- content expert
- graphic artist
- programmer;
Consideration of software/hardware compatibility
- platform
- operating system - graphics
- video
- sound;
Selection of appropriate programming languages/authoring packages.
Having looked at the ideal, it is probably worth coming 'down to earth'. In many educational situations, human resources are scarce or software development is not supported as a priority. In 1990, Phillips looked a software development and compared the individual author model with the team approach.
- Clarify need;
- Detail specifications;
- Design prototype;
- Develop software;
- Beta test and modify;
- Finalise support materials;
- Implement;
- Maintain.
In the individual author approach, one person - typically a motivated educator - acts as curriculum specialist, teacher, programmer, documenter, and marketer - the proverbial one man band. The team approach enables a division of labour into experts intensely trained in each of the appropriate specialties. Team development provides a rich development environment within which the various team members provide unique contributions.
The one man band has enthusiasm on its side, (and communication should not pose a problem). If after an assertive search for contributors, you are the team, it is still vital to recognise the roles to be adopted and steps to be taken. A considerable amount of modification time can be saved by meeting with users during the planning and development stages to ensure the project is on task.
Evaluation should not be left until the implementation stage. Once beta testing has begun, don't consider making major changes to specifications, but do view it as more than time to find programming faults alone. What seems obvious to the creators, might not be so straight forward to the users. Beta testing provides the opportunity to gain and react to feedback from 'non-involved', 'non-computer' people.
One question we believe should be continually raised during the entire process is 'Does the program exploit, to the users' advantage, the power of the computing medium?' If the answer is 'yes' you are probably on the right track.
Consequently, all classrooms from PreSchool to Year 9, are already equipped with two desktop computers, printing facilities and linked to the college information network. In 1994, each student in years 5 to 8 has, in addition, been supplied with a personal laptop computer, which, too, can be linked to the college computer network. Modem facilities have also been installed so that students can access external information sources (including IAN, NEXUS and the Internet) from the classroom through the desktop computers or their personal laptop computer. Similarly, all students may use the modem facility to dial in from home and access the CD ROM information network.
Students in years 10 to 12 may use the Library Resource Centre computers, and stand alone computers in a selection of classrooms to access the same information.
This personal laptop computer program will be extended to years 4 and 9 in 1995; and by 1998, all students above year 3 will have their own personal laptop computers, as an aid to their learning, thinking, research, and as a means to access the world of information.
Before commencing any software production, a key determining factor for such development will derive from who, on or off the campus, can actually produce the package. In most schools, a team approach will be not be favourable due to limited human resources. Team work can occur on a much smaller scale even if the team only consists of one or two members. Whatever the size, the team should always have a project leader in order to maintain consistency and control. In most cases, the project leader will also be the programmer, though this could be achieved by someone else whether on campus or not.
During the development of Japanese Writer, a software packaged written for the Foreign Languages Faculty at John Paul College, the production team consisted of myself (project leader and programmer) and the Japanese teachers (content experts). While the program makes use of Japanese scripts, there was no requirement for a graphic artist.
If the project is to incorporate video, a small video production team headed by the video producer may be required. Again, this could be achieved simply be using the project leader and students from within the school.
Availability of an appropriate programming language/authoring package
Not all software that is written in schools will needed to be completed using a programming language. While programming languages can give more control and ownership over a piece of software, they are only one means of completing the project. Based on the size and complexity of the project, considerations can be given towards using programming languages (Visual Basic, Assembly, C++), authoring packages (Authorware) and general software packages (Excel, Access) which have almost become languages in their own rights. What is used will also be determined by the expenses involved in providing the required packaged and whether it is available for the particular hardware platform in use at the school.
As we have had considerable experience in programming languages in the past, we have decided to write software, generally, using the Professional Edition of Visual Basic 3.0 for Windows. We may consider moving to Visual C++ in the future. The use of Visual Basic meant that a professional user interface could be designed with few problems along with the fact that this particular edition of Visual Basic allows for the incorporation of sound, pictures, animation and video.
Software/target hardware compatibility
The hardware platform at John Paul College is that of the DOS/Windows machine, it was necessary for us to make use of a programming language which enabled us to grasp the potential of our computers and design high quality software (in both appearance and speed).
As we had made the decision to use a programming language, it was necessary to use other software packages in conjunction with Visual Basic to complete Japanese Writer. All the Japanese characters were scanned into the computer using a hand held scanner. The scanned images were then touched up using Corel PhotoPaint. This ensured that the images were crystal clear. Corel Trace was used to create an EPS file of each character and then Corel Draw enabled each EPS file to be easily inserted into the three True Type Font files required for the scripts.
Corel PhotoPaint was also used to assist in some of the titling which appears in the program and Animator Pro gave us the ability to incorporate a short flick sequence as the program is loaded.
The educational need
The educational needs and ideas for the software production, in most cases, will come from colleagues in the school or educational arena.
The Foreign Languages Faculty were keen to have their area of expertise capitalise on the use of high technology within the school. The Japanese staff members wanted to include a program on each laptop which would assist in their instruction of the language. It soon became evident that there was an area of the market where little software has been produced. The educational need to produce such a piece of software became evident.
Software specifications
From the initial discussion with the teachers specifications of the Japanese Writer were devised: the teachers wanted a software package that would help in the teaching of the two major Japanese scripts (Hiragana and Katakana) as well as providing an introductory level of the Kanji script. They also hoped that the program might allow the students to maintain a personal word bank and be able to write stories using the three scripts.
Designing a prototype
Before actually producing the software package required it is important to design a prototype. This may be as simple as scribbling notes on paper, to drawing diagrams of the product, to producing a non-working shell for the piece of software. It is important to remember not to rush too far into the project without consultation with those in the school who originally wanted the piece of software. Time and energy can be saved by constantly communicating with these people to ensure that the program is meeting with their criteria.
Development of the software/beta test and modify/implement
Once all criteria has been established and all parties involved are satisfied with the prototype, it is then possible to write the program. Depending on complexity, human resources and time, this can be time consuming and the results may not be achieved overnight.
Even once a working edition of the program has been completed, it may be necessary to continually test the program by having others run through it and make any modifications that result from the testing.
To implement the final edition of Japanese Writer, it was necessary to install it on every student's laptop and the network desktop. As the Japanese teachers had assisted in its production, minimal instructional time was needed.
Printed materials
It may be necessary to provide printed resources to complement school produced software. We have found, through experience, that it is often better to have someone completely independent of the project leader and programmer to write user manuals. It is also more appropriate to have printed resources and support materials written by the content expert.
A small program entitled "Event Cards" was written. In essence, the program is basically a database. As this was one of the first programs we developed, it is quite interesting to look back at it, now having a wider experience in programming with Visual Basic. At the time of developing the software, we had had little experience in programming with databases. As a result, we developed our own database functions. If we were to spend time in upgrading the program now, its capabilities could be truly extended using the Microsoft Access coding available through Visual Basic.
Developing software doesn't always have to evolve from an educational need. One of the major projects we have developed is our school prospectus. It was realised there was great potential in being able to construct an interactive, multimedia presentation to be used in the marketing of our school. The prospectus involved many hundreds of hours in its preparation: it required a user friendly interface, Kodak photographic images, animation, video, and sound, along with text based information.
Berge, Z. L. (1993). Beyond computers as tools: Re-engineering education. Computers in the Schools, 9(2/3), 167-178.
Laurel, B. ( 1991). Computers as Theatre. Addison-Wesley, p119.
Phillips, W. A. (1990). Individual author prototyping: Desktop development of courseware. Computers in Education, 14(1), 9-15.
Wills, S. (1994). Beyond browsing: Practical applications for educational multimedia. Paper presentation at Information Technology & Education Conference, Sydney.
| Please cite as: Kerwin, C. and Smith, A. (1994). Software development in the learning environment. In J. Steele and J. G. Hedberg (eds), Learning Environment Technology: Selected papers from LETA 94, 141-145. Canberra: AJET Publications. http://www.aset.org.au/confs/edtech94/ak/kerwin.html |