This paper describes how web-based course materials are being developed and implemented at the University of Minnesota College of Education and Human Development (CEHD).
Last fall, the CEHD administration charged an internal web development team with designing and maintaining a standardized World Wide Web presence for the college (representing communications, student services, and instructional uses of the Web). This resulted in increasing interest from college faculty to offer instructional materials via the Internet. In lieu of individualized web course development instruction (impractical for personnel and financial constraints), it was intended that instructors would create and manage their own web-based course materials. A user-centered web page construction and maintenance model was developed in an attempt to decentralize this process. Several significant obstacles exist that challenged the implementation of this model:
In response to this problem, an alternate courseware development model was proposed that places actual creation responsibilities with a centralized web development team, while training instructors in related aspects of web-based courseware development, management and application. To support these goals, a training and reference model was developed to provide all instructors with a common starting point for initial web-based courseware development. This model includes:
Evaluation of this training session was based on:
Based on this case study, strategies and recommendations for centralized web development initiatives are presented, and an evaluation of the courseware development model from both a faculty and professional web developer's perspective are discussed.
Keywords: development, course model, pedagogy, graphic design, case study
Introduction
In 1996 the University of Minnesota made significant changes to its presence on the World Wide Web (Web). The central University Web site underwent a major redesign, using an audience-driven model for the delivery of student services via the Internet. This initiative focused on the delivery of student services such as admissions, financial aid, course selection and registration. By making the Web integral to the student experience, the University inadvertently created the expectation that other units would follow suit. The College of Education and Human Development (CEHD) soon realized that its own Web presence should be revamped to reflect the paradigm shift undertaken by the University. By establishing new organizational and graphic standards, our goal was to provide a seamless transition to the CEHD Web site when entered through the Universityís site.
Background
During the fall of 1996, CEHD administration decided to fund a redesign of the college's presence on the Web and we were hired to jumpstart this initiative. First and foremost we decided that the CEHD site would attempt to follow the page and content guidelines established by the University's central Web development team. Doing so would make the CEHD Web space appear to be part of larger, well-organized whole. Our initial meetings with the newly formed Web Design and Development Team included several members of the communications staff, a representative from the Technical and Information Services unit of the college, representatives from student support services, and the assistant dean of the college. Our charge was broken down into three main areas ó the Internet, the Intranet, and instructional uses of technology. The Internet was deemed the first priority, as the existing site had been designed and implemented four years ago, with little change since then. The initial redesign of the Intranet followed, with page graphics and templates designed to complement the collegeís Internet site.
As work progressed on the main CEHD Web pages, faculty and staff developed an interest to devise a centralized design model for college courses on the Web. While faculty recognized the growing importance of the Web as an instructional tool and resource, previous Web-based instructional efforts had been limited to disjointed enterprises by single professors without a centralized design model or any official CEHD support. Although there seemed to be enthusiasm among faculty for a centralized Web model, there were not many instructors who felt "ready" to put their course materials up on the Web. It fell upon the Web design and development team, in conjunction with various administrative units within the college, to develop not only a template for on-line courses but to also create an infrastructure to ensure continued support for CEHD course Web sites.
Theoretical and Practical Considerations
The CEHD Web initiative forced us to reconcile two very distinct areas: pedagogy and technology. As a college of education, we should strive to model the ideas we teach, especially in a medium as public as the Web. For this reason, it was critical that we ground our Web design scheme in sound pedagogical theory. We also felt that framing the content organization and graphic design considerations with established educational theory would provide a relevant content development model for CEHD faculty. This would also serve to separate content development from technological implementation considerations. We felt that instructors should not be burdened worrying about how their class is delivered but rather focus their attention on producing quality content. The model is designed to be technology-independent, so that changes in the method of delivery do not affect what the audience sees.
In creating a Web-based course model, we realized that the Web's rapid evolution makes changes inevitable, and on a much faster scale than any other educational medium. From a technological standpoint we conceded early on that no Web solution would truly be permanent and that the CEHD course model must have room for flexibility. While one technology might provide the best solution at the moment, we should never rely so heavily upon it that we cannot upgrade when a better delivery system appears.
The Technology and Information Services unit of the college proposed the original Web development and support in the fall of 1996. This model placed responsibility for Web site development, management, and maintenance with the faculty members in each department. Upon closer examination, this individualized model quickly became an unfeasible option. The college offers approximately 600 classes every quarter, ranging in size from independent study experiences to large introductory courses with 30 or more students. The large number of courses, coupled with limited Web support personnel and budgetary resources, invalidated the idea that each faculty and staff member could receive individual instruction in Web development and maintenance. This initial concept evolved into a model in which groups would receive limited instruction in Web site design and maintenance and then support each other while maintaining their own Web environments. After reviewing other preexisting conditions within the college, this model was deemed unacceptable as well.
Rejection of these early ideas came from examination of several key points. Our primary concern focused on the actual ability of college members to create and manage their own web sites. CEHD faculty and staff possess a wide range of computer and Internet experience. User capabilities range from near-total lack of experience to a high degree of technical competency. While some faculty and staff are still reluctant to use e-mail and Internet browsers, others have tackled multimedia projects with ease. Complicating this wide range of user experience is an equally wide range of computer hardware. When CEHD Web development resurfaced in the fall of 1996, over 60% of our usersí hardware did not meet the recommended hardware minimums to run the Web software package chosen by the college's Technology and Information Services staff. While we have been diligently working to resolve these hardware-centered limitations, the process is hampered by a lack of funds, end-user hesitation to switch platforms, and the bureaucracy inherent in any large organization.
A secondary concern centers on the nature and organizational structure of Web services within the college. As little as 3 years ago, CEHD Web services consisted of a single network administrator with a few Macintosh computers. Since there was relatively little development at that time, the additional workload was minimal and any changes the network administrator made to the Web configuration went unnoticed by end-users. The college now runs several Windows NT Web servers but still relies on one network administrator and numerous student support staff. If the NT servers go down for maintenance or upgrades, many more people are affected. If we had advocated for adopting the individual development Web model, each instructor would maintain his or her own Web space. To do so they would need to understand all the details of managing such a space, including how to respond to changes in service, how to change links within a Web document or to change Web addresses, and so on. This seemed an unreasonable expectation, given our assessment of faculty and staff Web development skills and knowledge.
Our final opposition to the individual development model was based on the dissemination of technology. In any group of users, knowledge on a particular subject will vary. While some instructors are well versed in effectively using current technologies within educational settings, many are poorly prepared or have no knowledge of the latest advances. This would result in a discrepancy in the overall quality of Web materials. Not only is this unfair to those instructors who possess less knowledge or experience than their peers, but students suffer by not benefiting from well-designed and implemented Web courseware. After taking all of these factors into consideration, we found it necessary to propose an alternate Web development model, which features both a centralized Web team and enlightened, self-sufficient users.
Process
To begin educating the faculty in the area of Internet development, we created the World Wide Web Toolbox. The Toolbox was initially intended to live on the Intranet and serve as a repository of information relating to the development and use of Web pages in the college. The site was initially aimed at developing Web sites in stages, with low-, medium-, and high-end solutions for the Web. Many of the resources listed were links which took the user to other places at the University that provided guidance in these areas. The response to the Toolbox was positive, but it failed to generate any significant interest from faculty in Web-based courseware.
Realizing that perhaps instructors could not ask for that which they could not comprehend, we decided to tackle an individual course, with the hopes that it could serve as a model for other instructors. The course, Curriculum and Instruction 5145: Social Studies and the Internet, proved to be an excellent opportunity to merge theory and practice. This distance education endeavor was designed to teach K-12 teachers how to bring the Internet into their classrooms in pedagogically relevant ways. We decided that the Web site design and content would need to be pedagogically relevant as well and we set out to design templates that would fulfill these goals. We attempted to design a course model that emphasized the content of the course, not the design of the Web pages, by working with the basic cognitive psychology principles of automaticity (Duffy & Cunningham, 1996), affordances (Norman, 1988), chunking (Winn & Snyder, 1996), advance organizers (Winn & Snyder, 1996), and user-centered design (Norman, 1988). It was our hope that this model would prove flexible enough to become the cornerstone for further college coursesí presence on the Internet.
We began the process by meeting with the instructor (a graduate student), and her advisor, explaining our approach to course design via the Internet. They were very willing to adapt the course content to best suit this new medium. Our initial site design and suite of graphics included the following components: the University of Minnesota wordmark (logo); the CEHD wordmark (logo); a banner graphic that included the course number and title; a left column button menu with 7 buttons; and a footer that contained copyright and contact information. We chose the button menu topics (syllabus, listserv, assignments, instructor, bibliography, resources, and home) to fit the course materials paradigm currently in use at the University. We felt that by presenting the information under familiar headings, users would need less instruction on how to navigate the site and instructors would have an easier time conceiving of their course content in this new medium. College administration supported the model, since it offered consistent representation of basic course information for all CEHD courses. In addition, users were able to access any of these critical areas from any page in the course Web site.
In late summer of 1996, the collegeís network administrator evaluated the major HTML editors available at that time and selected Microsoft FrontPage. He felt that it offered the best combination of managerial and creative features. One of the main attractions to using FrontPage as the development platform for CEHD courses is the ease with which developers can "automate" certain processes. The left column button menu, for example, is a WebBot component that is created once, saved, and inserted into each subsequent page as one item. This accelerates the development process significantly. We were, however, disappointed with FrontPageís discussion group capabilities and were forced to explore other software alternatives for this feature. Also, as the desired goal of the Technology and Information Services unit was for everyone to develop and maintain their own Web space, this template model and the automation features made it easy for us to provide the "shell" to people so they could insert their own content.
Working closely with the instructor, CI 5145 took shape. The final product fulfilled all of our expectations. In fact, we began to show it as an example when we met with other instructors to discuss putting their course materials up on the Web. We soon realized, however, that this particular course might not always be available for demonstration purposes and we decided to create a tool for instructors that would help guide them in this process. Thus, the On-line Course Construction Guide (OCCG) was born.
The OCCG was developed as a content neutral model that would help guide faculty Web development. The OCCG is a site unto itself, accessed from the World Wide Web Toolbox through the CEHD intranet. The site is set up just like an on-line course, but the content details how to develop your course materials for distribution via the World Wide Web. We also provided suggestions for using the Internet in course management.
Armed with the OCCG and the CI 5145 Web sites, we set off on a new round of soliciting Web course materials. We demonstrated these models to the collegeís technical coordinators, the Administrative Council, and the Committee for Academic Uses of Technology. We again met with enthusiastic receptions, but experienced no change in the volume of our business.
After further review, we uncovered some basic areas of concern among all members of the college who could possibly be involved in the course development process. The network administrator did not have a clear picture of how to structure this endeavor on the college servers. Complicating this was the fact that some departments within the college had their own servers and were not necessarily bound by the same guidelines that the departments using a central server would be. There also seemed to be no consensus on what role, if any, the technical support staff would play in facilitating Web-based course development within the departments. Web support has not been a stated component of the technical coordinatorís job description, but many had ventured into this territory at the request of members of their home departments. Finally, instructors seemed hesitant to learn how to construct and maintain Web sites without some sort of incentive or compensation to do so.
Meanwhile, technical staff continued to champion the initial Web development model of individual instruction despite our reservations. We tried to implement this model and experienced our first setback when we could not find any professors who had the time to sit down and learn a whole new software package. We attempted to work with several technical coordinators to jump start development efforts in a few select areas. Faculty members in three departments expressed interest: Curriculum and Instruction, Kinesiology and Leisure Studies, and Educational Psychology. We decided it would be best to meet with interested instructors and their technical coordinators to assess each situation and provide the necessary support. In general, we found that there were two factors common to each situation: enthusiastic faculty members who wanted to create a Web presence for their courses but had no idea how to do so; and technical coordinators who were willing to help with the project, but did not possess the appropriate resources to do so. Complicating this situation was our observation that the ability of the technical coordinators to support their respective departments in this area varied widely Some coordinators were able to use the software immediately, while some may never be able to do so.
In an attempt to get a clearer picture of the hardware and software challenges we faced, we compiled a survey of all of the computers in the college. As previously stated, approximately 60% of the computers in the college were unable to use the FrontPage software. This immediately pointed out to us that the "every user a Web page creator" model was already in serious trouble. Even our experience with getting higher ability computer users to use FrontPage was disappointing. We had been working with the communications staff, teaching the graphic designer and public relations writer how to use the software. While both individuals possess high-end word processing and desktop publishing skills, the conceptual model of FrontPage proved difficult for them to grasp. To date, the communications staff has been able to create and update simple pages, but will probably never be able to engage in higher-order site management and administrative tasks.
Current Courseware Development Model
In response to these problems, we decided to implement our courseware development model which places actual creation responsibilities with a centralized Web development team, while training instructors in related aspects of Web-based courseware development, management and application. To support these goals, we proposed a training and support model to provide all instructors with a common starting point for initial Web-based courseware development. This model includes:
We have tried to borrow the best parts of each original development model. However, we recognize that we cannot ask every faculty member to just leap in and begin designing and maintaining their own Web sites. This model gradually increases an instructorís exposure to and responsibility for a course Web site. With initial development and implementation resting on our shoulders, the faculty member is free to concentrate on learning the software and understanding what it means to maintain a Web-based course. Finally, the faculty member begins developing his or her own course sites, relying on the central Web team only when support or guidance is necessary. This incremental approach to faculty empowerment offsets fears of technology and the perception of a Web course as an additional administrative burden. With knowledgeable faculty members maintaining their own Web sites, we can focus on Internet research and development and work with the latest technologies to see which will work best for our faculty. Additionally, we will continue to work directly with faculty and staff on larger Web projects that require more comprehensive support and expertise.
Evaluation
The course model was presented at the 1997 CEHD fall faculty retreat. We consider the initial presentation of our model successful for several reasons. The purpose of the presentation was to introduce faculty to the Web course model and the resources available to assist them in integrating Web support into their existing courses. One measure of our accomplishment is based solely on the number of faculty who are now aware of our presence and intent. Through this one session we reached approximately fifty percent of the collegeís instructors, including all department and research center chairs. A second measure of success stems from acknowledgement by the attending faculty of the cognitive psychology and graphic design principles, which are the basis of the overall structure of the model. This we infer from questions and comments, both during and after the presentation, concerning items such as:
Further feedback from attendees provides another indicator of success: the willingness of interested instructors to accept and use our course model. In discussing the presentation with instructors in subsequent encounters, there was clear recognition of our desire to minimize the effort required to implement the Web course model, both in the development stage and from a maintenance perspective. They also welcomed being freed from the initial worries of designing and building a Web course that would fit into the collegeís overall scheme. In the days immediately following the presentation, instructors began to set up appointments and submit materials to create Web courses for the winter quarter. We hope to see a steady increase in the number of CEHD courses with a Web presence.
Recommendations
Based on our experiences building a Web development initiative from the ground up, the responses of our individual trial users, and the general response of faculty at the large presentation, we present the following recommendations.
Conceptual Recommendations
First and foremost, do your homework. Take the time to find out what instructors in your college need, what the college administration needs (expects), and investigate what direction your university is taking with respect to Internet development. Then determine how your initiative can best serve these goals. We encourage you to resist any attempts at skipping this process. Many people are very enthusiastic about Internet development and are very anxious to see actual pages up on the Web. Reassure them that the actual page construction is the quickest part of the process and that time spent getting all the issues on the table will actually get you to a workable solution faster.
Use known paradigms to organize course materials and provide consistency across departments. Instructors in the college and across the University have relied on custom course packets to support their instructional endeavors. The faculty is very familiar with the process and the students understand the concept as well. This means that students come to a class knowing how to interact with the materials. We decided to use the course packet paradigm to segment the course information on the Web because we did not want students to have to spend time figuring out how to use the Web site. We wanted them to be able to transfer preexisting procedural knowledge onto the Web.
Use known paradigms to ease the transition into "high tech" teaching. We felt it was just as important that CEHD instructors, as well as students, ease into using the Web. Again, we chose to follow the course packet paradigm, emphasizing the divisions of content as well as the submission process. Faculty members can submit information incrementally, just as they often do with course packet materials. We also advance the concept that unlike course packets, they have the opportunity to fine-tune their course materials throughout the courseís duration.
Consider what this process looks like to your "customers", not yourself. The entire Web development process may seem easy and obvious to you, but chances are you have a lot more experience with the technology and software than the instructors in your department. This does not mean that they are uninterested or unwilling, it simply means that they donít understand the concept. Having things that your audience can look at and interact with, in a form that makes sense to them, will go a long way to bridging this conceptual gap.
Always keep in mind that a professorís main responsibilities are teaching, research and publishing, not Web development. While you may have faculty members expressing interest in learning new software, etc., be prepared for the reality that they might never have the time to do it. Always keep this in mind when setting up a system for getting Web work done.
Technical Recommendations
Always keep in mind the level of technical support you are likely to get, not what you would like to get. Remember that even among technical support staff, people have different levels of ability and different areas of expertise. Be careful about venturing into territory that can not be adequately supported by you or other members of the technical support staff.
Always keep in mind the ability of your end users. This includes access to the necessary equipment, as well as the general level of technical expertise. In CEHD, for example, most of the students in the upper division courses and programs are working professionals and adult learners. Chances are good that these students do not have the same access to computing facilities as students who are on campus every day, using the computer labs. If the majority of your constituency is dialing in with slow modems, it might be best to rethink your use of high-end Web solutions. Another consideration for us is that many of these people work in the educational marketplace and are often several versions of software behind the rest of the world.
Also remember to consider the ability of the instructors to implement and support any Web initiative. We purposely included an active discussion group in the OCCG to give instructors experience using the software. This way, if they run into problems during their classes, they will possess some knowledge about how the software works.
Donít reinvent the wheel if you can avoid it. We have some very talented students in the technical support area of the college who are capable and interested in devising customized solutions to our courseware delivery problems. We have, up to this point, resisted the temptation to do so because chances are good that the people who create these applications will not be around to support them in the future. Purchasing prepackages solutions defers some of the technical support to the manufacturer.
Along the same line, remember that you must be able to support the solutions you provide. Whether it is a custom-designed application or prepackaged software, keep in mind that people are going to need help learning and troubleshooting these applications. It is a good idea to have support dispersed among several individuals. One person with all the knowledge or all the access is not a good solution. If you can truthfully say, "If our tech support guru gets hit by a bus on the way to work, we will have no network", then your support structure is too concentrated. If a bus does hit him or her, you will be in big trouble.
Donít promise to users what the software promises without first making sure that it will actually work. We were assuring our instructors that the FrontPage discussion group feature was going to be the vehicle for providing those services to faculty, because FrontPage said it would work. When we actually tested this feature and discovered it would not meet our needs, we were forced to adopt another solution. In the meantime, we had people creating content for their students based on parameters specific to the FrontPage discussion software and it had to be changed.
Just because something can be done doesnít mean it should be done. Make sure that your solutions reflect the needs of the instructors, users and course content. If your primary audience is only using Netscape 2.01, perhaps JavaScript is not a good choice. Make sure you really need the bells and whistles. Instructors and students need appropriate access to the content. Anything that prevents or hinders that should be removed from the site.
Managerial Recommendations
Itís better to start small and work up to more ambitious features as your development initiative progress. Bear in mind, particularly if Web development is new to your department that people will want to see results that work ó quickly. It is much better to start out with a manageable set of expectations, fulfill them, and have new ideas ready for further development.
Set incremental development goals. This will help set priorities and it also helps to test the waters on certain aspects of your goals to see where to expand services and where something isnít panning out. The main goal of the initial phase of Web development for CEHD courses was to create a common set of pages for each course that represents that course on the Web. When that is done, we will move on to helping the faculty teach courses using the Weband become more Web proficient, and help develop other uses for technology in the department.
Focus on stabilizing how the process appears to the user and how the process will work for your instructors. Keep the customer service side of your development process consistent. You can tinker behind the scenes all you want, but this should be transparent to your audience. Remember too, that is far easier to add services and features than to initially provide them and then take them away.
As with any uncharted territory, you need to realize your efforts will inevitably lead to other, unanticipated areas of concern. For instance, when we were presenting our course models to faculty groups, we found out that they have tremendous concerns about Internet security and protecting the copyrights to their intellectual property. While we could provide answers on the technical side, we eventually invited a University copyright administrator to speak to their other concerns.
Also realize that people will use the technology as an excuse not to do something. Be prepared to show why this isnít so. For example, we have had faculty members use Internet security as an excuse for not putting materials on the Web. Since we could not guarantee 100% protection for their materials, they said they were not going to risk having someone steal their content. We had to point out that there was absolutely nothing preventing anyone from going to the bookstore, buying their course packet and copying its content.
Realize that you may be navigating a political minefield ó be a diplomat. We interact daily with a wide variety of people, each of whom has his or her own agenda for managing our time. We are privy to passwords, procedures, attitudes, policies and other information that should not be abused. We recognize our unique position in the college and we work hard to maintain the trust put in us by members of all these groups.
Finally, donít be afraid to say you donít know ó but do find an answer for someone in a timely fashion. People will respect your honesty and you will save yourself a lot of time avoiding the inevitable backpedaling that hasty answers create.
Conclusion
As of this writing, two positive steps have been taken as a result of our efforts. A Web Steering Committee has been formed with the express purpose of providing a central guiding body for all such activities within the college. While primarily focussed on college-wide web initiatives, this committee will work with the collegeís Committee on the Academic Uses of Technology to oversee instructional web efforts. The driving force behind this committee's formation and perhaps the most significant outcome of our work to date is the enthusiastic support from CEHD administration in light of the faculty response to our presentation. We have been assured that more resources, including funding, will be available to continue development in this area. We look forward to a busy year ahead as we implement our model on a larger scale. Additionally, we anticipate future phases of the model that will incorporate more interactive technologies and build upon the framework established here.
Bibliography
Duffy, T. M., & Cunningham, D. J. (1996) Constructivism: implications for the design and delivery of instruction. In Jonassen, D. (Ed.), Handbook of research for educational communications and technology (pp. 170-198). New York: Macmillan.
Norman, D. (1988). The psychology of everyday things. New York: Basic Books.
Winn, W., & Snyder, D. (1996). Cognitive perspectives in psychology. In Jonassen, D. (Ed.), Handbook of research for educational communications and technology (pp. 112-142). New York: Macmillan.
Anthony Hill Simione and Jill M. Tuttle
Web Design Team
University of Minnesota College of Education and Human
Development
203 Burton Hall
178 Pillsbury Drive S.E.
Minneapolis, MN 55455-0211
ahs@tc.umn.edu and
tuttl002@tc.umn.edu
http://www.coled.umn.edu
c,1997. The author(s), Anthony Hill Simione and
Jill M. Tuttle, assign to the University of New Brunswick and other
educational and non-profit institutions a non-exclusive license 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 author(s) also grant a non-exclusive
license to the University of New Brunswick to publish this document
in full on the World Wide Web and on CD-ROM and in printed form with
the conference papers, and for the document to be published on
mirrors on the World Wide Web. Any other usage is prohibited without
the express permission of the author(s).