A good portal for an educational organization ought to encapsulate five key concepts:
- Integration -- everything the end-user is looking for is here and is easy to access
- Customization -- we know what we know about the user to give them what we think they want
- Personalization -- the end-user can modify their portal as they see fit
- Communication -- we target messages only to users to whom the message actually applies
- Anticipation -- based on existing data, the system anticipates what is most likely to happen next
These concepts are all driven by data the organization already has about it's users. Best of all, most of these concepts rely on population selection techniques that, once setup, automate the portal.
Key Concepts
Integration -- all of your organization's services belong here. These services include links to information (e.g. information about the Information Technology department, how to checkout books from the library, where to go for registration, etc.) as well as actual web services (such as your organization's email, calendaring, and document management systems).If your first thought when you read "integration" above was Single Sign-On (SSO), you're on the right track. SSO can be used to tie all of your organization's web services together so that when a user logs into your organization's portal, they have one-click access to all of your web services.
There are a variety of SSO solutions available on the market for organizations of any size or budget; they include Free / Open Source Software (FOSS) solutions like JASIG's CAS service all the way to cloud-based Software As A Service (SAAS) solutions such as OneLogin.
Customization -- once a user logs in to your organization's portal, the content, services, and applications that they see should be customized to what we know about the actual user who is logged in. For example, students would see their grades, have links to class registration and the bookstore, and be able to access your organizations Online Learning Management system quickly and easily. Staff would see links to Human Resources and the IT ticketing system.
But it doesn't have to stop there. The basketball coach -- who is an employee -- could see the team's schedule, performance, etc. in addition to the other links that other staff typically see.
There is no need to have a page with hundreds of links on it pointing to anything and everything that might be usable. The technology exists right now to simplify what the end-user sees based on what we already know about them.
Moreover, the system already has all of the information that it needs to provide this level of customization without asking the end-user to self-identify.
Simply put, there's no reason to ask the end-user if they're a student or a member of the faculty as the system already has this information. The system knows where the student went to school before, what classes the student is taking, what grades the students has received, the department of an employee,
what groups, clubs, and organizations the user is affiliated with, and much, much more.
When the system requires the user to click a button to say, "I'm staff," we're both wasting that user's time and demonstrating that we're not taking advantage of the data our systems already have.
The goal here is to make it as easy as possible for the end-user to complete whatever tasks led them to the portal in the first place; they should see the system's best guess as to what they might find the most helpful.
Communication -- the flip side of an end-user using a portal to find something is when the organization wants to send a message to specific target groups of users. Targeted communication is generally accomplished by specifying not only a message, but also a description of the intended recipients.
Consider the example of a school sending a message out to all 10,000 students providing them with a second reminder that if they haven't paid their housing deposit by a given date, they might lose their desired housing option. Now, consider the number of students to whom this message doesn't apply. Students who are not signed up for housing next year don't need a reminder. Students who have already paid their housing deposit don't need a reminder. In fact, there may only be a few dozen students who actually need this reminder. If there are 100 students who need the reminder, there are 9,900 students who do not.
As a result, 99% of the students who receive this message might as well be getting spam.
If this happens frequently enough, your users will stop reading what you're sending since whatever you send is likely not to apply to them.
Fortunately, the technology exists right now to provide targeted communication functionality.
Personalization -- while the end-user's initial visit to the organization's portal should be our best guess as to what they may need, the end-user should be able to personalize their experience of the portal to match their individual needs.
The aforementioned basketball coach may also be taking his Masters in Business Administration (MBA); come May, the coach is far more likely to be interested in the exam schedule for the test next week than what the team's score was in their last game four months ago.
Similarly, one user may be keenly interested in knowing the weather conditions outside (they may have an hour drive to get to campus that they need to plan) while another may not care at all (they may be a resident with a five minute walk under a covered walkway).
Anticipation -- as mentioned before, the portal already has a lot of information about the user base. When an individual user is considered (e.g. a "micro" view), the system can provide pretty accurate guesses as to the resources that the user will use. However, when the entire user base is considered (e.g. a "macro" view), the system can provide pretty accurate guesses as to what will happen based on trends in the data.
For example, consider an organization that requires as a general education requirement two classes in writing -- Writing 101 and Writing 102. Further consider that over the past five years, after passing Writing 101 in the Fall, students take Writing 102 in the Spring 85% of the time. If at registration time in the Fall semester we have 300 students who are currently taking Writing 101 and currently have passing grades, the organization can reasonably predict to have to teach at least 250 students Writing 102 in the Spring semester.
That is, the system can anticipate roughly how many sections of a given class will need to be provided based on the current user base and the data on users' past behaviors. As a result, the system can help predict and anticipate resource loads and provide data supporting better allocation of existing resources.
Another example is to consider that most of the year, students aren't registering for classes -- there are only a few times of the year when lots of users are registering for classes at the same time. During those peak times, many users are clicking on the link to register for classes; outside of those peak times, few users are clicking on the link to register for classes. So, the system can anticipate that during those peak times when registration is happening, the link(s) to register for classes should be more prominent. That is, the more popular a link is, the more prominent it could be displayed. While this can be done by hand, it's far more efficient if the system can observe the popularity of links and bubble up the more popular ones automatically.
Population Selection
Most of the key concepts mentioned previously rely on population selection techniques. That is, for each type of customization or targeted communication or each group of users whose behavior the system is attempting to anticipate, subsets of the user base need to be specified, primarily by articulating search terms.So, for example, consider the idea of setting up a special graphical "Welcome!" theme for students who have recently matriculated in a program. It would be sub-optimal to show this theme to students who are in their fourth year of continual enrollment. Moreover, it would be similarly sub-optimal to show this theme to students who haven't yet been accepted into the school. So, how does the system know who sees the Welcome! theme?
We specify a group of users -- a population -- that forms a selection from the user base as a whole. This selection can be represented as a query. For example, if we were to search for new students, one way to search would be to look for students whose number of semesters of enrollment is equal to one. The system can then perform the necessary queries to figure out what each user sees and store that information for when they login.
The Technology
The best part of all of this is that there exist tools to instantiate this functionality right now. There are Free / Open Source Software (FOSS) solutions such as uPortal (JASIG) and Liferay (Liferay Inc.) and there are commercial platforms such as Luminis Platform (Ellucian, formerly known as Sungard Higher Education).(Full disclosure -- while I was a beta tester for Luminis Platform 5, I no longer have any formal relationship with Ellucian)
Summary
Portals ought to encapsulate several key concepts:- Integration -- tie everything together in one place
- Customization -- systematically make guesses about which resources the end-user is looking to find
- Personalization -- allow the user to manipulate the environment for their ease of use
- Communication -- target messages only to recipients to whom the message applies
- Anticipation -- automate the decision-making process based on current and past data
These resources are backed by data that already exists in the system about the organization's users and their application can frequently be automated by the use of population selection techniques.
These resources belong in your organization's portal, not on your organization's home page. The home page is a tool to help Admissions attract and recruit top talent to your organization.
Best of all, none of this is science fiction; it's all possible using existing technology that is available to any organization, regardless of the size of the budget or the size of the student body.
Related links
Wes Dean, a Google Apps Certified Deployment Specialist and a Google Apps Trusted Tester, is Principal of KDA Web Technologies, a Google Apps Authorized Reseller. To learn how Wes and KDA Web Technologies can help you, go to http://www.kdaweb.com/.
No comments:
Post a Comment