iCampus

1
iCampus
Going Live at Illinois State University Michael
Erdely - mjerdely_at_unicon.net Arturo Ramirez -
aramir_at_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
16
Financial Aid
17
Financial Aid
18
Financial Aid
19
Email
20
Registration
21
Registration
22
Registration
23
Registration
24
Registration
25
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 werent 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 departments 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
• Its my data! Mine, mine, mine!!!
• Its 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
  doesnt
• 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 developers dream
• Keep business logic out of the iCampus portal!
• Get XML from the outside all the time, anytime!
• Input Simple form
• Output XML
• ltSCHEDULE_COURSEgt  ltCOURSE_DEPARTMENT_NBRgt412lt/COU
  RSE_DEPARTMENT_NBRgt  
• ltCOURSE_DEPARTMENT_ABBRgtBSClt/COURSE_DEPARTMENT_ABB
  Rgt  
• ltCOURSE_DEPARTMENT_NAMEgtBiological
  Scienceslt/COURSE_DEPARTMENT_NAMEgt  

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 developers box and
  refine XML according to customer needs Use CVS
  system!
• Phase 6 Move channel to QA so customer and
  others can review it and make comments (test
  using focus groups)
• Phase 7 Load test in QA
• 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
Database
Load Balancer/ SSL Encryption Engine
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 wont be out of the
  loop when new uPortal features are incorporated
• Users feedback is very important
  (icampus_at_ilstu.edu)
• If you answer the questions and attend their
  requests theyll 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_at_unicon.net
• Arturo Ramirez
• aramir_at_ilstu.edu