Access Anywhere: The JHSPH Portal Project Ross McKenzie, Director Michelle Newman, Assistant Director Johns Hopkins University School of Public Health Office of Information Systems Baltimore, MD CUMREC 2001 May 16, 2001
Annual budget of $230m 950 full/part time faculty 1,500 students 21% international 2,500 staff 11,000 living alumni 30% live outside US Receives 27% of all research funds for US schools of public health Faculty pursue research in 40 countries Award 1/6 of all public health doctorates world wide The Johns Hopkins School of Public Health
Requirements • Secure electronic collaborative environment. • Completely web-based. • Access from disparate geographical areas. • Highly personalized. • Single point of access.
Mission Statement The JHSPH portal is an academic research tool providing a personalized single point of access for consolidating information from disparate sources.
Selection Criteria • No client software. • Rapid development and deployment. • We needed a fairly Quick Win! • Willing to form a partnership. • Established firm with a solid future. • Compatible with industry standards.
Interviewing Users • Faculty Senate Questionnaire Results • Company logos appeared as advertising • News considered not useful. • Webmail & Calendar a necessity. • Taxonomy – What does this mean? • Document Management is not clear. • Threaded Discussion/Chat – limited use.
Interviewing Users • 100 Personal Interviews • What do you do? • How comfortable are you when using your computer and browser? • Encourage openness. • Useful as an opportunity to talk with less vocal faculty.
Portal Categorization • Benefit of Portal • Many ways to present information. • Challenge • Finding the best way to present the information for the user and for future administration & maintenance.
Portal Categorization Possible Solutions • WebLinks • Taxonomy • Basic CDA’s • Complex CDA’s (user customizable) • Another Tab
Personalization • User Perspective • The ability to choose what you want to see and where you want to see it. • Technical Perspective • The ability to determine the user’s options.
C L I E N T Browser Client Internet Explorer Netscape WAP Device Web Server Microsoft Internet Information Server (IIS) WAP Gateway X P S XML Application Server Content Delivery Services XML Portal Server D A T A Internal Sources Apps Databases Security Broker Mail File System File System External Sources WWW Apps Databases Outside Sources Outside Search Engines Framework and Architecture
User Roles • Managing Access through “Roles” without creating an administrative nightmare • Faculty, Alumni, Students, Staff, External Users • Departments • Centers, Committees, Classes
User Interface Design • Minimize company logos wherever possible. • “Search” available at all times. • Pay close attention to the use of pop-up windows and additional windows. • Allow for single sign on. • 2-column, 3-column, whatever! • Use of tabs.
Application Integration • Clinical Trials Data • Forms • Administrative Applications • Student • Financial • Grants/Contracts
Rollout • Training Classes & One-on-one • Paper Brochure • Email • Posters • Portal Booth
Why Training? • New applications (web calendar) • Explain personalization • Dual purpose (also to get buy-in!) • Explain potential
Security Requirements Portal software • had to fit into our current security architecture which is somewhat restrictive for an academic institution. • must authenticate via LDAP. • must work with certificates. • must work with SSL.
Lessons Learned • Start interviews as soon as prototype is done! • Don’t use the word “Taxonomy!” • Component creation - easier than anticipated. • Training will be extensive!
Future • Accessible from wireless Palm/CE devices (not the Palm VII – 802.11b access) • Develop a true e-learning environment to merge our distance and onsite students and to provide service to alumni.
Contact Info Ross McKenzie email@example.com Michelle Newman firstname.lastname@example.org http://portalinfo.jhsph.edu