1. iCampus Going Live at Illinois State University Michael Erdely - mjerdely@unicon.net Arturo Ramirez - aramir@ilstu.edu

2. Illinois State University Founded 1857, first public University in Illinois Public, coeducational, and residential 160 undergraduate major/minor options in six colleges 37 master programs, 2 Specialists, 7 Doctoral 850 acre campus is located in central Illinois, the communities of Normal-Bloomington Fall 2002 enrollment, approximately 17,500 undergraduates and 2,500 graduates http://www.ilstu.edu/

3. Why go with a Portal Educating Illinois strategic action plan –“Building a Technology Friendly Campus” Create an alternative personalized view of available services Homepage running out of real state space Need for virtual one-stop student services The purpose of going to a hardware store to buy a drill bit is not to own the bit but to make the hole …

4. Why go with uPortal Open source framework for presenting aggregated content Easiest route for adding value to existing systems Commercially supportable Based on XML/XSL transformations The only open source portal developed by and for universities Available content

5. State of affairs of iCampus iCampus Demo –What is in iCampus –What can students see –What are all the channels –Why go with some UNICON channels Current usage stats (Grades, Elections, Registration)

6. Login

7. Home

8. Redbird

9. Transactions

10. Schedule

11. Schedule/Map

12. Text Books

13. Grades

14. GPA2

15. Financial Aid

19. Email

20. Registration

26. Registration2

27. Campus Life

28. People Search

29. Voting

30. Matrix Skin

31. State of Affairs - Statistics Logins –At peak times between 700-1200 users login every hour Voting –4000 student surveys completed (36 hrs span) Grades –7000+ users checked their grades through the portal within 48 hrs of being posted Registration (Sessions w/ 200 users aprox.) –3,120 hits in one hour – almost 1 per second

32. How did things work before iCampus Student Information Access System (SIAS) –Mainframe sessions: fast and reliable Cumbersome interface Accessible through TN 3270 emulator screens Messages / errors had to be brief –Information restricted to 80 chars per line Services that just weren’t available before –Redbird card, GPA Calculator, Financial aid awards accept/decline system

33. SIAS Terminal - Login

34. SIAS Terminal - Menu

35. SIAS Terminal - Registration Menu

36. SIAS Terminal - Registration

37. SIAS Terminal - Schedule

38. SIAS Terminal - Course Directory

39. SIAS Terminal - Postal Address

40. State of Affairs - Campus Services Campus Services –Well organized but at times nowhere to be found –Departments changing links to their own pages –In general, did not provide custom information –Needed individualized attention –High dependency on individual department’s own resources

41. State of Affairs - Web

42. Risks uPortal was in beta version at the time that iCampus work started Technology curve was steep Not enough buy in from the entire campus How can we import legacy data What if project failed Do we want real time data presented to the students Campus services are more visible so if something goes down people will notice

43. Engaging different departments How do you get other departments to buy into this idea –Proving iCampus Portal reliability and success (Elections) –Saving them money (Eliminating mass mailings) –Less headaches for staff –Portal can get data across to the students in real time Initial reaction against a consolidated portal –It’s my data! Mine, mine, mine!!! –It’s my hardware, my servers, my network!!!

44. Planning - History Planning phase - (Spring ‘00 – Spring ‘01) –Committees work: Have a good plan before coding (users first, tech issues later) Prototype phase – (Fall ‘01) –Focus on a small population and do extensive testing –Initial development and first online test Going Live – (Summer ‘02) –3000+ new freshman used for Preview program –More features than conservative planning proposed Today – (Summer ‘03) –All 20K+ students, faculty and staff have access

45. Planning - Committees Executive Development Group Oversight Planning Committee Development Team (16 campus staff) Content Committee E-commerce Committee Digital Imaging Committee Student Portfolio Planning Group(s) Faculty Staff Portal content LDAP Committee ECAT

46. Planning - Groups AIS (data and data delivery) CISS (infrastructure) IWSS (front end and features) Registrar/admissions (SIAS one-stop) Campus community (content committee & focus groups) Outside consulting IBS Interactive Business Solutions/UNICON (uPortal consulting and programming)

47. Planning - Channels How to come up with channels –Content Committee analyzed campus needs –Comes up with Initial list of 42 channels –List reduced to 15 possible roll out channels –Channel approvals go through Portal Content Committee before developers get anything going

48. Planning - Consulting Services Why UNICON Invaluable Experience –Wrote the initial uPortal prototype –Heavily involved in uPortal management and development –J2EE solutions for higher ed. since 1997 –uPortal Applications & Content –uPortal Professional Services –uPortal Training

49. Planning - People How many employees to go with –Relative to budget, campus commitment Training –uPortal training for portal developers and outside departments –Common technologies (i.e. XML) training among developers from diverse fields Web, Mainframe, etc Focus groups –Basic load test

50. Planning - Money Budget: 500K

51. Marketing iCampus Focus groups –Users helping to identify what works and what doesn’t Preview program sessions –Great testing opportunities Home page visible link –Portal does not replace Home page –They complement each other Importance of graphic design –Make portal pages appealing to student population

52. Legacy System Integration Business logic – mainframe programs EAGLE – University of Florida –Enhanced Application Generation Language for the Enterprise –Enables Internet access to mainframe databases and CICS resources Pros / cons –Lack of experience using EAGLE –Plenty experience using CICS (Cobol) queries that incorporate business logic

53. Business Logic A web developer’s dream Keep business logic out of the iCampus portal! Get XML from the outside all the time, anytime! Input : Simple form Output : XML 412 BSC Biological Sciences 101 014 220121 Fundamental Concepts In Biology

54. Channel Implementation In the beginning –Started off by gathering data from different sources (static channels) –Later, applications read and write to the mainframe (interactive) –Minimal documentation How are we building new channels –Trying to incorporate system requirements and documentation –More intensive testing and realistic time frames What has changed between now and then –iCampus is well known –Groups and departments want their content (own channel) in the portal –Anything goes wrong, you will know right away, everyone will notice!

55. Development Lifecycle Phase 1 -Identify possible content, target user groups and data sources for the channel Phase 2 -Decide what is the best method to bring content into iCampus (XML being the preferred way) Phase 3 -Review simple requirements specification (Managers/Developers) Phase 4 -Create an initial XML document with basic content for the channel Phase 5 –Test channel in developer’s box and refine XML according to customer needs – Use CVS system! Phase 6 –Move channel to Q&A so customer and others can review it and make comments (test using focus groups) Phase 7 Load test in Q&A Phase 8 Roll out to production servers

56. Roll out strategies Initial –Good stickies (need really useful things) –Small roll out size Current –Require access but have backups ready –Expand target audience –Advertise Future –Staff and faculty content –Expanded documentation

57. Hardware Load Balancer/ SSL Encryption Engine Database Other Backend Systems Apache/ Tomcat/mod_jk/uPortal

58. Lessons Learned Documentation is important –Developers think they can live without it Collaboration works –Communication among groups (JA-SIG, Universities, UNICON, students) is crucial to identify problems and possible points of failure Keep code separated (independent) from uPortal framework –Prevention mechanism so you won’t be out of the loop when new uPortal features are incorporated Users feedback is very important (icampus@ilstu.edu)icampus@ilstu.edu –If you answer the questions and attend their requests they’ll keep coming

59. Lessons Learned A portal may enforce extra effort for data keepers –Info available 24/7 People should do what they know –Owners of content are responsible for their content not display –Developers are not responsible for display –Designers are not responsible for code iCampus becomes center of attention –Thinking about becoming involved with the portal? You will get blamed for everything (even when external data sources go down or not available)

60. Questions ?

61. Thank You Michael Erdely mjerdely@unicon.net Arturo Ramirez aramir@ilstu.edu