My University Portals FAQ V1.0
Last Updated: Wednesday, 13-Feb-2002 16:11:23 CST
About This FAQ
This FAQ was developed from notes taken by Kevin Lowey at the "Portal
Technology Symposium" held in San Diego California on July 11-13, 2000
(see http://www.convergemag.com/PortalTech/). Information
about the "uPortal" project was obtained at the 2nd JA-SIG
conference held on July 10-11, 2000 in Monteray California (see http://www.ja-sig.org/events/jul00/).
Additional comments were provided by the members of the UWEBD mailing
list.
The FAQ is divided up into 5 sections:
Section 1: What is a My University
Portal?
-
This section defines what a My University Portal is, and what makes it
different from ordinary web sites.
Section 2: What does a My University
Portal
look like?
-
This describes in more detail the experience of using a My University
Portal. It also provides pointers to University Portals you can visit on
the web, as well as generic Industry portals like My Netscape or My Yahoo.
Section 3: Pros and Cons of a My
University
Portal
-
This section outlines the benefits to individuals and universities of
having a My University portal. It also points out the problems and common
mistakes made in implementing the portal.
Section 4: Building a My University
Portal
-
This section discusses how to go about implementing a portal. It lists the
various options available, and the pros and cons of each option.
Section 5: Other Resources
- This lists other places to look for information about portals in
general, and University portals in particular.
Section 1: What is a My University Portal?
What is the definition of a "My University Portal"?
The term "portal" is so overused as to be meaningless. It has gotten
so bad that many places build a portal simply by putting the word "portal"
on their normal web pages. We need a better definition.
This FAQ defines a "My University Portal" as the
following:
A one-stop client-oriented web site that
personalizes the portal's tools and information to the
specific needs and characteristics of the person visiting the site,
using information from university databases.
What are the goals of a My University Portal
Make it easy for people to find University information targeted
specifically at them. Instead of hunting the web for information, a
person identifies himself to the portal, and the portal brings all
relevant information to the person.
Use a single consistent web-based front end to present
information from a variety of back-end data sources. Information about
people is stored in many different databases at a University. This
includes student information, employee information, course information,
alumni information, library information, parking information, calendaring
and scheduling software, and so on. The role of a portal is to put a
consistent "face" to this information so that visitors don't have to deal
with dozens of different web interfaces to get their information.
How is a Portal different from a normal web site?
In a normal University web site, the information is out there, but it is
up to the visitor to find it. They have to either use a search engine, or
navigate the links on the University's web page. Often people miss
information they couldn't find.
In a "My University Portal", the visitor identifies himself to the
portal. The portal then uses the detailed knowledge the University has
about this person to gather together all the information relevant to
that person and display it in one place. This information could be
generic publically accessible information, or it could be confidential
information specific to that individual (like course grades or
payroll information).
The emphasis has shifted from a public web site showing on-line pamphlets
to a user-oriented web site that provides tools, reports, and services
specifically designed for that individual.
Ok, So a portal is just a collection of bookmarks right?
Well, not exactly. Bookmarks let people quickly get to information they've
already found, but they do nothing to help people find this information.
A My University Portal finds the information for the
person so she doesn't have to go looking for it.
Also, a person doesn't know if a bookmark has changed unless she chooses
to check the bookmark regularly. A My University Portal
displays all the content in one place. If the "news headlines" information
changes, this change is displayed on the portal page immediately. The
visitor doesn't have to check the news headlines bookmark before becoming
aware of the change.
Finally, bookmarked web-services provided by different departments have a
different look and feel to them. They all work differently, require
separate logins to access the information, etc. A portal uses a consistent
framework for presenting the information in a standard way. Usually one
login gets access to all the services, and these services are all designed
to fit within a standard portal framework. This consistancy makes it
easier to learn and use these services.
Will a My University Portal replace a normal University web site?
No. The focus of a My Univeristy portal is to provide information
targeted at individuals. The focus of a general web site is to show
general on-line pamphlets to wide audiences. The two systems are
different, but compliment each other. Neither is a replacement for the
other.
What are the key characteristics of a My University Portal
A My University Portal consists of a number of features.
- Personalization:
-
The key word in "My University Portal" is "MY". The main purpose of a
portal is to provide information that is personalized for each visitor.
The portal should adapt as a person's roles change on campus, and provide
information relevant to these new roles.
For example:
Prospective students might get information hilighting the
programs offered, housing information, student loan information, etc.
Registered students would get information about the classes they are
registered in, automatic updates in their personal calendar about
assignment deadlines or final exam schedules, current status of
library sign-outs or books put on reserve for them, lists of required
textbooks for their courses, etc.
Alumni would have information about alumni reunions added to their
calendar, information about alumni groups in their city, etc.
- Customization:
-
The portal is a tool for the individual, not the University. The
individual must have complete control over the information presented
within the portal. This includes:
-
Control over what information is and is not not displayed on
their portal pages. This is done using "information channels", small bits
of information designed to be included in larger web pages. The system
controls what channels people are allowed access to, but the individuals
decide which of these channels they'll actually use in their portal.
-
Control over the content within the information channels (for example,
what cities to show weather for).
Control over how the information is displayed. For each channel, do
they want the full text, a quick summary, or just the title line? Should
the information be on the starting page for the portal, or a secondary
page? What column should the channel be displayed in?
Control over the preferred output device. Some people may want to access
their information through a normal web page. Others may want to access the
information (or a subset of the information like today's calendar) through
wireless devices like web enabled cell phones or personal assistant
devices. Others may require specialized output device support (for
example, people who are blind may require support for braille readers).
Control over the appearance of their portal. Many portals allow
visitors
to use different "skins" to change colour schemes, decorative graphics,
and other characteristics about how the information is layed out on their
screen. This is often combined with accessibility issues (like using only
one column for devices with small screens or larger text fonts for people
who are blind).
- Standardization
-
A My University Portal needs to have a consistent user front-end to a
variety of behind-the-scenes tools for the individual. As a minimum this
should include web-based e-mail, and a personalized calendar. Optional
tools could include chat rooms for groups like students in a class,
on-line file-storage, tools to build and maintain personal web pages, etc.
- Enable the Individual
-
The My University Portal is a tool for the individual. As such, all tools
and services should be there to help enable the individual as much as
possible. This includes tools to help individuals to provide their own
content to the portals. For example, a group of students working on a
class project should be able to quickly set up a private chat-room for
those students. Individuals should be able to set up public calendars
everyone can update and view, as well as private calendars, etc.
- Single Login
-
When a person visits a portal, they should only have to identify
themselves once. They shouldn't have to remember many different usernames
and passwords to get at the information within the portal.
Section 2: What does a My University Portal Look Like?
What does it look like to a visitor?
Here's an example of how someone will use a My University Portal:
The visitor clicks on a "My University" button from the main
University home page.
The "My University Portal" asks for a username and a password to
identify who the visitor is. (Alternately it may provide a starting page
with generic information, and ask people to log in from there for
personalized information).
-
The visitor sees a web page consisting of a page heading, an option for
configuring the system, and a collection of "Information Channels"
containing information and tools from various sources. Sometimes these
channels are grouped together in system-defined or user-defined "tabs",
such as "My Studies", "My Employment", "My Recreation", "My Projects",
etc. People have the option of subscribing to or unsubscribing from
channels available to them. They are not forced to view all channels.
Types of Information Channels include:
Off-Campus Channels such as news headlines, or weather
reports. These would be provided by off-campus organizations, but since
they utilize channel definition standards they can be included in the
University portal.
Public on-campus channels such as the latest University
press
releases. These would be channels created by the University, but available
to anyone who wants them. They would utilize channel definition standards
which allows them to be utilized in other off-campus portals as well.
Private channels targeted only at this specific
individual. This would include employment or student records, exam
information, notes from a professor to a class, etc.
Custom tools designed for use within the portal. This would
include web-based e-mail, a calendaring system, communication tools like
chat rooms or bulletin boards, etc.
The available channels would be different for each individual. Students
would have different channels than staff members. People in the Ballroom
Dance Club would have access to the Ballroom Dance Club Member Channel.
No two people would have exactly the same channels available to choose
from.
-
Each channel can have standard controls to close (unsubscribe
from) the
channel, open the channel in a separate window, minimize the channel to
just the channel heading, or customize the channel (for example, specify
which cities to display weather information for).
The customization option allows people to select which channels they want
to view, set display characteristics such as number of columns, preferred
output device (like web page, wireless portable device, braille reader),
colour schemes, etc.
Where are example University Portals we can look at?
The best way to see how a portal works is to visit one that's already
in
action. Many universities are currently using or developing
portals. Some of these are listed below:
Where are some example portals from other industries?
Portals are being used quite successfully in industry. This includes
vertical market portals (for example, a portal that helps to link product
suppliers with product retail outlets) as well as generic entry-level
portals (such as My Netscape or My Yahoo).
A few examples are listed below which demonstrate quite nicely what a
portal can look like. However, remember these portals don't include
features specific to a University environment which makes a My University
Portal so useful.
Section 3: Pros and Cons of a My University Portal
What's in it for a User?
A well-implemented My University Portal can offer a number of benefits to
a user of the system.
-
One place to get information. The visitor no longer has to search
for the information, the information finds him.
-
A standard set of tools. Visitors get a set of tools like web-based
e-mail and calendaring software that follows them through their entire
time at the University. They don't have to use one tool for one class,
another tool for their work, etc. Also, since these tools all work within
the portal framework, they all have a consistent look and feel and work
similarly, reducing learning time.
-
Global access to their information. The only thing required to
access the portal and associated tools is a web browser. There's no need
to configure e-mail programs, etc. A person can be anywhere in the world
(such as away at a conference) and still get at the information they need.
-
Personalized and Customized information.
The information available in a portal is personalized for each
individual. In addition, this person can then customize this information
further to suit his or her individual tastes. A portal puts control of
their web experience in the hands of the people using the web, not
the people building the web sites.
What's in it for the University?
A well-implemented My University Portal can offer a number of benefits to
a University.
Promote a life-long connection with the University. A properly
designed portal will follow a person from being a prospective student, all
the way to alumni. From a new employee, to a retired employee. If the
service provided by a My University Portal is of good quality, people will
continue using it, thus fostering a lifelong connection to the University.
This then benefits the University in the form of donations, children or
siblings of alumni becoming students, etc.
-
Attract new students to the University. An important pool of
new students consists of the children of alumni, or younger siblings of
existing students. Providing services for these people on a University
portal helps to cement their relationship with the University even before
they become an official part of the University. This in turn attracts them
to our University.
-
Standardization of Web Services. The portal, through use of
standards for defining how information gets into channels, can help in the
standardization of web-based services on a campus. Developers wouldn't
have to re-invent the user interface each time. Instead, they can
concentrate on the back-end database integration, and utilize the existing
portal for the user interface.
-
Promotion of data sharing between departments.
Many Universities run into the problem of "data silos", where data is seen
as being owned by individual departments, instead of as a campus-wide
resource. The portal may act as a catalyst for breaking down these silos
and making the data available in a controlled way to the people who need
to use it. The mechanisms used to build portal channels can provide
controlled access to data for people who need it, while still leaving
control of that data in the hands of the people responsible for its
accuracy.
What problems do Universities have to overcome?
Who owns the data?
A successful portal must have access to most of the databases on a
campus, in order to identify who a person is, and what information that
person should have access to. It also needs the ability to query
information on behalf of this individual and display it in that person's
portal.
Many Universities have the idea that the student database belongs to
the Office of the Registrar, the employee database belongs to the Human
Resources Division, etc. A portal demonstrates that these databases must
be seen as institutional databases, not department databases, and ways to
access this data from outside the hosting department must be developed. If
this isn't done, then a portal will fail.
Buy-in by Channel Developers:
A portal is only as good as the tools and information channels it
provides. If the portal only provides generic information like weather and
national news headlines, then people will use established sites like My
Netscape. A successful My University Portal must have tools available to
let novices easily populate the information channels (things like
web-forms for creating news headlines for every department on campus).
A My University Portal also must have access to information specifically
about this individual. This implies that you must have buy-in from the
library (for library patron records), the Registrar (for student and class
information), the Human Resources office (for employee, department
memberships, and union memberships), campus clubs (for club memberships
and channels for those clubs), faculty members (information channels
for their classes or research groups), etc.
A portal is not something that one department can do on its own. The
portal must be a University-wide project with participation from all the
stakeholders.
Competition with other internal University portals:
The biggest threat to a successful "My University" portal is when each
department decides it would be better to have a portal of their own,
ending up with a "My Alumni Office", "My Library", "My Computer Lab", "My
Classes", etc.
An important feature of a portal is that individuals only need to visit
one place to access all web-tools relevant to them. An individual doesn't
want to go to "My Library" then to "My Computer Lab", then to "My
Classes", and divide their time up looking in ten different "department
portals". They want one central place with all their tools.
Usually individual departments don't offer enough information on their own
to keep people coming back day after day. That is why most "my library" or
"my alumni" pages are doomed to fail. People look at it once or twice, but
don't find enough to keep them coming back so the department portal dies
out.
If departments instead focus on developing channels for a well-designed
central My University portal, then everyone benefits. A person may not
find it worthwhile to keep checking the Library portal every day, but if
the information on that is combined with the Alumni information, and the
course information, and the computer lab information, and their department
information, and their employee information, then the whole package
becomes more attractive and keeps people coming back.
Single login
A portal requires a way for people to identify themselves so the system
can decide what tools they are allowed to use. This implies a single
standard login name for each individual using the portal. A person can be
at the same time an alumni, a student, and a staff member. We don't want
separate logins for each of these roles. We want one login name for that
person that follows the person through all their dealings with the
University.
We also want to avoid forcing people to log in several times for
different tools. Once they are in the portal, they should be able to
access all the tools without logging in again. Sometimes this isn't
technically possible, but it should be the goal.
Identification of roles
Once a person identifies himself to the portal, the portal must determine
what tools and information this person should and should not have access
to. There needs to be a way to accurately take the person's login name,
and tie that to his student records, employment records, alumni records,
club membership records, etc. This can be very difficult in most
universities, where information about individuals is stored in several
different and incompatible databases with no cross references between
them.
Integration with existing mail or other tools.
It would be best if all the tools are designed to work with the portal.
For example, once you log into a portal, you should get access to your
e-mail without logging in again. Similarly, you may have a channel in the
portal which lists the headings of unread e-mail, with a button to go into
the e-mail application to read all the mail.
Right now a compromise is usually made, where a portal has a button to
access a separate e-mail or calendaring program. However, the tighter this
can be integrated with the portal, the better it is for the individual.
Can a University have more than one portal?
The purpose of a portal is to have one place that brings all the
information relevant to an individual together. You cannot do that if the
information is fragmented between "My Library", "My Alumni Page", "My
Business Office", "My Student Services" etc.
A portal is a tool for an individual, to help that individual manage the
information provided to him by all departments in a University. Portals
are not tools for departments. Thus the whole concept of a "My Library" or
"My Alumni Page" is flawed, because that's taking the emphasis off the
individual, and putting it on the department providing this limited
department-only portal.
Section 4: Building a My University Portal
What parts are there to a My University Portal software?
Software for a My University portal really consists of two parts:
- the "portal infrastructure" which displays the channels and manages
all the security, personalization, and customization.
- the "channel development tools" which builds content for the
information channels. Often this is custom developed software to convert
information entered in web-forms, or found in databases, into channels for
the portal infrastructure.
What is the "Portal Infrastructure"?
The portal infrastructure is responsible for the following:
- Identifying who is visiting the portal, usually through a unique
campus-wide username and password for each individual using the portal.
- Saving and loading configuration options for this individual. This
includes tools for letting individuals change these options. Example
configuration options include:
- what channels the person subscribes to,
- configuration settings for channels. For example, what cities to show
weather for, whether to show the full channel content, or just
headlines, what "personal bookmarks" to store for an individual, etc.
- appearance settings, such as prefered colour schemes or "skins", user
defined tabs for grouping channels together, preferred output device
(text-only, web, cell-phone, braille) etc.
- Deciding which information channels individuals are allowed to
view, and providing a way to let individuals subscribe to these
channels.
- Displaying the information channels according to the individual's
preferences.
What are the "Channel Development Tools"?
Channel Development Tools are used to build the content that goes into
the information channels. This can be done in a variety of ways, depending
upon the complexity of the information displayed in the channel:
- A web-based form could accept information from a person, and use that
information to build a simple information channel. For example, someone
could enter "Campus Press Releases" into a form, and the program would
then automatically build a channel containing the news headlines, a short
description, and a link to a web page with more details.
- A programmer could use defined guidelines to write a behind-the-scenes
script to query a database on behalf of the individual and come back
with information specific to that individual. For example, a program could
query a student information system and come back with information about
that student to display in the channel.
- Some channels may be made available from off-campus sources, such as
USA Today's news headlines. These use industry standards for defining
information channels using files downloadable off the Web. Adding ways to
easily use these industry-standard channels greatly enhances the
functionality of a My University Portal.
The key here is to realize that the channel content itself is separate
from the infrastructure that displays that content. Using standards to
define what channels should look like, then separating channel development
from channel presentation, allows anyone to easily develop information
channels without needing a central programmer to modify the Portal
software. This lets us easily add channels, as well as use channels
provided by off-campus sources.
What standards are there for defining channels?
Several standards have developed for defining information channels
within portals. Some of these standards are specifically designed for
Portals. Others were originally designed for other purposes, but can
be adapted for portal channels.
Many of these standards are based on XML. XML uses a syntax similar to
HTML to define data in a standard way that can be shared among different
computer systems. It's especially useful for transfering data between
computer programs over the Internet.
Resource Description Framework (RDF) Site Summary (RSS) files
RDF Site Summary Files were developed by Netscape corporation for their
"My Netscape" portal. It is an XML standard used for defining the channels
used in the My Netscape portal.
More details can be found at these web sites:
Open Content Syndication Directory Format
The Open Content Syndication (OCS) is an XML application designed to
enable channel listings to be constructed for use by portal sites and
other applications. It lets a site easily share its public channels
with portals from other institutions. For more information, please refer
to the following sites.
Channel Definition Format (CDF) files
CDF files were developed by Microsoft Corporation to support their
"Active Channel" and "Active Desktop" technology, using the XML standard.
It also works very well for defining channels for portals. For more
information, refer to the following web sites:
HTML Files
Normal HTML documents can be used in a My University Portal. However, the
portal "channels" are supposed to be smaller components of a larger page.
Usually the HTML documents are not displayed directly within the channel.
Instead, the channel is usually an RSS file that contains a short
description of the web site and links that, when clicked on, open another
window containing the full web pages.
JAVA applets
Some portals support java applets within a channel. This allows the
channel to do complex tasks, from showing a clock, to displaying chat
rooms for students in a class, to listing a student loans calculator.
Wireless Markup Language (WML) Files
The Wireless Markup Language is an XML specification for communicating
with wireless devices like cell-phones, pagers, and personal assistants.
These devices have very limited display areas, just as a single channel in
a My University Portal has a limited display area. This could make WML a
useful way of building channels for a portal. The advantage here is that
you would also be ready to use these same channels in a wireless
environment.
More details on WML is available at http://www1.wapforum.org/tech/terms.asp?doc=WAP-191-WML-20000219-a.pdf. Information
on wireless device standards in general can be found at http://www.wapforum.org/.
XML-RPC (Remote Procedure Call)
XML-RPC is a specification and set of implementations that allow
software
running on disparate operating systems, running in different environments,
to make procedure calls over the Internet. It is remote procedure calling
using HTTP as the transport and XML as the encoding.
This may be useful as a way for a channel processor to interact with
programs on other servers to collect information to display in the
channel.
For more information, please refer to http://www.xmlrpc.com/.
SOAP (Simple Object Access Protocol)
From the W3C web site: "SOAP provides a simple and lightweight mechanism
for exchanging structured and typed information between peers in a
decentralized, distributed environment using XML". It allows a program on
one computer to request information on another computer (either data, or
the results of a remote procedure call) and have the results sent back.
In the context of a My University Portal, SOAP allows a portal channel
handler to make requests for confidential information from a back-end
database, then have the results sent back to the channel handler for
formating. It is very useful for querying dynamically changing data, such
as getting stock quotes from a stock server.
More details on SOAP is available from:
iCalendar Standard
The Internet Calendaring and Scheduling Core Object Specification at http://andrew2.andrew.cmu.edu/rfc/rfc2445.html
defines a way for calendars to exchange information. While not directly
applicable to portal channels, this standard may be very useful for a
"calendar channel" within the portal. It would provide a standard way for
external applications to update individual calendars. For example, using
this XML standard, the Office of the Registrar could update the course
schedules in individual student calendars over the Internet.
How does a University build a Portal?
Building a portal consists of two parts: Build the portal infrastructure
and channel development tools, and then build the channels used in the
portal. The infrastructure and channel development tools are relatively
easy to build. The difficult part is building the interfaces between the
back-end databases and the portal. This is where selecting portals that
support standard portal channel standards can save a lot of time and
effort.
There are various options for implementing a portal:
The first option is to build the portal infrastructure and channel
development tools from scratch.
A second option is to use "free source" for portals. This lets you
use source code developed by others to implement the portal
infrastructure quickly, but still allows you to customize the portal
software to meet your institution's unique needs.
A third option is to use commercial portal software. This is portal
software you purchase and install on your own computers.
-
A fourth option is to look at "Bundled Portals". This is where software
vendors include customization features and tools similar to features
offered in a portal, but bundled with their existing software.
A fifth option is to go to an "online community" site, where an external
web site provides a number of services for people at your institution,
including tools like calendars, e-mail, etc.
What should I consider when building a portal from scratch?
The advantage to building the portal yourself is you have full control
over the implementation of the portal. You do not need to rely on outside
companies or agencies.
The disadvantage to building the portal yourself is that this will take a
lot of time and money to do properly. Often, the time spent re-inventing
the wheel could be better spent in tailoring existing portal software to
your site and building content for the portal channels.
If you do decide to build your own portal software, remember to do the
following:
-
Keep the portal infrastructure separate from the portal content. You want
a portal that can easily add more channels without having to rewrite your
portal infrastructure software. The best option is a portal where people
simply fill in forms to build new channels, without bothering the central
programmers at all.
-
Use established standards for defining the portal channels. This allows
you to use premade tools for building channels, and also provides a good
way to plug additional channels into your portal in the future.
What "Free Source" portal software is available?
There are several portal projects which provide source code which you can
adapt to implement your own My University Portal. This gives you complete
control over the portal's features, but it is also the most time consuming
and expensive alternative.
Remember that "free source" does not mean a "free portal".
Usually the software is implemented up to a point, but you still have
to invest a lot of time in building the interfaces between the software
and your back-end databases, and tailoring the system to your
environment.
This portal project was developed by the Java in Administration Special
Interest Group (JA-SIG). The purpose of this group is to promote the use
of Java as a development language in University adminstrative computer
applications. The uPortal project was the first attempt to have the
members of this organization cooperate to develop a significant Java
application for members to share.
The software is written in Java. It is considered a "reference
implementation" and not a full production program yet. There are
significant features still missing, most importantly the concept of
different "roles" to control who can see what channels.
Jetspeed is another Java-based open-source portal project sponsored by the
Java Apache Project at http://java.apache.org/. This appears
to be much more mature than the uPortal project listed above, especially
in the area of supported standards for defining channels.
XML.COM has an article on Jetspeed at http://www.xml.com/print/2000/05/15/jetspeed/index.html
that describes it in more detail.
This is a portal project developed using the Perl programming language. It
was developed specifically to support Libraries. While not a full-featured
portal, it may be useful for providing some portal features to a general
University community. Source code is available after signing a licensing
document (see http://my.lib.ncsu.edu/about/ for
more technical details about the product).
What commercial portal software is available?
Some companies (usually database or online learning companies) sell their
own "portal" software. Either this software is installed on computers at
your institution, or the company provides a hosting service to implement a
portal specific to your institution on their computers.
These might provide a more mature portal product. However, they may also
lock you into a specific vendor. For example, a portal product built by a
database vendor might only work with that database. Care must be taken to
make sure you aren't backing yourself into a corner.
Issues to consider with these products are:
- Is it really a portal (as defined in this document), or just a web
front end to the company's database product?
- Does it work with industry standards so you can import information
from databases and companies other than the one providing the portal?
- How well does this fit with your existing University Environment? Can
you integrate it with existing campus systems well?
Visit the following web sites for information about these companies:
E-Business Portals, not necessarily targeted at Universities:
Portals specifically targeting Universities:
What "Bundled Portals" are available?
A "Bundled Portal" is anything calling itself a "portal" or "My something"
that is built as part of a larger program. Usually these are very limited
and not real portals in the sense defined in this FAQ. For example, often
you cannot define new channels or include information from other sources
into the system. However, "bundled portals" do offer some portal-like
features which may suit your needs until you can get a real portal.
Here are some products which offer a limited portal as part of the
product:
WebCT is a product for managing on-line courses. Instructors can put
courses and supplimental course materials into WebCT, and then students
can access these course materials. The system keeps track of what the
students did, can give quizes and exams, manage student progress and marks
for the class, etc.
My WebCT is a new feature in WebCT that collects all a student's courses
together in one place. The students can build their own "bookmarks
channel" with links to sites outside of WebCT, see an "announcements
channel" for students in the different classes, and see a list of all the
WebCT classes they are enrolled in. It helps to simplify using WebCT, but
it is a far cry from being a true portal.
Blackboard's focus is providing support for on-line courses. They provide
tools to let instructors create courses web courses for students to take.
Part of this product is "My Blackboard", a portal product that enhances
their learning environment with integrated tools like e-mail and chat
rooms to promote online communities for the students.
What other "University Communities" are available?
A "University Community" is a portal operated by an outside agency on
their web site. They offer services such as e-mail, calendaring, chat
rooms, on-line courses, etc. However, they do not offer additional
services custom-tailored for your university, such as access to class
timetables or other institutional databases. Often there is advertising on
these pages as well. This may be a quick way to get a "portal"
implemented, but the portal itself will be very limited. It could be
argued that these aren't true portals in the sense outlined in this
document, but instead are just customizable front-ends to the services
offered by that company.
This is a "vertical portal" oriented towards supporting university
purchasing departments. It helps to connect buyers with
suppliers. However, it doesn't support students, alumni, or other
audiences. It would not be useful as a general University Portal.
This site provides a way for alumni, students, and others at an
institution to contact each other, access mentors, coordinate graduate
reunions, etc. It is not a full University portal.
This site, oriented towards students, provides tools like chat rooms,
discussion areas, and calendars. The intention is to let students easily
communicate with each other, relatives, friends, etc.
College Club is another site for letting students communicate with each
other, and organize their lives using calendars, etc.
Section 5: Other Resources
Below is a list of other web sites dealing with University Portals.