• The second day of school was the busiest day of the term for visits (not visitors, as define by Google Analytics), 32,915.
• Monday after spring break had the highest total visitors, 18,391.
• Saturday, March 15, the start of spring break was our least busy day for visits, 4,499.

Now, you might look at these numbers and say, “Pat, that’s exactly what we would expect to happen.” That is correct, but until you actually have the numbers, you don’t really know that your expectations of reality and reality itself match up. Now you do.

The numbers for the whole term look like this:

You might notice some abnormalities in our sparkline graphs. This is due to our introduction of tracking some popular “external links” during spring break. It will slightly distort our page view data for spring 2008, external links are tracked as views, but as long as we break our reporting into pre and post break segments we’ll be fine. Our visitor information remains consistent though.

The external link tracking is important in the portal so we know where people are going when they leave. Our portal strategy has never been to bring applications into the portal, just provide easy access. Before Google Analytics it was difficult for us to track that information. Now we track clicks to all major applications from the portal. That information should prove illuminating in the future.

Overall having Google Analytics in the portal is a big win for us. We’re still keeping all the raw log file information and doing our usual processing, but this wins hands down just for the amazing breadth of information we can look at now.

Yeah, it was hopping. You can even seen the network outage we had late that night (yeah, that was fun). This is just a snapshot though. It just tells us that, in general, it was really busy.

Our login stats also show that Monday was indeed very, very busy with 31,984 logins made by 13,412 users. A good number to have, but it doesn’t say much. We don’t currently run an analysis to get a real logins per user average.

Google Analytics shows us where people went in the portal but not where they went when they were leaving the portal.

We know there are three main destinations: PeopleSoft, WebCT/Blackboard Vista, and webmail. Because of the way we send users to PeopleSoft from the portal, we have good numbers — although they are not tied to unique users.

Clearly the first day of the term (the 28th) shows a lot of activity. We rack up +70k clicks for only 13,412 users and 31,984 logins. The performance of the PeopleSoft system suffered a little that day, which is what really prompted us to start trying to tie all these numbers together.

While nothing is definitive, it seems that the performance problems were due to a number of issues — as you would expect in an enterprise system like PeopleSoft. With ~32k logins and some poor statistical assumptions you get just over 2 clicks into PeopleSoft per login and users logging in at least twice during the day.

The questions that these numbers can’t answer for us are many. Is the system usable? Are usability problems leading people to login more times than they would in a perfect world? Are students needing to login frequently on the first day to find or adjust their schedule? All of these will remain “unknown unknows” until we actually talk to students.

What do we know from these numbers? The first day of school is busy.

The result on January 8 was the busiest Portal day ever. (Pat or Scott will hopefully speak to the details of the usage numbers and Portal system performance.)

Clearly, the message was in the right place for a sufficient amount of time and helped to fulfill the compelling need of students to see their grades as soon as they were available. This was the first semester that the message went up at the beginning of finals week. It was also the first time that the message was nearly alone in terms of other content in the channel. My guess is that those were the chief contributing factors to the effectiveness of the announcement.

• It didn’t go out in the finals week edition of the Student Announcements.
• It wasn’t in any of the finals week Campus Announcements.
• The Student Records site didn’t mention it.
• We didn’t put it on the Student Computing front page.

So, my little experiment is to send portal usage stats out via Twitter. The updates are sent every two hours between 8am and 6pm, Monday through Friday. Thank you, cron! There are so many moving parts in this that I’m tempted to fire up OmniGraffle to illustrate it, but I’ll try with just words and see how it goes.

The portal has multiple servers running behind the scenes so that we can deal with lots of traffic. Each of these servers have their own set of user sessions. We can query these servers for their session information, and we do this every 5 minutes and stick the information in a database (thank you perl and mysql). We have another internal system that allows us to graph and browse this data, which is incredibly helpful in looking for usage trends. I wrote a small ruby script that uses the Twitter gem written by John Nunemaker to query the stats database and then post the information to Twitter. Scott was even so kind as to place a Wordpress widget in our theme (top right) to show the information pulled directly from Twitter.

Now, some might call this a frivolous exercise but that would be ignoring the fact that we have to push a lot of information around campus and we need to be looking more at using proper APIs and not just don’t batch dumps of data to be imported by some other system. Our systems need to talk, and more importantly listen to what other systems are saying.

We currently run two production app servers (Tomcat, Java 5, Dell 2850s) and yes, we keep the portal as simple as possible. People login, and then they go to e-mail, WebCT, or PeopleSoft. So what makes the portal different from a static HTML page with links? Two things. We know who you are and to some extent what you do on campus, so we show you things that are appropriate for your group. The real killer app is single sign-on, which in our case is CAS. You login once, and then we can get you to all these other applications, safely, without having the user login again.

Anyway, back to our Monday debacle. A big requirement of the initial uPortal deployment was that it had to stand up to peak demand, and by all measurements the portal meets and exceeds this requirement. So, where did it all go wrong? It all started deep in the core of the network…

Around 2:30pm we noticed that network connectivity was gone. I think it’s time to interject a small quote from Rands.

The fact that a computer without an Internet connection is essentially a very expensive DVD player is a recent development, but the fact is, when I sit down at my MacBook and there is no wireless I think, “Well, I could play Bejeweled, right?”

When the network goes funky CAS can lose touch with LDAP and without LDAP it can’t authenticate people. Our killer app is useless at that point and that’s when you know things aren’t going well. You also know your day is about to get worse, because the only solution is to bounce tomcat. This, of course, means (in our current configuration) we lose any existing user sessions. So, as soon as we are back up, we are inundated with a wave of people needing to re-authenticate. CAS was a “little” slow, but it eventually slogged through the onslaught of requests.

So, what’s with the odd bump in portal sessions after the network recovered? Scott surmised that it was phantom sessions. When the network went down many people probably closed their browser windows, killing their current session on the browser side but not on the portal side. After the server-side timeout was hit, the sessions (on the server) started to drop as Scott predicted.

Luckily we were in communication with the help desks and they were able to explain to people what was going on. It looks like a CAS 3.1 cluster could be useful sooner rather than later.

The first Monday is even crazier, as one would expect. Last year we even had to take one portal server down for maintenance. Our current setup allows us to do this without much fuss, as we just roll in a hot stand-by server.

The most exciting element of the upgrade is the move away from table based layouts thanks to the Yahoo! Grids framework. Thanks to some clever XSLT hackery we are now able to support 1-3 column layouts. Plus, we reimplemented our tabs using the YUI Tabs mark-up and styles to take advantage of the browser testing Yahoo! has already done and standardize on something.

We also made a slight change to the location of the navigation bar by moving it above the banner graphic to a location more inline with where major websites (Yahoo, Google, etc.) place the ” YOURNAME Login/Logout” links.

Not content with our footer, we jazzed up the mark-up with some Microformat goodness and tossed in a Campus Search box; just in-case someone has a need to search for something not in the portal.

The finishing touch of the upgrade was the migration away from Verdana as the main sans-serif font, to Helvetica Neue for Mac users and Arial for Windows users. The migration to Helvetica was a small homage to the Swiss school of design who brought us such tools as grid frameworks, which we have employed in the portal layout.

Recently ‘AlcoholEdu’ and ‘Alcohol Edu’ came up in our popular searches. It’s not surprising as most of the communication for this program is via paper that is mailed to students. I know that when I was a student, paper mail got lost after I got it. A lot. I imagine things haven’t changed much since then.

Without much information about the program on our web site, searches are turning up mostly irrelevant information. The first thing we recommend is to create a page with all the information that people would need about this program (times, dates, links, etc.) and link it prominently from the department main page. The title of the created page should also be specific (“AlcoholEdu Information”) and make good use of header tags (h1) to convey to the search engines the purpose of those pages.

If people are searching for your information that doesn’t necessarily mean that you or your organization have failed in your organizational scheme. The age of search is upon us. I suspect the number of people that try to find things via navigation is dwindling, while the number who first try search are growing. There is a good chance that people aren’t even going to your site before they do a search. You need to make sure your site works for the searchers.

When that sentence first spewed forth from my frontal lobe, I was attempting to convey the advantages (at least in our heterogeneous university IT environment; unknown for others) to bottlenecking users through a single point for access to enterprise-wide applications. By looking at what might be referred to as a single point of failure instead as a single point of communication, the notion of having a single container in which to place context-specific messages about these enterprise apps is made visible.

Really, this is just a re-wording of the fundamental purpose of a campus web portal, but after our horrific experience with Campus Pipeline, significant resistance had arisen to the single gateway concept. (Some out-of-context legacy IT mumbo-jumbo about avoiding SPOFs that might have been true in the 90s fed this resistance as well.) People responsible for these other enterprise apps wanted to make sure that the non-portal avenues to their apps were widely publicized. They were questioning the reliability of the new Portal. Fortunately, with a mixture of CAS, some load-balancing content switches, and (most importantly) top-end admin/developer and network talent, those dragons were slain.

Can you spot the summer months? I knew you could! So, some obvious observations:

• Fall semester starts off with a bang. People tend to login in more than once a day during that period. This makes sense because there is a lot of schedule checking, adding, dropping, and grabbing of WebCT information.
• Summer is slow. People rarely login more than once a day.
• Spring break is a lot like summer, only shorter and probably not as warm.

So, what is the difference between logins and unique users? That’s an excellent question. Logins count all the times people login to the portal. If you login 3 times in one day, we count them all. To get a unique user count, we ignore how many times a person would login in a day and just count them once. This accounts for the discrepancy in our line plots. (*Note:* For the uportal geeks out there, we’re not counting guest sessions.)