1. Olivier Liechti Java architect Sun Microsystems P7: A pilot portal project for the K12 Community in Geneva, Switzerland PEPC 2003 Pan European Portal Conference 2003

2. Agenda ● Presentation of a K12 portal project – Pilot for the State of Geneva, Switzerland – Delivered by Sun Professional Services ● Approach & methodology ● Architecture – Sun ONE platform & open source packages – 4 different modules delivered incrementally ● Demonstration (off-line) ● Lessons learned ● Questions & answers

4. Objectives ● Share the experience gained during the project ● Explain how the portal is used by the K12 community ● Describe the pilot architecture ● Review a number of Open Source packages that fit nicely in any collaborative portal

5. Project Overview (1) ● Partnership between: – State of Geneva, Switzerland – Sun Microsystems ● Project owner – CTO for the State of Geneva (CTI) – Strong focus on e-Government – Want to establish a transversal portal across departments (education, health, finance,...) ● Project sponsor – Director of the Pedagogical Center for ICT

6. Project Overview (2) ● The role of Sun Microsystems – Take project leadership and deliver a complete solution. – Take an active role in the capture of requirements and coaching of project team. – Provide technical expertise. – Provide a platform for building a K12 portal. ● The approach – Iterative and incremental development – Early and frequent release of the system – Early involvement of portal users, workshops and feedback gathering

7. Project Objectives ● Pilot project ● Explore the application domain – Define high-level functional requirements – Implement them and provide a "sandbox" to pilot users (teachers) – Iterative & incremental development, participatory design, lots of workshops! ● Evaluate the Sun ONE platform – Design and implement a Sun ONE stack with the Sun ONE products. ● Integrate third-party packages

8. Project Timeframe ● July 02 – November 02 – Analysis, design, implementation & evaluation – Iterative process, evaluation started in August already ● December 02 – End of the first evaluation period, validation of the results. ● January 03 – Extension of the pilot evaluation, with an increase in the number of participants

9. Approach & Methodology (1) ● Iterative & incremental development – Deliver system releases early and regularly – 4 modules delivered sequentially ● Involvement and coaching of users – Series of workshops, after each release – Super-users (teachers) had to come up with usage scenarii for the generic tools ● Initial requirement capture – brainstorming workshops, high-level requirements definition – Selection and definition of priorities

10. Approach & Methodology (2) ● For every functional module – Search for, evaluate and select a software package (Open Source if available) – Integrate the user management of the package with the user management of the portal – Develop a portal channel to present information on the desktop page ● Involve the customer team, so they can repeat the process in the future ● Show that S1PS can integrate heterogeneous technologies

11. Functional Requirements ● Basic portal features – personalization, aggregation, messaging, calendar, search ● Support identity management in a decentralized way ● Support role-based access to services ● Strong focus on collaborative tools – Collaborative Web spaces – Content Management System – Mailing lists and newsgroups

12. “Don't learn to use ICT. Use ICT to learn!” Raymond Morel, Director of CPTIC, Geneva Project Sponsor

13. Non-Functional Requirements ● Ease of use – for the end-users – for the system administrator ● Localization ● Stability & performance ● Prepare for scalability and high- availability, but do not address it explicitly during the pilot.

14. Subsystems ● Core Portal module – infrastructure – portal – messaging – calendar – search engine ● Collaborative Web module ● CMS module ● Mailing lists module ● Newsgroups module Sun ONE stack Open Source packages

15. Core Portal Module (1) ● Requirements – Personalization – Aggregation – Identity management – Communication – Search ● Hardware – 3 servers – 1 development server ● Sun ONE Products – Portal Server 3.0 – Directory Server – Messaging Server – Calendar Server – Sun ONE Web Server – Compass – Personalized Knowledge Pack

17. Collaborative Web Module (1) ● Requirements – Create a collaborative space, where people can browse and easily edit Web pages. – The target is the workgroup (e.g. a class, biology teachers, a project team) – Favor a lightweight approach, that does not require special tools on the client side. ● Application examples – Group assignments and collaboration – Never-ending story – Project management for interest groups

18. Collaborative Web Module (2) “TWiki is a leading-edge, web-based collaboration platform targeting the corporate intranet world. TWiki fosters information flow within an organization; lets distributed teams work together seamlessly and productively; and eliminates the one-webmaster syndrome of outdated intranet content.” http://twiki.org, mission statement

19. Collaborative Web Module (3) ● Selected software – http://twiki.org – perl ● Features – Any browser – Link management – Attachments – Revision control – Access control – Variables & plugins – Skins ● Pros – very lightweight – editing the content is very fast ● Cons – don't expect "beautiful" documents – need to learn the TWiki syntax – not designed for scalability

20. Collaborative Web Module (4)

21. Collaborative Web Module (5) ● Portal channel – Quick solution: the URLScaper provider, but... – only works for non-protected URLs – Screen real-estate is an issue ● Identity management – TWiki provides its own user management – Users and groups are defined in TWiki topics – Every TWiki user has an associated TWikiUser topic, with its data and preferences. – In this topic, the TWikiUser id is mapped with the Web server user id

22. Browser Web server TWiki script GET /twiki/bin/view 401 Unauthorized WWW-Authenticate: Basic realm="twiki" TWiki UserTopi c GET /twiki/bin/view Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== invoke REMOTE_USER=john lookup mapping between web server user and TWiki user LDAP Server auth

23. CMS Module (1) ● Requirements – Provide a mechanism to create and publish on-line documents, in a controlled manner. – Support a basic validation workflow, where editors validate the content submitted by authors (then accessed by readers). ● Application examples – School newspaper – Assignments submitted on-line – One-to-many communication channel between teacher and parents

24. CMS vs. Collaborative Web Authors Lecteurs CMS (spip) Éditeurs explicit control and validation Editors Readers induced control mechanisms Collaborative Web (twiki) Community of peers

25. CMS Module (3) SPIP is a simple, yet powerful CMS system http://spip.org

26. CMS Module (4) ● Selected software – http://spip.org – PHP, mysql ● Features – administrative interface – LDAP interface – validation workflow – forums – syndication ● Features (cont.) – keywords – search engine ● Pros – new instance can be deployed very easily (by end- user) – user friendly – very simple, yet feature rich – elegant

27. CMS Module (5) ● The dynamic sites consist of categories, organized in a hierarchy ● Articles and briefs are published in these categories ● Authors use the admin interface to create and submit documents ● Editors use this interface to define categories and validate documents ● Webmaster use tags to create templates for the site

29. CMS Module (7) ● Identity management – First versions of SPIP stored users, passwords and roles in the mysql database – SPIP 1.5 now offers an LDAP interface for authentication, and a basic mechanism for role assignment on initial login ● Portal channel – Display article headers in the channel – In the "edit" mode of the channel, users can select from which SPIP categories

31. CMS Module (9) Portal Provider SPIP Abstraction Layer in Java SPIP Database SPIP PHP Web Browser JDBC ClientPresentationBusinessIntegrationResource TemplatesCore

32. Mailing Lists Module (1) ● Requirements – Support the creation and management of mailing lists – Enable the definition of policies for these lists (access rights to archives, posting rights, etc.) – Provide a web-based interface (localized) ● Application examples – Teacher to students communication channel in a classroom – Exchange of information between all teachers of the same branch

33. Mailing Lists Module (2) http://sympa.org Sympa is a very flexible mailing list manager

34. Mailing Lists Module (3) ● Selected software – http://sympa.org – perl, mysql ● Features – Multilingual – Customizable web interface – Policies – Dynamic membership – Document repository ● Pros – very flexible – LDAP interface for authentication and dynamic membership ● Cons – Need to run as FASTCGI for good performance

35. Mailing List Module (4)

36. Mailing List Module (5) ● Integration with Sun ONE Messaging – One account for every mailing list – Pipe the messages to the Sympa daemon – Manage accounts through the web interface ● Identity management – Sympa offers an LDAP interface for authentication and dynamic membership ● Portal channel – Display message headers in the channel. – Future work: display statistics, e.g. most active list, number of messages, etc.

38. Mailing Lists Module (8) Portal Provider Sympa Abstraction Layer in Java Sympa Database Sympa perl Web Browser JDBC ClientPresentationBusinessIntegrationResource TemplatesCore

39. Summary ● Use TWiki if you want to create collaborative spaces for workgroups ● Use SPIP if you need a publication workflow and good looking documents ● Use Sympa if you want to use mailing lists and newsgroups

40. Lessons Learned & Conclusions ● Engaging users early and often in the design process is very important ● There is a strong demand for collaborative tools in the K12 community ● The tools used for the project are not specific to the K12 domain – they can be used in other application domains ● Working with teachers is a lot of fun!

41. Q& A