Portals what and why? Presentation defines a portal as a main entrance or site serving as a guide to other sites on the web. It discusses business drivers for portals including preventing silos, thinking user-centric, and reusing functionality. Usability drivers include a single screen for all information, single sign-on, and a consistent user experience. Architectural drivers are simplifying architecture and enabling modular and scalable designs. The key driver is reducing time to market. Challenges include requiring user-centric thinking and coordination across teams. Examples of portal products and technologies are provided.

1. Portals what and why? Presentation by Jeroen Zomer

2. Agenda Definition Reasoning business drivers usability drivers architectural drivers single, key driver Challenges Products and Technology Examples Assignment

3. Definition of a Portal Main Entry: por·tal Pronunciation: \ˈpȯr-təl\ Function: noun Etymology: Middle English, from Anglo-French, from Medieval Latin portale city gate, porch, from neuter of portalis of a gate, from Latin porta gate — more at port door, entrance; especially : a grand or imposing one the whole architectural composition surrounding and including the doorways and porches of a church the approach or entrance to a bridge or tunnel a communicating part or area of an organism; specifically : the point at which something (as a pathogen) enters the body a site serving as a guide or point of entry to the World Wide Web and usually including a search engine or a collection of links to other sites arranged especially by topic

4. Why does business want them? prevent silo's, think user-centric configure before build out of the box functionality (i.e. language preferences) white-labeling capabilities functionality without infrastructure context sensitive applications profiled experience (bronze, silver, gold) reuse of functionality

5. Why do users want them? single supplier single screen, all information Single Sign On (SSO) Single Identity unified look & feel consistency personal (pull and push) multimodal

6. Why do architects want them? simplify architecture (UI on SOA?) unified architecture create the generics once modular HA and 24x7 are feasible smaller deployments easier scalability less components

7. Key Driver Time To Market!

8. Portal challenges user centric thinking required more coordination needed thinking in reusable requirements concept guarding ownership organizational change new technology adaptation

9. Products and Technology Just a quick overview, for context products: IBM WebSphere Portal, Pluto, uPortal, JetSpeed, BEA (Plumtree) Portal, Liferay, Microsoft Sharepoint Portal, SAP .., Peoplesoft .., SUN .., Oracle .., ....... technology: JSR 168/286 (1.0 vs. 2.0), WSRP 1.0/2.0

10. Key components small modules (windows, gadgets, portlets) title bars aggregated functionality customization personalization: pull - request personification: push - profiled context and cooperation Single Sign On persistent preferences

11. Designing for Portal Tips think user centric think task oriented think workflow think small component, but not too small portlet content is not important draw small windows, titles, buttons do not start with drawing

12. Common objections Portals are expensive Why fix something that isn't broken? Portals are overcomplicated Portals are not widely accepted (yet) We want to own our products

13. Thank you Please remember: this was just an introduction, touching the surface of a iceberg of details "He who asks is a fool for five minutes, but he who does not ask, remains a fool forever." Chinese Proverb