INTRODUCTION
University portals are emerging all over the world. Portals have been perceived by many people as the technologies that are designed to enhance work and learning processes at university by making workflows simpler and information more readily available in a form in which it can be processed (Franklin, 2004). There are many benefits for having a portal in a university. First, the portal makes it easy for people to find university information targeted specifically at them. Instead of the user searching the Web for information, a person identifies himself or herself to the portal, and the portal brings all relevant information to that person. Secondly, the portal uses a single consistent Web-based front end to present information from a variety of back-end data sources. Although information about people is stored in many different databases at a university, the role of a portal is to put a consistent face to this information so that visitors do not have to deal with dozens of different Web interfaces to get their information. Usability is an important issue when designing the university portal. Principles from human computer interaction must be included in the design of portals. However, there are also other issues that must be considered when designing portals with low bandwidth for universities in countries such as Africa. This concerns accessibility by students to the Web portals using limited bandwidth. Students in these countries have only limited bandwidth to access the portals. The development of portals for universities in these countries must take this factor into account. This article describes the development and use of the portal for an online learning environment (OLE) at a large distance-education institution in Africa for students with limited bandwidth. We first present a brief overview of portal, its benefits, and what it is used for in universities. The next section describes the requirements and objectives of the portals for our university. This is followed by our conceptual framework, which we have developed for the implementation of our OLE portal. The article then argues for the importance of customized development for implementing OLE portal for universities that have special needs.
WHY PORTALS?
Organizations need to provide timely, relevant information to customers, employees, and partners anywhere in the world, to meet today’s business requirements. It is important that information does not get lost or become irrelevant and outdated. A good solution is to create and deliver highly relevant content on a portal.
Portals can be used to improve document management, communication and collaboration, information access and sharing, and assessment and reporting in education. They can be personalised for different types of users, such as student, teacher, parents, government agencies, and administrators. Relevant and pertinent information and services can be made available to users to enable them to be more effective and efficient in their learning tasks.
A portal is a gateway to the Web that allows organised information to the users through a single entry point. A good portal knows the individual using it and it changes with the individual. It acts as an individual’s personal assistant, ready to act on his or her behalf. According to Daigle and Cuocco (2002, p.10), there are there main types of portals:
• Vertical Portals: Provide access to avariety ofinforma-tion and services about a particular area of interest.
• Horizontal Portals: Are often referred to as megapor-tals. These portals target the entire Internet community, for example, Yahoo.com or Lycos.com are megaportals. These sites often contain search engines.
• University or Enterprise Portals: Can be either vertical—focusing on a specific application such as accounting or financial aid information, or horizontal—offering access to almost all the information that an individual within the university needs to carry out his or her function.
EDUCATIONAL PORTALS
Portals have become one of the most visible information technology (IT) issues in the commercial sectors as well as in higher education. Portals offer a number of channels including reports and documents needed for class assignments, calendars, administrative information such as grades and degree audits, campus news and events, reference materials, and so forth.
Portals offer the following benefits to students:
• Increased and easier communication with faculty members
• Online access to courses
• Access to communities of interest within university, such as clubs, sports, and community service opportunities
• Access to latest university news
• Increased lifelong learning opportunities
Other benefits for staff members include:
• Instant access to information for advising students
• Simplified course management tools
• Real-time communication with students
When designed properly, a portal can improve the activities required to facilitate, manage, and assess learning. A portal can help teachers and students to discover new learning content and to express ideas in more innovative ways. It can streamline workflow and automate manual tasks. Fundamental portal capabilities include content aggregation, application integration, user authentication, personalisation, search, collaboration, Web content management, workflow and analysis, and reporting (Connect, 2004).
Typically, university portals can be grouped into institutional portals and subject-based portals (Franklin, 2004). The institutional portal provides its users with a wide range of services, integrating these through a common interface regardless of whether particular services are provided by the institution or not. An institutional portal contains information about the user, enabling it to customise itself and be customised to the individual’s interests and responsibilities. A subject-based portal brings together a variety of information sources and tools about a common theme, but is unlikely to have much information about the user.
WHY ARE UNIVERSITIES IMPLEMENTING PORTALS?
Englert (2003) gives the following reasons to why universities are implementing portals. These are to:
• Integrate/streamline information and services.
• Improve service to students/staff.
• Offer personalised/customised/targeted service.
• Improve administration efficiency.
• Attract students.
• Enhance university image/raise profile.
• Engage/connect/build community.
• Offer distance/flexible learning.
DIFFERENT METHODS OF DEVELOPING PORTALS IN UNIVERSITIES
University portals can be developed in several ways. Each has its own advantages and disadvantages. The most straightforward option is to work with one of the university’s existing suppliers that has a portal offering. Another option is to acquire a portal from a specialist vendor. A third option is to develop the portal in-house. The main benefit of this approach is the complete control it offers. Universities that plan to develop their portals in-house now have the opportunity to base their development on open-source products. This helps to speed up development time and reduce the cost.
In this article, we describe a case study of a university where the students are geographically distributed throughout the country. These students are taking distance-learning courses in different subjects. Broadband services in this area are very expensive for the home user, with less than 10% of the total Internet population having access to DSL services. The average student therefore makes use of a 56K connection. The design of an online learning environment (OLE) portal must take this into consideration. This was also our main reason for developing our OLE portal in-house, in order to customise the portal to our special requirements. Also, while an official student portal system is in place at this particular university, it simply did not cater to our faculty needs
A FRAMEWORK FOR THE DESIGN OF A LOW BANDWIDTH PORTAL
components of an OLE portal
There are three main components to portals, as shown in Figure 1. These are administration, content, and technology components.
The administration component supports students in their academic pursuits and teachers in their teaching. It:
• manages noninstructional content (e.g., due dates, course/module information, notice boards, forums, etc.);
• manages the learning object repository (LOR), which contains the distinct learning objects used to construct course modules;
Figure 1. Content, administration, and technology components interaction in an OLE
• gathers information about the intended audience from the portal system (PS) in order to develop appropriate learning objects; and
• defines flags to import relevant PS information into the OLE (e.g., flag modules to import staff and student information, etc.).
The functionality the administration system (AS) offers is of critical importance, since staff acceptance is a major deterrent to online efforts. Acceptance and use of the AS by staff is not only dependent on the extent to which it is perceived to be useful, but also on the extent to which it does not add to existing workload. It therefore makes sense to have an AS that, where possible, taps into existing departmental and institution workflow models, thereby decreasing the input required. For example, if staff, in their normal duties, are required to make backups of static learning material to a central repository, it makes sense to tap into this backup upload procedure and simultaneously direct material to the OLE, thereby not only reducing staff load, but also supporting them into contributing to the OLE.
The content component requires that any learning component introduced into an OLE must be pedagogically meaningful. Pedagogical issues that currently challenge professionals are learning approaches, teaching methods, and students’ expectations and experiences with instructional activities. Pedagogical intervention is required in the dynamic interactions that exist between student and course content, student and teacher (and/or facilitator), and student and peers, and also in the interaction between student and technological tools employed in the OLE. Besides varying computer and Web skills, learners have different learning styles, needs for different content depths, and even different attention spans. These considerations are complicated by different pedagogical requirements for discrete modules, and exact and pliable learning models can only be refined and defined after considerable online experimentation and continuous evaluation of the technologies employed, the learning model and content, the learner and the learning object repository (LOR). This implies that a portal is a constant work in progress, and is in continually growing in size and complexity, as graphically depicted in Figure 2.
Figure 2 reflects (the first) three hypothetical phases of development of an OLE. In phase 1, based upon the available technology, a particular learning model and content is proposed and implemented into the OLE. After a sustained period of evaluation of the technology employed, the interaction between learner and OLE (the learning model and content) is revised, and a second phase is initiated that results in a restructured (and thus evolved) OLE.
It is an iterative process that is primarily driven by decisions to implement pedagogically meaningful content dictated. Since each step adds to the one before, the existing structure must lend itself to extension, supporting the need for an open-source software (OSS) and open-systems approach to developing an OLE.
Figure 2. A simplified development model for an evolving OLE
The technology component concerns the proper choice and use of technological tools (hardware and software) required to support and enable the evolution of both the learning model and the OLE. It includes decisions about the architecture, platform(s), and legacy systems that will form part of the OLE, as well as the scripting, database, Internet communication, and operating software technologies best suited to an open systems evolutionary approach. Objective criteria for selection include maturity of standard (reliability, availability, stability, acceptance, support, etc.), appropriateness (fit, costs, manageability, etc.), and ease of deployment, including extensibility of software technologies, in particular, to allow for emerging e-learning technologies.
Three collections of enabling technologies are employed in any OLE. These are technologies for teaching (TfT), technologies for learning (TfL), and technologies for administration (TfA). TfA and TfT are used by faculty for input into the OLE, while TfL is utilized by the learner and allows him/her to partake in the OLE.
At any given time, within each collection, the level of implementation of technologies is subjected to constraints that influence the type of learning model that can be employed. Once the level of implementation of any collection of technologies surpasses the level required by the current learning model and/or allowed by the constraints, OLE development continues to the next phase.
The required levels for collections of technologies within a particular learning model are not necessarily equal, neither fixed. Depending on the phase of implementation of the OLE, the collections may or may not be sufficient to support the learning model envisaged, in which case, the learning model must be reconceptualized.
Our Framework
For our low-bandwidth OLE framework, the administrative and content components are presented as tiers. In order to provide specific examples of applications used in the OLE and the type of interface offered, services and interface tiers have been added to the framework. The technology component is used to portray enablement over time in a four-stage evolving OLE. Figure 3 depicts the framework.
The framework is described in terms of the following general observations:
• The existence or absence of enabling technologies determines the stage of implementation of the OLE.
• While the OLE evolves horizontally from stage 1 to 4, the stages are not vertically inclusive. For example, depending on TfL, TfA, and TfT levels employed, the OLE may be rooted in stages 4 and 2 in terms of the Interface and Services tiers, but in stages 3 and 2 with respect to the Content and Administrative tiers.
• The OLE does not end with stage 4, but is open-ended to accommodate future technological developments.
Figure 3. A framework to implement an open software workflow in an Internet learning and teaching environment
• Each stage incorporates components from a previous stage, if required.
IMPLEMENTATION EXAMPLES
We hold two beliefs concerning our OLE experimentation. The first is the principle of technology mastering, a term coined by Kostopolous (1998, pp. 257-265). In the absence of established learning models, it makes more sense to follow a nonproprietary and evolutionary approach to the development of an OLE. In other words, until such time as there is conceptual coherence of online instruction paradigms, and until all or most of the constraints currently impacting on OLE’s are removed, it makes sense to explore and experiment withvarious scripting, database, Internet communication, and operating software technologies, tools for online learning, in an effort to find a customized solution that fits a faculties current and future OLE requirements.
Our second belief is also ascribed to Kostopoulus (1998, pp. 257-265). He refers to it as the “last mile” problem. Many Web-based courses are “dead-on-arrival,” that is, learners never get started because they cannot meet the technical requirements for the course (Horton, 2000). In some instances students cannot afford the required technologies, while in others they simply cannot figure out how to download, install, or get the required software and hardware up and running, which may add to faculty workload in terms of support. A moral dilemma is also created when some learners are excluded from elements of the OLE because of constraints, especially if no formal policy on the use of an OLE exists. The principle of technological minimalism thus dictates the OLE developers team have to consider the lowest level of technology to which each student has access to when decisions are made about the minimum technological requirements needed for course delivery and access. It is well worth to keep in mind that the more technological features a course requires to be presented, the more expensive and complex the technology required to produce these features, and the greater the limitation on student access is. Figure 4 shows a screen shot of the student interface Web page with panels and respective content generated from the database and personalized for a hypothetical student registered for five modules.
Any panel can be minimized, maximized, or closed, depending on the preferences of the student. Here, the departmental Notice Board has been minimized. A panel that is minimized does not load data, of course. It follows that a student has total control over which panels are loaded and hence, about the amount of data that is loaded. A student with access to higher bandwidth may choose to load all panels, while students with lower bandwidth may choose to minimize or even close panels. The page currently loads very quickly with all panels open, regardless the connection speeds. But the value of such a design in an evolving low-bandwidth OLE portal is obvious.
CONCLUSION
In this article we have described the main components of a low-bandwidth OLE. We presented a framework that can be used by course planners and designers to plan, develop, and implement an interactive and dynamic online learning environment. We have argued that development of an OLE is best supported by an open system, evolutionary approach. Besides obvious economic arguments, we regard OSS as the appropriate “glue,” not only because of its sustainable, dynamic, and responsive nature, but also since it allows one to devise workflow models appropriate to the requirements of an OLE and faculty.
Figure 4. A screen shot the OLE portal. Personalized and customized home page generated with PHP from the faculty MySQL database (centre panel compressed to fit).
We have shown how OSS and open systems can be used to design an efficient and easily maintainable Web platform that serves as interaction between the student, his study material, and his lecturers, by building a dynamic OLE that is easily administrable, yet powerful and scalable enough to allow for the future inclusion of complex interactions and even new technologies. When higher levels of interaction become attainable, the development platform is expected to fulfill whatever needs and requirements exist at that time, be it in the provision of applications to support interactive learning, or in the delivery process.
Both staff and students have responded well to our efforts, mainly because applications are designed around them and take cognizance of staff workloads and student needs. As it can be seen, OSS supports an open systems approach that, as demonstrated, allows greater leverage for customized OLEs.
KEY TERMS
Bandwidth: The amount of data that can be transmitted in a fixed amount of time.
Horizontal Portals: Often referred to as megaportals. These portals target the entire Internet community, for example, Yahoo.com or Lycos.com are megaportals. These sites often contain search engines.
Human-Computer Interaction (HCI): A discipline concerned with the design, evaluation, and implementation of interactive computing systems for human use.
Online Learning Environment (OLE): The use of the Internet for learning via coursework or information posted on the Web, electronic communication, and other instructional activities.
Open Source Software: Software for which the underlying programming code is available to the users so that they may read it, make changes to it, and build new versions of the software incorporating their changes
Usability: A quality attribute that assesses how easy it is to use the interface. It often refers to methods for improving ease of use during the design process.
Vertical Portals: Provide access to a variety of information and services about a particular area of interest.
