In order to retain users, these sites introduced personalized portals (eg my.yahoo.com) which allow the user, via simple interfaces, to select various types of pre-existing data-feeds and do basic page layout.
The solution to Caltech's dilemma was to offer information in two ways - organized as above, or organized by what kind of audience type the person browsing belongs to, i.e. Portals for Alumni, Undergraduates, Staff, etc.
My{Yahoo|Excite|Lycos} are personal portals because they have a wide variety of choices from which each person may choose when personalizing his site. This type of portal is really popular right now, but I would be curious to see how many people actually take the time to personalize.
Our portals form a "group portal" system; a set of administration level people (managers) guess at what a specific type of audience would like to see. These managers construct or choose the data-feeds and do the page layout. The parameter AllowUserLevelPortals, when set to 1, can allow each user to act as his own manager - although the user-as-manager can not construct his own data-feeds.
Perhaps the best kind of portal is the kind that allows the user to start with a group type and then later may customize his own set up. We don't currently have a way for a user to easily migrate from a group to a personal portal, but it should not be difficult to do so.
The default portal_table editor is a simple ADP editing field; the ADP itself can be complex depending on how much, if any, tcl is involved. To shield managers from this, the admin_url column can be set to a URL of a better administration tool.
Changes to portal_table fires a trigger which backs-up information in portal_tables_audit for versioning purposes.
The portal_pages table holds page names, numbers, and owners, where the owner is either defined by a group_id or user_id, whichever is not null.
Finally, portal_page_map is a bit more than most _maps in ACS, it maps tables to pages and to locations (left side, right side, 3rd from top, etc.) so it is more of a layout definer than a map.
; for the Portals System [ns/server/yourserver/acs/portals] Administrator=aure@caltech.edu AdministratorName=Aurelius Prochazka SystemName=Caltech Portals ; set to 1 if individual may create their own portals AllowUserLevelPortals=1 ; set to 1 if super administrator can add or remove themselves and other super administrators SuperAdminCanChangeSuperAdminP=0 BodyTag=<body background="http://www.caltech.edu/pics/background.jpg" link=#006600 vlink=#003300 alink=#669966 bgcolor=#eeeedd> FontTag=<font face=arial,helvetica size=-1> ; These standardize a prettier table than the browser default BeginTable=<table border=0 bgcolor=#006600 cellpadding=1 cellspacing=0 width=100%><tr><td><table border=0 bgcolor=white cellpadding=3 cellspacing=0 width=100%> EndTable=</table></td></tr></table> HeaderTD=<td bgcolor=#006600><font face=arial,helvetica size=-1 color=#eeeedd><b> HeaderBGColor=#006600 SubHeaderTD=<td bgcolor=#eeeedd><font face=arial,helvetica size=-1><b> SubHeaderBGColor=#eeeedd NormalTD=<td><font face=arial,helvetica size=-1> ; For portals with multiple pages, tabs link to the other pages, set this to 1 if you want each tab ; to be equal width instead of proportional to the name of the page EqualWidthTabsP=0 MainPublicURL=/portals/ ; number of seconds to memoize a portal page CacheTimeout=100 ; browsers will decide the "optimal" column sizes unless you force column widths here: ;LeftSideWidth= ;RightSideWidth= SpacerImage=/portals/spacer.gif
portal_group
.
Super Administrator
from the /admin/portals
page.
/portals/admin/
We use the "memoize" procs on the portal pages for speed: Popular pages need not incur x sql queries on each server request. We use a variant of Memoize_Force called Memoize_for_Awhile_Force found in /tcl/portals-defs
Super Administrators can assign portal managers and create, edit, delete or restore any portal table he wishes. When creating or editing a portal table he has the option of associating a url with that table. In restoring a table, the Super Administrator can view previous versions of a table (held in an audit table in Oracle) and select the one he wants.
The Super Administrator may also masquerade as a manager of any portal group to directly change the layout of a given portal.
Regular managers see a list of manageable portals (one manager can have any number of portals to manage) or get redirected to the main portal management page if he is a manager of only one group. On this page, he will see select boxes that correspond to page sides. Each page has a re-nameable title. The last page is initially empty because it will only be created when items are moved into it. Potential portal elements (not on any page) appear in the bottom centered selectbox, clicking one of the two arrow keys adds that element to the lowest page.
Here the manager may also click on "X" to remove the table from portal pages seen by the user or the manager may click "?" to edit the ADP content.
When done setting up the portals the way the manager likes, he clicks FINISH to implement the layout changes.