Conclusions and Recommendations

1.  Teaching a UAF graduate environmental engineering course by completely electronic means is feasible.

2.  There are very few impediments to remote students registering, paying their fees, getting an Email account, and logging on to the ECM tool.  Most problems were minor and easily corrected in a few days.  At the beginning of the course there is a large potential for frustration for both the instructor and the remote student, because neither can fix these problems immediately.  Further, if the student discovers a problem on a weekend, and instructor does not check Emails until the workweek, or it required UAF office that is not open on weekends, it will take at least several days to clear a minor problem.  (Many of the students do their work over the weekend.)   These are the busiest time of the semester for most of these offices.  I don't see these problems ever being completely removed.  Things that might help are to:  warn students of the possible for glitches and the requirement for patience, arrange the first lessons so the students can start without completing the registration and Blackboard process, persuade the students to register early.

3.  Teaching with Web-based pedagogy is effective.  The standard method of assessing instruction indicated the web-based course was comparable with classroom-based courses.  Students reported they we as satisfied with this method as classroom-based instruction.  Most parameters were comparable.  Numerically the web-based scored better on most parameters then the same and similar courses taught in the classroom.  The data do not lend themselves to statistics, but qualitatively there is some evidence that the students perceived the web-based course as slightly better instruction.

4.  Answering a qualitative question, the students reported that the web-based course required more work than an equivalent classroom-based course.  In qualitative questions, the students also indicted that the course was more work.  The effect of commuting on the effort put into the course was not queried in the IAS.  For full-time students this is difficult to evaluate while they take the IAS.  For part-time students taking one course, the commute would be part of the time and effort for that course.  Since the course indicated, on the average, about one hour per week more effort than similar courses, if we assume the commute was not in the classroom-based courses, the amount of effort is quite similar.

5.  The resources required by the faculty: vendor-supplied training, hardware, software are minimal and are not an impediment.

6.  The time required to develop the course, about 350 hours, should be compared with the following: 1500 hours in a nine month contract, 60% teaching equals 900 hours,  four courses equals 225 hours per course or 450 hours for two.  Hence the time to develop this course was the equivalent of about one and half teaching loads.

7.  The time to teach the course, 207 hours, is similar to the 225 hours above.  The second time the course is taught, I would allow for three hours per week for review and update, (3 * 15 =45) 207 +45 = 252 or slightly more effort than an equivalent course. 

8.  The faculty time to teach the course, especially interaction, is necessary to a high-quality web-based course.  This involves electronic transactions with the students.  It appears that this transaction time will increase linearly with the number of students.  Contrast this to a classroom-based course where only a few students actually interact with the instructor via questions.  Grading of numerical homework problems might be delegated to a student grader, or be made automatic.  Grading of essay questions and interaction should not be delegated in a high-quality graduate course.

9.  The investment in electronic distance education via web-based pedagogy is almost entirely in faculty time.  There may be some payback in student satisfaction, but it is not large relative to similar classroom-based courses.  If there is a significant payback, it would be in numbers of students taught.  If we consider a classroom course that would have 15 students on-campus, and developing the course is equal to teaching it twice, it would require increasing enrollments from 15 to 45, if the electronic class was taught only once.  With each time it is taught again, the incremental number of students required to amortize the development would decrease.  Here is a table:

While the numbers above are somewhat arbitrary, the principle is sound.  Clearly before the investment in faculty time is made, a sufficient market must be available.

Lessons Learned

Here are some things I would do differently in the future:

1.  Do not leave spaces in file and folder names.  When my WYSIWYG program sees a space in a file name or folder, it put "%20" into the URL. That makes clumsy mess of a simple name "Module 5" becomes "Module%205.". Write the names together, "Module5" or use the underscore Module_5, that keeps it readable.

2.  Paper, on line sources.

On-line resources are an ever-increasing literature source for student papers.  While this is to be expected, and properly referenced is not a scholarship problem, I wanted to be sure the students were familiar with searching the primary literature, most of which is not on-line.  It can be accessed electronically through libraries, but this puts a burden on off-campus students to get connected to the library.  Some library resources can only be accessed via a computer that has a UAF IP address. Next time I would recommend limiting my directions in the course to one database with specific instructions for that database, but then require use of that site in a definite assignment.

3.  Referenced Web sites down.

Bad hyperlinks are common on the web.  The web-searcher gets an error message, such as "404" or "we have moved" message.  Electronic course preparation can eliminate these; at the time the pages are written.  Any time after that, however, the site might change and URL become bad.  We discovered a different problem.  Even good sites occasionally go down, either because of an equipment problem or to perform some maintenance.  For a student working in Alaska at 8 PM Sunday night, it is midnight on the east coast, a time when planned maintenance may be taking place.  In any case I had built several assignments around particular web site, and when these were "down" for whatever reason, the students get an error message and could not complete their assignment.  This leads to Emails to the instructor, but, by the time he gets the Email and checks the site, it may be "up" again.  Because these are random events, this seems unavoidable.  Most sites have a Webmaster, but by the time they respond, the problem may have cleared up.  Warning the students early in the course of the possibly of sites going down and up may help somewhat.

4.  Mobile students

Several students traveled during the course.  One student traveled to India, but reported that the Internet connections were not sufficient to work on the course effectively - she kept getting cut off.  One student reported that as he traveled, he was a guest on others computers, and was reluctant or had difficulties with different operating systems, files and so on.  Two student traveled to the North Slope on emergency business, but the Internet connections were not convenient and the extended working hours were not conducive to school work.  For these and other cases I accepted late assignments.  This was barely manageable with 15 students.  For 20 or 25 students it would become impractical to accept late assignments.  Also, those submitting late work could not participate in discussion questions on time.  Even with classroom-based courses, these difficulties are common with part-time students who have full-time jobs, especially in Alaska where travel is required for many jobs.  My impression is that while the "Internet is everywhere," it is often impractical for traveling student to work on the course.  Again, this is related to expectations and explaining this to students in the marketing process is important.

Appendix A

URLs

TOC