I took a few moments to write up a transcript of the audio from the recent Johns Hopkins University uPortal demo featured in the February 2010 uPortal Community call and I'm sharing that transcript in this blog post. I'd say this is a "good enough" transcript of the audio in the YouTube video, not a perfect transcript. Please do clue me in to ways the transcript can be improved via comment or the Unicon.net contact form.) This transcript has also been added directly to the YouTube video to inform YouTube's captioning feature. All hyperlinks are mine. (Embedding the video immediately below doesn't render on at least some versions of Chrome for reasons I don't yet understand. In the meantime, any fellow Chrome users can view the video directly on YouTube.)
Okay, I guess we'll just start with a brief background and history here at Hopkins with uPortal. It started as a pilot project back in summer of 2005. At the time Hopkins IT was working closely with the library, specifically with Elliot Metsger who helped launch the initial portal in February of 2006 to a pilot audience. I [Chris Doyle] began working for Hopkins in April 2006 as tech lead of the portal. June 2006 was our first launch to an official audience. We herded all of our incoming freshmen in through the portal to provision their email accounts and their JHED accounts. JHED is their directory account here at the University that gives them access to all the resources at Hopkins. So we had about 2,000 users at that time come in and we've grown to about 80,000 registered users. We get about 2 million page views per month now with about 15 to 20 thousand unique users per day. We've put a lot of highly visable highly used applications like search, the Web-based SSL VPN software is offered through the portal, there are a number of resources, for JHU staff their timesheets are filled out through the portal. All provisioning of the incoming freshman class to JHU is still done through the portal so we've got another round coming up in June about to start their provisioning. So obviously our user base has grown tremendously. That's happened over time as we've introduced new services and centralized services into the portal. We should talk about sign on. At Johns Hopkins we use a product called Netegrity Site Minder for single sign-on and we have about 300 applications currently protected with Site Minder authentication not all of which are available through the portal but quite a few of which are available right through the portal. With all that said I'll jump into the demo. We're not only offering a portal to the university constituents, we're also supporting a portal for the Hopkins medicine organization, also the hopsital. So we've got a lot of clinical apps we're starting to look at integrating into the portal as well as the university community's. We actually have right now four public-facing entry points into the portal. We've implemented custom URL based personalization. If you go to my.jhu.edu you'll see the portal that you see right now on the screen. If you go to my.jhmi.edu that redirects you to get a different skin. The content looks the same there but it's actually housed in a separate area in our content management system. We also have the School of Advanced International Studies. They're out of Washington DC but they're also offices in China and Bologna. They maintain all their own content as well. That's another public entry point. So if you go to insider.sais-jhu.edu that's another public entry point and they manage all their own content as well. We also have worked with the Engineering for Professionals which is a part of Johns Hopkins University. They have their own skin and their own public entry point which is myep.jhu.edu. We're also working with the Carey Business School. They're working on their own skin and their own public entry point as well. This is all being served from the same portal instance. To give you an idea of what our setup looks like: We have six physical machines that are serving our portal that are fronted by two switches. They're actually spread across two data centers, so our load is distributed across two data centers, across six app[lication] servers. We have two virtual machines on standby that we can just throw into the mix at any time. We're using Tomcat 5.5. We're actually running on Win[dows] they're not Linux boxes and we're fronting it with IIS. We have a number of custom Cold Fusion applications that we proxy into our portal that are running on these same 6 portal boxes. We're looking in the next year to go completely virtual and not have any physical machines. We also have a development environment and a staging environment. We convert one of our prod boxes into a pre-prod environment when we're preparing releases. We release probably on a monthly basis, sometimes more, sometimes less depending on what we're putting out. We try to stick to a monthly release schedule and we try to pumpt things through the development staging to prod as much as we can. So I've got to show you the authenticated view. There's not much useful content to individual users per se in the public entry points. Except for SAIS, they've done a really nice job at posting latest news and events and things like that. But the authenticated view looks something like this. And this is just my experience, just to give you an idea. We have close to 30 individual DLM fragments defined for the various constituencies within both the university and the hospital so we have a large number of interested communities in publishing content out to those individuals who want to receive it. We heavily use PAGS [Person Attribute Group Store] and we also use the Smart LDAP Group Store for Active Directory integration. We consume close to I want to say about 50 Active Directory groups right into the portal to use for authorization for resources within the portal channels, DLM fragments, things like that. We're making JDBC calls to get person attributes. We actually have some custom person directory plugins that make web service calls. We have web service calls going out to WebCT to get their IMS id as a person attribute so we can use that to assign permissions. We really were excited about the Quick Links that came along with uPortal 3. Just to note, we were one of the early adopters of uPortal 3 back in the summer of '08 I believe. I guess we launched in the August-September timeframe. We've been on uPortal 3 since then and made a number of incremental updates to the codebase. Tried to patch our code base with security patches and things of that nature. Have been looking at a jump to [uPortal] 3.1. We're still evaluating what we're going to upgrade to. We were really excited when we first jumped onto 3.0 about the Quick Links. Instead of relying on the portal framework to provide that functionality, we broke that funtionality out of the portal and wrote our own app so we could proxy that content in. You know, let the portal do what it does best and we kinda just enhanced the quick links so we can group links. So we have multiple mail systems here at Hopkins. As you can see I have four different quick link icons that break out into a horizontal. One thing that one of the developers here did is give us a quick email preview, it makes a Web Service call out to Outlook and just displays a real quick link and actually when you click one of these emails it will just take you out to a separate browser session through Outlook Web online. These quick links are configurable. We have a configure quick links that breaks out here. I don't necessarily want to see all the quick links that are available so this gives the end user the capability to control their quick links. We really like the idea of being able to control pushing out required links to people but we wanted to give the end user the control to do that. From an administrative standpoint you can lock down the quick links to be readonly so they have to get it. So everybody has to get the first quick link here which is the "my profile" which gives them access to their directory information and their visibility attributes and things of that nature. So that was one peiece of functionality where we kind of deviated from the core uPortal codebase and rolled our own quick links based on the concept by uPortal. We're actually using Quick Links information that's in the uPortal tables itself but the application itself is just standalone.