Figure 1: 1102net Home Page
Teaching introductory computer programming is a difficult task. Students often perceive programming subjects as requiring significantly more work than their other subjects, and feel that the result of their work is not near commercial quality. Students in our first year are provided with a World Wide Web based information source and assignments that produce World Wide Web documents in an effort to increase their interest and have them produce impressive-looking work. The Web also allows students access to a common pool of resources created by both students and tutors to help in the collaborative learning process.
3. Background
The Bachelor of Computing course at Monash University has about 400 first year students each year, all of whom must study two programming subjects, one in first semester (SFT1101) and a follow up subject (SFT1102) in second semester. These comprise both full time and part time, day and evening students. They vary widely in ethnic background, computing experience, age, maturity, motivation and interest.
Both these subjects were redesigned and restructured in 1996, in collaboration with staff from the Faculty of Education, in order to improve the quality of teaching and learning in first year programming. It was important to obtain feedback from students, as often as possible during the year, about the content and presentation of the material and how well they were coping, so that changes could be made to address problems immediately.
3. Student Perceptions of Programming
Computer programming is seen by the majority of students as more difficult and time consuming and less interesting than their other subjects. Programming is viewed by many students as the "lower paid" computing profession, rather than an exciting field in which one can specialise and find a niche far more readily than in other computing areas.
The perception of difficulty arises from the necessity to memorise what one has been taught (enough for many other subjects) and then apply that knowledge to solve problems. Students have to construct and test programs after extracting the specification details from the information given to them, ensuring that the programs created fulfil the reasonable expectations of a "client".
Learning to program is a time consuming task, as a very large number of hours must be spent at a computer writing and debugging code (even if the student is already familiar with programming languages which, for the majority of our students, is not the case). Concepts such as structuring code, reusability, ease of maintenance, meaningful naming and user interface design need to be considered for all but the most basic programs. Unfortunately, this gives students a sense of information overload as well as a seemingly unstructured set of concepts to link together. With experience the student comes to see how all the concepts learnt interrelate.
Students tend to see programming as unnecessary as more and more software products are available to remove the programming task from the user. Spreadsheets, databases and word processors can perform many of the information producing tasks that once required programs to be written. Programming has moved towards a role of product customisation and, consequently, the first year subjects focus on teaching concepts that can be used in this role without dependence on a particular product. The objective is to give students skills that they can translate from one programming language to another. Unfortunately, students tend to see products rather than concepts (until they gain experience with other languages), as the job advertisements in newspapers advertise for language experience rather than a general programming ability.
It is possible to work in the computing industry in many roles besides programming. However, many jobs require a knowledge of programming, the limitations of languages, the suitability of products for different tasks, and the design of maintainable code and, when the programmer is promoted, the ability to help and teach less experienced people the skills involved.
In order to increase both the quality of work being produced by students and retention rates in programming subjects, we tried to increase interest in programming, and focused on making the transition from secondary education to tertiary as smooth as possible. This meant trying to provide an interesting and useful set of information to allow students to explore options and work as independent learners.
3. Addressing Transition and Information Presentation Problems
First year students in most courses tend to require assistance in the area of information acquisition and the encouragement of independent learning. This is because of the relatively new topic domain being explored and the foundation that first year provides for later years. The unfamiliar environments with which students have to deal and tools and concepts that have an altered perspective from the real world further exacerbate the problem.
The response to this need has generally been large quantities of handouts and code distributed on disk. As attendance at lectures and tutorials is not compulsory, we found that some students skip tutorials and later ask for handouts, exercises and lecture notes. To this end, all handouts have been made available in electronic format. Use of the World Wide Web was an almost ideal method of distribution as it provided the chance for us to include many different types of media in a computer platform independent manner, usable from home through dial-up access as well as on campus.
Staff now have greater opportunities to share information with students. In previous years, announcements were disseminated to students via email to tutors, which was then either passed on verbally to students or forwarded to student email addresses. This meant that students not in attendance in tutorials would not receive word-of-mouth messages, and those with full mail folders would not receive email messages (many students do not delete old email no matter how many times we tell them to!). It was primarily for this purpose that these facilities were provided initially.
4. Enabling Collaborative Work Through WWW
The objective of the Web pages became increasingly ambitious as time went on: additions included areas for announcements, extra help, feedback and a set of pages where tutorial groups can place on the Web work they had done that week to enable other tutorial groups to look at it. This allows groups to "show off" their group work, encouraging a sense of competition between groups.
A newsgroup was also provided for discussion of issues related to the subject. There were different threads throughout the semester, mostly from the more able students, and aimed more at language specific details rather than programming and design issues. It seemed that the less able students were reluctant to post here, but were willing to place more comments and questions on the anonymous feedback page (see later).
5. Design Considerations
When working with the World Wide Web it is unwise to assume that students are going to be using the same software to access documents. Many of the students in our first year programming subject purchased new computers, which came with Windows 95 and Internet Explorer. Although this does not have the functionality of Netscape, most students prefer to use it than to install Netscape.
Novice users to hypermedia (including many of our students) experience difficulties from a lack of structural cues and the new navigation and search techniques available in hypermedia documents [2]. This led us to create a simple hierarchical design with minimal cross-linking into other topic areas in order to minimise disorientation. In first semester, students became confused about where to find information when they where taken from one "section" to another. This was because of the use of separate panes (frames) which all worked independently, each with a heading, information and a separate index. We found that a single frame layout worked better as it was more like a paper document.
It is also important to choose colour schemes and visual cues that allow the student to identify quickly topic areas, new additions and important announcements. Animated graphics were trialed in first semester in response to student requests, but were removed after a few weeks because of the extra time it took students to access the pages over their modems from home. We decided that icons and headings should be small in size and standardized. To this end, the front page is intended to take the longest to load, containing a variety of headings and icons. After this, most of the graphic files remain in the browser's cache. A list of new material with a visual cue (a new icon), the date this material was added and a short description of it helps students find new material quickly.
6. Major Sections in 1102Net
1101Net was the document design and automatic document generation software used for the first semester subject SFT1101, and 1102Net was an improved version used in the follow-on second semester subject SFT1102. 1101net proved to be as much of a test case as a truly useful tool for students, as there were only a few students who were confident enough to delve into the Web and find information. With the extra confidence of students in second semester and some redesign of the software, 1102net proved to be more successful. We will discuss mainly 1102net here. At the commencement of first semester 1997, the software used will be the third version.
1102net provides students
with a selection of subdivisions into which information is placed
and activity can occur (see Figure 1):
|
|
|
|
|
| |
|
|
|
Each page has standardized headings and a quick access menu at the bottom. Many of these were created as standard reusable files added by server side includes.
An essentially hierarchical structure is maintained as this allows students to make an easily navigable mental model of the system and allows them to identify where information fits in the course [1].
Figure 1: 1102net Home Page
6.1 Announcements
This is a collection of useful information that would ordinarily be emailed to students, announced in lectures or distributed as corrections made to handouts. Examples of information to appear in this section are sample test plans, Help Desk availability times, the subject handbook, staff home page and email addresses, and alterations to assignment specifications. The Announcements section tends to be used for a variety of subject information, and will be named accordingly in the next version of the software.
6.2 Assignments
This section holds the current version of the assignment specification, so that students can make sure that they have all corrections to the assignment specification, should it have been changed. These changes have direct pointers to the changed sections from the What's New section in the Home Page, and the changes themselves are stored in a separate area within the assignment for easy identification.
In addition to this, the Assignments section answers questions about how many marks each stage is worth, the weeks they are due to be submitted, and intermediate deadlines. The assignment specification is also given to students on paper, as required by university regulations.
It is planned that a section similar to the Anonymous Feedback section will be implemented in future to hold a collection of questions and answers about the assignment specification. This will ensure that all questions posed across the entire subject will be answered in a consistent manner instead of allowing the slight variations that have traditionally occurred between tutorial groups.
6.3 C++ Information
This section is primarily for help in the programming aspects of the subject. Staff provide code examples, extra information that is required and not obtainable from the text books, and demonstrations of ideas and concepts. Many of the requests for programming help can be dealt with on a large scale here, providing a resource wherein all students can obtain the same level of help with their work.
An example is the C++ source files that were added to the archive allowing the students to use a Queue class without knowing how it worked. This was intended to show the students how the notion of making objects "black boxes" improves their usefulness, as well as how providing a structure (or container class) to store any kind of object is better than making all the code data type dependent. A mime-type of application/cplusplus was added to allow students to click on the links to the C++ files and have them automatically loaded into the Borland C++ editor in the labs (or saved to disk at home).
6.4 Exercises
Each week, programming exercises and hints on solving
them are placed on the Web. Any source code to be included is
also placed there to enable download by the students, rather than
having the tutor pass around a copy of the files on disk during
the tutorial, with the inevitable risk of virus transmission and
time wastage. All source code is run though a conversion program
so that any characters that may be interpreted as HTML markup
are converted to the special escape characters provided in HTML.
| For example | #include <iostream.h> |
| is converted to | #include <iostream.h> |
Source code is displayed here, rather than made downloadable so that the students can look at the code and understand it, rather than download it and treat it as a black box. Exercises focus on the modification of that code, or inclusion of it as part of a larger program.
6.5 Anonymous Feedback
This has been one of the most successful ways of getting students to tell staff what their feelings are about the subject. Students can enter comments onto a form which is mailed anonymously to a list of staff members. This feedback is written directly to a file in the same format it is mailed. Students can view this file to reassure themselves that the feedback is anonymous, and to see what other students have said.
Staff members may select a message to answer. Only people on a staff machine may do this (i.e., in the .sd.monash.edu.au domain), preventing students from posing as staff. It is envisaged that threads will be added to this in future to allow for messages to be discussed further - something that could be better done in a newsgroup, but for lack of anonymity.
Halfway through second semester, the number of feedback messages from students stood at 120, roughly one message from every three students. The feedback and replies file reached about 200 kilobytes (of text only), before it was divided into two files. An extension for this software would be an automatic archival date of one month, after which time comments are moved to an old comments files. This would prevent excessive download delays over modem. Feedback covered issues such as:
The feedback script is written in Perl and allows much of the data regarding storage directories, the staff feedback email address list, headings and subject codes to be stored as part of the feedback form. These hidden fields are then sent to the feedback mail script as part of the CGI request. Any subject run by the department could potentially use this feedback script after construction of the form and creation of the feedback and reply file storage directories.
The follow-up script, to allow staff to comment on any issues raised, runs on the same principle. The number of the relevant article is added as a field in the feedback file, as well as the directories in which it is stored, and turned into a link when the display CGI-script is run. When this link is selected by a staff member (the IP address of the machine is checked by the Web server before allowing access), a form is generated so that the reply can be written. When completed and submitted, the staff comments are saved to a file.
When the feedback file is read using the display feedback script, the follow-up file is scanned for corresponding staff follow-ups which are added after each message to which they refer.
To prevent any abusive language or slander, a list of words and phrases and an accompanying script have been added to scan for offensive language. If a feedback post is received and found to be offensive, the student is returned a "Network Error" message and the article is not posted. This is designed to keep students from discovering that their feedback is being vetted by this script - and then trying to "beat" the script. One day an individual posted offensive material on the feedback page - since implementation of the script there has been none (whether this was a result of peer group pressure or the script is a debatable issue).
As an additional use for the feedback script, we placed a section where the students could write their own potential examination questions, the three best of which were to be used for the exam. This was designed to get the students thinking more about what they had learnt during the semester and how it might be applied to problems. It also provided a valuable revision tool for students as well as an "alert" to students who had missed some topic areas. The implementation is a reuse of the anonymous feedback script, where the output directory fields and mail addresses were changed in a copy of the feedback form.
6.6 Lectures
The Lectures page presents the collection of Powerpoint files which constitute the lecture series for the subject. In the labs, Powerpoint viewers are set up to detect when a document of type application/powerpoint is received, and start up the Powerpoint viewer. Alternatively, shift-clicking on the relevant file allows students to save the lecture overheads.
Lecture notes are placed on the Web using a form that prompts for the local filename, the intended destination filename and a description of the file. A Perl script then performs a CGI-upload of the file onto the Web server.
6.7 Newsgroup
A USENET newsgroup called monash.sd.sft1102 has been set up to allow discussion of various issues related to programming. Topics of discussion have included technical issues of using C++, installation of software at home, help with programming problems and the design of the assignment. At times this group had a low usage because of problems with the news server.
6.8 Tutorial Pages
Each tutorial group is given a form and an index page, from which it can generate pages that are presented on the Web. The index page for each group contains a list of all the presentations by that tutorial group, and a link to a form that allows the tutorial members to enter information about their presentation.
Each of these pages is then generated by the program after checking the password, and entries are added to the index files. The entire set of pages is generated by a script written in Perl, which generates all forms, index pages and acts as a data file for passwords.
6.9 Surveys
During the year we conducted three surveys using the World Wide Web. Two were regarding student feelings about assignment work, and one about the popularity of a summer semester subject if it was offered. To make this easy, we constructed a multiple choice survey form generator that took a text file of questions and options and created a form which delivered the information to a script which tabulated the results. Thus, creating these questions does not require expertise in forms. Potentially, this is another tool which the department can use to poll students on various issues.
At present the scripts produce only multiple choice questions, but this could easily be altered to accommodate extended answer questions. This section was generated purely to get more feedback - not as any kind of assessment tool.
6.10 Home Page
This page serves as an index and landmark page for navigation around 1102net. It contains a list of all the information added recently, providing quick access to new topics of interest as well as the dates these items were added.
7. Assignments and Exercises
Students are required to keep work folios of all their exercises so that tutors can examine this to identify problem areas, help the students and monitor progress. This normally involves the student keeping a folder of printouts with a table of contents and descriptions of problems and strategies, to be presented at set review times. It was decided that this material could be put on the World Wide Web by students, and that the task of doing this could form the assignment for first semester.
The assignment required the students to read in from disk the exercises they had completed, and add them to HTML files. These files would also contain the comments and problems they would normally write in their folders. Later stages of their assignment saw them adding indices and links between weeks as well as "pretty printing" their code. Upon completion, the students had their own electronic work folios on disk to give to their tutors for perusal.
Second semester assignments consisted of an airline booking system which allowed the students to create a small version of a real world system, using Object Oriented Programming. The Web was used to distribute code that could be used to construct part of the assignment and provide hints on how to create the various objects needed for a functional, well structured program.
8. Guidelines on Creating Online Course Material on the World Wide Web
When constructing course material on the World Wide Web, a number of issues have to be considered, ranging from hardware and software required to access the pages to user experience with hypermedia software.
8.1 Interface Design and Structure
Simplicity is the key to making a quickly navigable and non-disorienting document. Links to the outside world, unless central to the course, seem to cause distraction. Simple consistent graphics and icons with clear topic areas allow users to form a map in their heads of how the site is constructed. Cross linking between topic areas can show relation, but can also prove disorienting to some of the less capable students.
8.2 Download Times
Network access within the university is fast; however, access from modem is generally about ten times slower on average. If there are to be graphics on the Web pages, they should be small, use a restricted colour map and be under fairly high compression (i.e., use JPEGs). GIF files can be larger but more attractive as they can be made transparent. However, if the Web page design has a consistent background colour (we chose white) then any reasonable paint package such as Corel Photo-paint will be able to make the desired effects on the background of choice.
Text, in such areas as feedback pages, can also build up. Old text should be moved to another area in order to allow browsing.
8.3 Feedback
Students seem to prefer anonymous feedback. It also seems that some of them are distrustful that the feedback is anonymous as they do not know how the technology works, and if they logged in with a user name and a password then they feel that they are being monitored. Anonymity requires proof, and once they trust that the system is anonymous then the value of the feedback seems to increase. In the anonymous feedback section one can expect to see everything from praise to abuse. We have found that in the rare event abuse is received, if it is removed promptly or prevented from appearing at all, students give up (we also found that it is normally one or two individuals who are the culprits and their fellow students will usually remonstrate with them).
8.4 Information Retrieval
If there is any material that will not run in the browser and is meant to be considered as part of the exercises, assignment work or required knowledge then it must be easily viewable. Lecture notes and handouts should be viewable online as well as able to be downloaded and taken home for viewing. The viewer should also be made available where possible.
If code is to be used for exercises and is to be understood, it should be placed so that it is viewable in the browser itself. If the code can be downloaded and executed under the programming language, it is less likely that students will consider and understand the contents. If code is meant to be treated as a black box, providing a link that triggers a download helps the student understand that the code works and does not have to be considered in depth before use.
9. Conclusion
Some students have commented to staff members that
they felt they were getting more support in this subject because
of the availability of staff and information provided on the Web.
In addition, it provides a level of access to information from
home, which benefits those who have to travel substantial distances
to university. Collaborative learning is enhanced though the
user of newsgroups and tutorial pages, and staff stay in touch
with the students though monitoring and responding to feedback.
10. Bibliography
[1] L. De Young, (1990), "Linking Considered Harmful", in Hypertext: Concepts,
Systems and Applications,
Streitz, Rizik and André (Eds.), Cambridge Press, UK.
[2] J. Rout, (1994), "Question Answering and Learning with Hypertext", in Lessons from Learning, Lewis and Mendelsohn (Eds.), Elsevier Science Publishers, B.V
11. Copyright
Hagan & Lowder (c) 1996. The authors assign to ASCILITE and educational and non-profit institutions a
non-exclusive licence to use this document for personal
use and in courses of instruction provided that the article is
used in full and this copyright statement is reproduced. The authors
also grant a non-exclusive licence to ASCILITE to publish this
document in full on the World Wide Web and on CD-ROM and in printed
form with the ASCILITE 96 conference papers, and for the documents
to be published on mirrors on the World Wide Web. Any other usage
is prohibited without the express permission of the authors.