See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221538639

A Web-based lab manual for CS 1: an experiment

Conference Paper · January 2000

DOI: 10.1145/330908.331828 · Source: DBLP

CITATIONS READS
3 743

1 author:

Thomas J. Cheatham
Middle Tennessee State University
37 PUBLICATIONS   193 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Mathematics as a First STEP for STEM Success in College View project

All content following this page was uploaded by Thomas J. Cheatham on 30 September 2014.

The user has requested enhancement of the downloaded file.

 A Web-Based Lab Manual for CS 1: An Experiment
Thomas J. Cheatham
Department of Computer Science
Middle Tennessee State University
Murfreesboro, TN 37132
cheatham @mtsu.edu
Abstract
No one can deny the impact the web is having on education.
Computer Science education is no exception. Computer
literacy classes now include units on web surfing and
personal web page creation [6]. Data structures students
have web tools for viewing algorithms and dynamic data
structures [2, 4-5]. Computer graphics students have 2D
and 3D visualization tools [7], and database students learn
to access remote databases using ODBC or JDBC over the
web [1]. Special courses in web technologies are being
added to the curriculum in many departments [3]. It is only
natural for a laboratory manual for Computer Science I to
be presented as an interactive web document.
Pedagogically, how does such a laboratory manual compare
with the traditional hard-copy manual? What are its
strengths and weaknesses? Which approach do students
prefer? We sought to answer these and other questions
from our empirical study of Computer Science I students.
The results of the study and the lessons learned will be
described in this article.
1 Overview
Before an empirical study of the pedagogical
(dis)advantages of a web-based laboratory manual for CS 1
can be conducted, such a manual must exist. Faculty in my
department wrote a laboratory manual that we have been
using for our CS 1 class for the last four years (with
continuous updating, of course). The lessons learned from
"web-i-fying" this manual are an important part of this
article and will be discussed in the next section. Then, we
will describe the study and the results along with some
suggestions for others who travel this road.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that
copies ere not made or distributed for profit or commercial advent
-age and that copies bear this notice and the full citation on the first page.
To copy otherwise, to republish, to post on servers or to
redistribute to lists, requires prior specific permission and/or a fee.
SIGCSE 2000 3/00 Austin, TX, USA
© 2000 ACM 1-58113-213-110010003.- $5.00
105
2 Creating an Interactive Web Laboratory Manual
Creating an interactive web-based laboratory manual is not
a difficult task but there are some interesting technological
and pedagogical issues that must be •
addressed along the way. One of the major labor intensive
parts of the process is converting the hard-copy manual to
HTML. We tried at least three methods: using a word
processor (MS Word) to create HTML code; using an
HTML editor (Netscape Page Composer); and, coding the
HTML codes by hand. It would seem that nothing beats the
word processor approach for speed. However, speed
turned out to be its weakness. It is true that MS Word can
add HTML tags to the document faster than a person can by
hand, but (1) the spacing is often not what you want, (2)
color costs too much in a hard-copy manual, so there is no
color in the HTML document, (3) graphics may get
botched, and (4)C++ code snippets are often a mess.
After using the "Save as HTML" feature from MS Word for
a couple of lab assignments, we decided it is more time
consuming to "clean" the resulting HTML code than it is to
create the HTML code by hand. This does not mean we
type each and every HTML tag. Copy-and-paste functions
take care of retyping complicated tags. Doing this
repetitively for fourteen labs is boring and error prone, but
it is actually quite efficient. A main advantage of using an
HTML editor such as Page Composer is the ease with
which special spacing can be accomplished. A combination
of hand-tagging (mostly accomplished with copy-and-
paste) and an HTML editor proved to be the most effective
in the end. Once we had the basic layout (background,
formats, links, and so on), it took about five hours to create
the interactive HTML code for one laboratory and its
answer sheet.
We teach Computer Science I using C+÷ in a UNIX
environment, the same UNIX system that is our web server.
The HTML <FORM> .tag enables the (client) browser to
send student answers to the web server. A Common
Gateway Interface (CGI) program running on the server
processes the answers. The CGI program is written in Perl
since most of what it does is "parsing." The system does
not automatically grade laboratory assignments. Its primary
functions are (1) login security, (2) presenting the
laboratory text to the browser, (3) saving answers from
partially completed assignments, (4) presenting the answer
sheet for editing, and (5) presenting the final answer sheet
for printing.
To use the lab manual, the student must first "login." The
login screen has a text box for the student's name and
computer account/user name, and a list box to choose the
instructor. The user name is used for saving answers. The
login data is passed along throughout the various
communications between the student and the CGI through
hidden fields in the HTML code. This is one of the reasons
we have the CGI program read the HTML code for the
laboratory assignment and create the web page. It also
provides a small amount of security.
Saving answers in the student account requires that the
CGI program (running under the control of the web server)
has access to the student's account, a potential security risk.
Also, students have to be responsible for deleting old
answer files. We decided to store answers temporarily in
the/tmp directory which is routinely purged (but not oRen
enough to cause a problem on our system). A student can
copy the answer file to his/her account if he/she feels the
need. Answers are stored in a text file in "name=value"
pairs. Originally, we decided to store answers only when
the student pressed a submit button "Click to Save Answers
Only if You Must Leave Before Completing." Because of
hardware configuration problems explained in the next
section, this was an unwise decision. Now, answers are
saved on demand and automatically upon submission.
The CGI program also provides a last chance to edit the
answers, still in <INPUT> tag form, before providing the
final answer sheet which must be printed using the
browser's print function. Many other choices are trivial to
implement. For instance, we could email the answer sheet
to the lab instructor or email the lab instructor a hyperlink
to the answer file.
In summary, the CGI program sends an HTML file
(containing FORM tags) to the browser and, when the form
is submitted, it parses the input, saves the answers, and
displays the answers for editing. When editing is
completed, the CGI parses, saves, and displays the answers
again in printable format. The same CGI works for all
fourteen laboratory assignments, and with only a couple of
code changes it is being used for other classes too.
3 Lessons Learned
New technologies bring new challenges, that make
computing exciting (and sometimes frustrating). This
Some of these problems were caught before the experiment
project was no exception. There were little problems such
began and some were found during use.
as
106
the decision to only save answers on demand. On more
than one occasion after the final answer sheet was
displayed by the browser, it was discovered that the PC
did not have a printer configured. This would never
happen in a perfect world! Configuring a printer often
requires a reboot and results in losing the posted
answers (which had not been saved). Solution:
Change the CGl program so answers are automatically
saved before they are printed.
where to save the answer files. CGI programs only
access files and directories accessible to the http
daemon. Generally, this does not include student
accounts. Solution: Store answers in /tmp/
userid.labnumber which is automatically purged in a
timely fashion. Students can copy their an.swer file to
their account if they know it will be a f e w days before
they can finish.
forgetting to change" the <FORM> submission method
from GET (used in debugging the CGI) to POST mode.
Long answers will overflow the buffer. Solution:
Change from GET to POST.
multi-line answers entered into a <TEXTAREA> do
not print on multiple lines on the answer sheet.
Solution: Have the CGI program replace newlines '~n'
in the answers with HTML break tags "'<br>" before
printing the answers.
there are no links to previous laboratory pages. So, it is
easier for a student using a hard-copy manual to look
back at previous labs to review how to do something.
Solution: Insert links to each previous lab using
TARGET= "_NEW" so that a new copy of the browser
will be opened, thus protecting answers already posted
in the current lab.
answers containing certain special characters (such as
<, >, and ") cause printing problems. Solution: Have
the CGI program convert these characters to non-
offensive HTML characters such as &lt;.
a browser losing posted answers when it. is maximized
or minimized. Solution: Get a newer version of the
browser.
losing answers because'an input tag name was copied
twice and only changed once or, alternately, the CGI
program does not properly handle input tag names
delimited by quotes. Solution: Proper testing and
debugging.
 4 The Experiment twice each week. The laboratory session for the control
group was scheduled immediately after class on Tuesday,
In spring 1999, two sections of Computer Science I, taught while the laboratory session for the treatment group was
by the same instructor and laboratory assistant, served as held after class on Thursday. A coin toss determined which
the subjects for the control group (C) and the treatment class would serve as the control group.
group (T) for the study. The treatment group used an
interactive on-line laboratory manual while the control ACT scores and GPAs were collected for each student. The
group used the "same" manual in traditional hard-copy control group had a higher average G P A (2.9 to 2.6) and a
form. Of interest is whether one manual is better than the higher average ACT (23.9 to 22.8) but neither was
other pedagogically, and, of course, the student's reaction statistically significant (difference in sample means, two tail
to the interactive manual for CS 1. Hypotheses were tested test at 5% level). Yet, the treatment group ended up with a
using the distribution of differences in the means of the two higher class average (76.8 to 69.0). Lab attendance was
samples and a two-tailed student t-distribution at the 5% better in the treatment group (25.3 students on the average
level. When the sample size is larger than 30 as it was to 23.8), and more students in the treatment group persisted
originally, the student t-distribution is equivalent to the to course completion (25 to 20). None of these differences
normal distribution. was statistically significant as can be seen from Table 1
above. Overall, this study reveals no significant difference
in the two approaches to presenting the laboratory manual
Table 1: Statistics for Empirical Study for CS 1.
Hard- On- STDev" z-score Significant
Copy Line of diff. t-score abs(z)>l.96 Permit me to make a few non-scientific personal
Enrolled 35 35
observations. In my experience, morning classes are often
superior to afternoon classes. At the beginning of the
Completed 20 25 semester, I was convinced the control group was the better
class based on class participation and early work. By the
end of the semester, I was convinced the opposite was true.
Average 23.9 22.8 1.70 0.67 No
ACT The treatment group was definitely more fun to teach.
Their attendance was better in lab and lecture and more of
Average 2.9 2.6 0.20 1.07 No them completed the class. It will be interesting to follow
GPA !
their progress in CS 2.
Course 69.0 76.8 5.14 0.31 No
Average To assess student opinions, each class was asked to use the
approach from the other class for the last laboratory. That
Lab "84.1 84.1 3.15 0.22 No is, those using the web were given a hard copy of Lab 14
Average
and asked to not use the web. Those using the hard-copy
Lab 23.8 25.3 2.17 0.54 No manual were given a brief introduction to the web manual
Attendance ! in lecture and asked to use it for Lab 14. Then, each class
I
Prefers 5 4 0•18 10.85 No
Other i ,
Table 2: Student Surve I
*Standard deviation •o f the difference in sample means Hard-Copy On-Line
Enrolled 35 35
CS 1 is taught using C++ in a UNIX environment. The
manual [3] contains 14 laboratory assignments starting with Completed 13 18
an introduction to UNIX and ending with multi- Survey
dimensional arrays. One two-hour closed lab assignment is
completed each week. Each lab assignment is graded and Prefers Other 38.4% 23.5%
returned the next week. These laboratory assignments are
separate from regular class projects. Used at Home 38.4% 61.1%

Students did not know before they registered that they Used Outside 46.1% : 61.1%
would participate in an experiment nor did they know Lab
which class would use which manual. As is typical, 35
students signed up for each section. Historically, about Advantages Portable, easy Low cost,
40% do not complete the course. These sections were reference easy to use
typical. The control group was an 8:00 AM class and the Disadvantages Cost, Portable,
treatment group met at 12:10 PM. Both met for 75 minutes Available Convenient

107
 was asked to complete an opinion survey. Table 2 contains [61 Pierson, W. and S. Rodger. Web-Based Animation of
a summary. A larger percentage of the control group Data Structures using JAWAA. Proceedings
(38.4% to 23.5%) reported a preference for the other SIGCSE'98, 1998, 267-271.
approach. Of course, with only one opportunity to
experiment with the other approach, students had little [7] Towsend, G. Turning Liabilitities into Assets in a
experience to make a decision. The most frequent comment General Education Course. Proceedings SIGCSE'98,
made by the control group: "Prefer hard-copy manual since 1998, 58-62.
I can take it anywhere" seems moot since more than twice
as many of the treatment group reported actually using the
manual outside the laboratory sessions. The most frequent
comment of the treatment group: "Prefer web manual since
it is less expensive" is important but not pedagogically
revealing. Again, they did report more use of the manual
outside the laboratory setting and this is desirable.

5 Conclusions

Statistically this study shows no difference in outcomes or

student preferences between the traditional hard-copy
laboratory manual and an interactive web-based manual for
Computer Science I. The web manual saves money for the
students and is more environmentally friendly. The initial
work to create such a laboratory manual is significant but
not forbidding. Future maintenance of the manual should
be about equal. We now have three classes using
interactive web manuals---Computer Literacy, Computer
Science I and II. Obviously, we felt that the experiment
was a success and that interactive web manuals are an
acceptable way to present laboratory material, A copy of
the interactive web-based laboratory manual for Computer
Science 1 can be viewed at
http://www.mtsu.edu/~csdept/117man.

References

[1] Asalam, S. Web-Based Query Processing in a

Database Course. Proceedings SIGCSE'98, 1998,
297-301.

[2] Baker, R., M. Bailen, M. Goodrich, R. Tamassia, and

A. Stibel. Testers and Visualizers for Teaching Data
Structures. Proceedings SIGCSE'99, 1999, 261-265.
[3] Hankins, J., B. Parker and M. Thweatt. Computer
Science I: Closed Laboratory manual using UNIX
and C++. RonJon Publishing, Inc., 1998.

[4] Lim, B. Teaching Web Development Technologies in

CS/IS Curricula. Proceedings SIGCSE'98, 1998,
107-111.

[51 Naps, T. and E. Bressler. A Multi-Windowed

Environment for Simultaneous Visualization of
Related Algorithms on the World-Wide-Web.
Proceedings SIGCSE'98, 1998, 277-281.

108

View publication stats