| Table of Contents |
|---|
Agenda
- Possible co-habitation solutions
- Action plan
Issues
- User populations that cross boundaries:
- Student employees
- Postdocs
- Faculty
- "Store fronts" and naming - how do people know which one to go to?
- Look-n-feel
- Governance in general
- Aggregating search results
- Announcements (double-entry)
- Calendar sharing
- Sharing of code, data & content
- code update notifications
- portlet sharing
- user support
Proposed solutions
- Merge two portals into one (possibly with different "store fronts"):
Pros | Cons |
Seamless user experience | What to use for host name, logo, etc? |
Sharing of code & accessing shared libraries is easier | May have too many tabs/fragments to load |
One set of announcements, no duplication | May have too many tabs to display |
Unified look and feel | Have to negotiate a common look'n'feel |
Leverage the technical and hardware resources | Governance and control of the announcements, layout, look, etc? |
Redundancy | Differences in design philosophies? |
Aggregated search results | Tailoring search results is harder; may produce large result lists |
Best practices |
|
Having 2 portals makes us look unprofessional to users and colleagues |
|
- Shared database:
- Common user lists, groups, announcements, channels, permissions store
- Allows us to setup the two portals as backups for each other (possibly?)
- SNAP would have to move to MySQL: a big job, but doable
- Somehow link the databases
- Setup data feeds (may only be possible in batch mode)
- Make AdCom code and libraries available with update notifications
- Make Student Portal code and libraries available with update notifications
Minutes
- Proposed action items:
- By December, 2008:
- 2 separate instances running
- upgrade SNAP's code base to uPortal v 3.x
- discontinue support for IE6 ??
- reorganize content in SNAP, reduce the number of default tabs
- enable portlets in SNAP
- rename portals to ZotPortal
- create a "store front" -- once a user authenticates, s/he will be redirected to the appropriate portal; for users who belong to more than one audience, the store-front will ask them which portal they prefer to go to and save their choice. Both portal will provide ways to navigate from one to another
- identify common tools: e.g. library, calendar, maps, safety, email, travel, etc.
- Evaluate possibilities of merging by May, 2009
- By December, 2008: