One Size Fits All? – The Case of ECNG 3020 – Special Project Portal

Wayne Sarjusingh, Fernando Castellanos and Crista Mohammed
The University of the West Indies, Trinidad and Tobago

ABSTRACT

ECNG 3020 - Special Project Portal is a custom-built, course management system. Specific administrative demands of a year-long student-project necessitated an e-solution. The Portal serves as: 1) a central information hub, 2) an administrative and processes management platform and 3) a sharing tool. End-user feedback was positive. Users highly valued the centralisation of course information and scheduling provisions. The Portal’s many facilities and inherent adaptability justify significant initial outlay as it promises to serve the Special Project for the long-term. Its greater potential is its utility in the management of similar courses.

Keywords: UWI, customised course management system, software prototyping model

INTRODUCTION

ECNG 3020 - Special Project is regarded as the capstone course of the BSc in Electrical and Computer Engineering. It is a student-driven project that does not involve traditional course delivery and assessment (Department of Electrical and Computer Engineering, 2008). This course has an average enrolment of eighty (80) students, who are supervised by approximately fifteen (15) lecturers.

ECNG 3020 commands significant resources, administrative time and effort. Faculty may each supervise as many as ten (10) independent student projects. For students, ECNG 3020 is arguably the most critical and demanding course as it is a year-long, high-stakes assessment that counts for six (6) credits and contributes 20% of the final weighted average used to determine the class of degree awarded.

Morgan (2003) defines a Course Management System (CMS) as a “software system that is specifically designed and marketed for faculty and students to use in teaching and learning”. The ECNG 3020 Portal is primarily an administrative tool used to streamline and execute course processes. Atypical course needs which are not part of existing CMSs, such as WebCT and Moodle, prompted the development of a customised CMS. According to Morgan (2003) most CMSs facilitate teaching and learning activities, such as sharing course resources (lecture notes, readings etc) and administering assessments (online assignments, quizzes and teacher feedback) – these are not altogether useful to ECNG 3020 as the course requires the production of an independent, out-of-class study; the teaching and learning elements are highly idiosyncratic and are largely shaped and facilitated by the student-supervisor relationship. The Special Project Portal was developed, by the authors of this paper, using open source software, to address various course specific requirements. The Portal serves as: 1) a central hub for information and communication, 2) an administrative and process management platform and 3) an information sharing tool.

Simplicity and usability were guiding principles in the Portal’s design; keeping in mind that undue complexity could alienate users (Halloran, 2001). The Portal thus presents a very gentle learning curve. Moreover, it makes various course processes easier for all parties – the course coordinator, examiners and students. It has been developed incrementally, as functionality was implemented in parallel with the needs of the actual course delivery, during the 2008/2009 academic year.

Using insiders’ knowledge, this paper describes processes unique to ECNG 3020 which catalysed the development of the Portal. The Portal’s tools and provisions, the course web-portal design and challenges faced during the development are described. Evidence of usability, gleaned from two surveys, is presented. We explore the advantages and disadvantages of developing a customised course management system. Finally, future plans are shared as it is intended that with subsequent ECNG 3020 offerings, the Portal will be enhanced and improved.

SERVING A COMMUNITY OF USERS

A significant suite of provisions serve the course coordinator. These processes include (1) reviewing and publishing project proposals, (2) assigning projects to students, (3) scheduling presentations, (4) generating various course related documents, (5) sharing course information and (6) archiving data generated during a particular course offering.

For course participants the Portal allows them (1) ready access to course information, (2) access to published project proposals, (3) project proposal tools and (4) project selection options.

Project supervisors use the Portal (1) to draft, revise, submit and peer-review project proposals, (2) archive past proposals, (3) assign projects to students and (4) access course information.

ECNG 3020 PROCESSES AND PORTAL DEVELOPMENT

In simple terms, any offering of ECNG 3020 involves 8 major processes (refer to Figure 1). ECNG 3020 was initially coordinated using hardcopy forms exchanged amongst the coordinator, faculty and students. This manual, paper-based system was difficult to handle with problems related to missing forms, and long delays in the distribution and exchange of information. Subsequently, an electronic-based system was created using a combination of independent, static web pages and a standalone database administered by the coordinator. This system solved some of the problems in terms of broadcasting course information and collating some course data. However, the lack of communication between the database and the web pages made for difficult handling and required tedious, repetitive work to update the information in these two major components.

Figure 1: Course Life Cycle.

The Portal has been designed as a system of linked, dynamic pages and forms that can interact with users and a database that collects, stores and manages course information.

The Portal was developed using the software prototyping model (as illustrated in Figure 2). Functionality was implemented fairly quickly and then iteratively refined until it performed satisfactorily. This model allows a prototype to be developed rapidly, enabling users to assess the relevance and usefulness at an early stage, well in-advance of significant investment in the development of a system that does not perform desirably (Alavi 1984).

Figure 2: Software Prototyping Model.

The Portal was implemented using free, open-source software. The database component was implemented using the MySQL1 database management system. PHP2 server-side scripts and JavaScript client-side scripts were used to effect portal functionality. The Portal was deployed on the Faculty of Engineering’s server, running the FreeBSD3 operating system and the Apache4 web server.

Creation and Publication of Project Proposals

Each course offering requires new project proposals - faculty and final year students can propose projects. A standard form specifies required information for a comprehensive proposal. Typically, 6 - 8 project proposals are required from each supervisor resulting in 90 - 120 project proposals per academic year.

One of the most valuable tools in the Portal is the centralized system to create, store, review and publish the proposals. Faculty can draft proposals and continuously review these using a simple editing tool embedded in the Portal (refer to Figure 3). A proposal is submitted via the Portal, to the coordinator who takes it through the review process. The WYSIWYG5 functionality of the project proposal creation and editing tool was implemented using the TinyMCE6 JavaScript library.

Figure 3: Project proposal creation and editing.

Approval of Project Proposals

All proposals must be approved before publishing. This ensures that proposals are of acceptable academic quality, sufficiently challenging and achievable over two semesters. A review process, undertaken by the Department’s thematic groups, evaluates, and approves or suggests changes to proposals. Once a project is approved the coordinator indicates the change of status (as shown in Figure 4).

Figure 4: Project proposal approval.

Publishing of Approved Project List

Following the approval of proposals, the project list is dynamically generated and therefore automatically kept up to date and links to the full details of each project.

Assignment of Projects

At the beginning of semester one, students can consult faculty on project proposals. At this stage, supervisors can assign their own projects to students. The lecturer simply selects the student from a list (as illustrated in Figure 5). The automatic updating of the projects’ status is critical to informing students about those projects that remain unassigned and hence available. A record is kept of assignment details – who assigned the project, and the time of assignment; this log is useful for auditing purposes.

Figure 5: Project assignment.

Bidding for Projects

After the project assignment stage, students who have not yet secured a project can bid for the unassigned projects by selecting up to 4 projects (refer to Figure 6). The coordinator, in consultation with faculty, makes a final decision on the assignment of projects.

Figure 6: Project bidding.

Assigned Project List

After all students have been assigned, a list based on the project assignments is automatically generated and published.

Progress and Final Presentations

Student presentations are held at two instances. The first is a progress presentation in January and the second is the final presentation in April. Four (4) parallel sessions are hosted over two (2) to four (4) days, depending on course enrolment. ECNG 3020 presentations are evaluated by a panel consisting of the project supervisor, a second examiner and a moderator. Scheduling is a demanding task given the limited number of faculty and large student enrolment.

A scheduling tool, using drag and drop functionality (as shown in Figure 7) allows students, and examiners to be assigned to configurable time slots, hosted in four (4) rooms. Schedules by examiner, room and day are automatically generated and shared. The drag and drop functionality was implemented using the Prototype JavaScript framework and the Scriptaculous8 JavaScript library.

Figure 7: Presentation scheduling tool.

USER RECEPTION AND FEEDBACK

Davis (1989, 1993) identified perceived usefulness and perceived ease of use as fundamental determinants of user acceptance of information technology systems. Abbitt (2006) later identified that two major factors of user acceptance of a custom-made course management system were ease of navigation and visual perception. Thus the study’s survey instruments aimed to test these. Using a Likert Scale, users rated the Portal’s usefulness for accessing information and its navigability. Faculty also assessed the usefulness of various tools, specific to their functions. In addition to close-ended questions, users provided qualitative feedback. In total, 59 persons, or 88% of the entire community of users was polled.

To the credit of the Portal, the large majority of those polled, or 88%, found it a useful hub for accessing course related information (see Figure 8).

Figure 8: Responses to “The Portal was a useful resource for accessing information on ECNG 3020”

Most users, that is 90%, judged the Portal easy to use and navigate. Significantly, more than half or 54% of the sample strongly agreed that the Portal could be navigated and used easily (see Figure 9).

Figure 9: Responses to Statement “Portal was easy to use and navigate”

One objective of the Portal is improved access to information. Students were polled on how well they were able to view available project proposals. This information is an indicator of fair treatment in a process that involves great competition, as students do vie for projects. Most students, over four-fifths of the sample, felt that they were able to easily view projects (see Figure 10). This is significant, since as projects are assigned, the updated list of available projects can be accessed in real-time allowing for informed decision-making.

Figure 10: Responses to the statement “The Portal allowed for easy viewing of available projects”

Of those faculty members polled, many felt that the tools that allowed for creating proposals, managing proposals and assigning projects were the most useful. Two (2) faculty members disagreed that the Portal’s proposal drafting and editing facility was simple to use. In one instance the lecturer indicated that this facility proved challenging to the first time user. And in the second instance, that person experienced difficulty in navigating various versions of proposals, as multiple copies were created through the automatic save feature.

In their qualitative feedback, four (4) faculty members were pleased that all course related information could be accessed from a central hub. In particular, one (1) lecturer felt that it was useful to browse other projects on offer. The coordinator expressed that this facility allows for easy, convenient peer review of projects – a key quality control measure.

The coordinator selected the scheduling feature as most useful since it significantly reduced effort in the generation of several sets of schedules and reduced human error.

CONCLUSION

After the first cycle of use, the Portal is under extensive review. Further development of the Portal will be guided by two principles - genuine simplification of processes and user-friendliness. While the Portal allows a schedule to be created, it does not permit editing. Schedule changes are done manually by directly updating the Portal’s database. The inclusion of schedule editing will allow for changes without involving the software developer, allowing the coordinator to be more self-sufficient. An obvious improvement of the scheduling provision is the automatic detection of scheduling conflicts. Additionally, while students compulsorily upload their reports for vetting by a plagiarism checker, this screening is done manually. It would significantly reduce human effort if the checking were done automatically. Provisions for student-teacher interface, through discussion boards and file-sharing tools, have been suggested by two (2) members of faculty. This possible inclusion of groupware is receiving the consideration of the Department.

A custom-made course management system requires a wide array of resources, chief being a dedicated software developer. Our department has a clear advantage, as our core business involves this precise type of research and development. The Portal demonstrates the department’s ability to maximise available resources to solve local problems. As added advantage, the Portal testifies to our capacity to design and build software products.

A customized course management system as opposed to a commercial or open source one was preferred. It may be argued that open source course management systems can also be customized to suit user-needs. However, this requires a thorough understanding of the organization and operation of the various sub-systems and the technical competence to implement these changes with a consistent look and feel that does not adversely affect other parts of the system.

The most significant advantage offered by a custom-built system is user-targeted functionality. It directly addresses required features without unwanted facilities. Secondly, new system functionality can be rapidly introduced since the system internals are already familiar and well understood. Existing functionality can be iteratively refined and enhanced as the system is used and new requirements or unforeseen issues arise. Of value to organisations, like ours that are often financially constrained, is the use of free, open source software which results in lower system costs as compared to the cost of commercial systems.

The Portal has significantly improved the management of this year-long course. It is a dedicated tool that has, by all indications, worked well in the short term. Its greater value, however, lies in its ability to serve the department in the long-term and it is this long-term service that justifies any initial outlay, both material and human.

What remains to be an area for further investigation is whether the Portal can be adapted to meet the needs of similar, terminal assessment courses like ECNG 3020. Within the Faculty of Engineering there are several programmes with final year projects which make similar demands. The Portal thus has the potential to improve the administration of courses that are extra-departmental, and perhaps even external to the University of the West Indies9.s Department’s final-year project

ENDNOTES

1 MySQL database management system http://www.mysql.com/.

2 PHP scripting language http://www.php.net/.

3 FreeBSD operating system http://www.freebsd.org/.

4 Apache web server http://httpd.apache.org/.

5 WYSIWYG is an acronym for “What You See Is What You Get”.

6 TinyMCE JavaScript WYSIWYG editor http://tinymce.moxiecode.com/.

7 Prototype JavaScript framework http://www.prototypejs.org/.

8 Scriptaculous JavaScript library http://script.aculo.us/.

9 At the time of writing the Portal has been co-opted by the Department of Mathematics and Computer Sciences, UWI, St. Augustine in the management of their Post-Graduate Programme. Also one member of faculty, from the Department of Civil Engineering, UWI, St. Augustine, who is quite familiar with the inner-workings of the Portal, having himself supervised several ECNG 3020 projects, has expressed an interest in using the Portal for the management of hi

Copyright for articles published in this journal is retained by the authors, with first publication rights granted to the journal.
By virtue of their appearance in this open access journal, articles are free to use, with proper attribution, in educational and other non-commercial settings.

Original article at: http://ijedict.dec.uwi.edu//viewarticle.php?id=866