skip to main content

TAMU Webmaster's Blog


Information and insight from the A&M Webmasters

Code Maroon

Code Maroon Test

FYI…
Code Maroon’s hardware and software will receive a major upgrade. To ensure the newly upgraded system is functioning properly, the CIS Code Maroon team will test the system on Friday, May 17. The usual drill scheduled for the last Friday in May will be suspended if early testing is successful. Additional tests may also be needed in the coming months. The Code Maroon team apologizes for any inconvenience this may cause.

Wednesday, May 15th, 2013 Code Maroon No Comments

Emergency Notice Publication

We have crossed a milestone this week.  We now have Code Maroon alerts automatically published to not only the emergency information site, but to the main university site and the mobile site as well. The exact methodology for each site was a bit different, but the first two rely on web services built into the Hannon Hill Cascade web content manager.

The problem was brought to us after the last Code Maroon incident two months ago.  The event occurred over the lunch hour, and the person who normally entered the Code Maroon message into the sites was unavailable.  This led to about a 10 minute delay in getting the information onto the web sites.  The emergency team decided in their after-action meeting that the process should be changed and alerts posted automatically rather than manually.  This led us to examine our options and try to come up with a best solution.

Whenever a Code Maroon alert is issued, it triggers the publication of an RSS feed on the Code Maroon website.  This is considered the authoritative location for the anyone who wants to retrieve the alert notification.  The first step, then, was to set up a cron job that would monitor the feed and note any change.

The easiest of our web sites to update to automatically publish the information was actually the mobile site.  It runs on PHP, so it was no problem to have the site read the contents of the RSS feed and publish the results to a static include file on the server.  The page logic would then include this file and display any alert that had been issued.

The emergency site and university site were more complicated.  Both sites are simple, static HTML.  We intentionally do not even run PHP on the server, so using the site’s internal programming to pull in the alert was not an option.  We do not even run server side includes on these sites in an effort to maximize efficiency.  The content for both is handled by a CMS, so common includes are not something needed to make page editing easier.  This, then, eliminated running any kind of cron job to update an include file.

We also eliminated javascript/ajax as an option.  This is actually how the Code Maroon website works.  It uses ajax to querry the RSS file and write the information into the page dynamically.  This wasn’t an option for us on either site.  The emergency site was set up purposefully to be very lean.  It includes only HTML, CSS, and a single sprite image.  We designed the site like this because of its nature as the emergency information location.  We don’t want to drop traffic during a crisis, and having to load something as heavy as jquery could easily cause a site to fail during a traffic spike created by a large public crisis event.  While www.tamu.edu does include jquery we decided that we wanted to handle both sites in a similar process if possible.

Another reason we stayed away from a dynamic content insert or include file was that we wanted to be able to maintain an audit trail of all changes.  After an event there is always a post-mortum of the process, and we need to be able to go back and look at exactly what was published at a particular time.  This information gets lost if it is simply embedded directly into the web site.  What we needed was something that would create a permanent record of the alert being issued and published.

At this point we knew that our content management system was the only element of the publication workflow that would be able to offer a viable solution.  Our first thought was to have Cascade simply pull in the RSS and publish any new updates.  It became quickly apparent, though, that this approach was overly simplistic.  Yes, it would create the archived record that we were looking for, but in order to make the page auto-updated we would have to republish the page every minute in order to have it pull in and read the RSS.  Technically possible, but not a direction we wanted to take.

We finally settled on a little used feature of Cascade server – its built in web services.  Cascade allows external scripts to authenticate into the system and send commands to update content and even publish pages via SOAP.  This was the perfect solution for us.  We could use our original cron script to monitor the Code Maroon RSS feed, and then if it detected a new alert message we could have it process the message into the HTML that we wanted to see on the page and then pass it along to the web service in a SOAP envelope.  In essence the contents of the SOAP envelope authenticate into the CMS, tell it to edit a particular information block with the content that we provide from the RSS feed, and then publish the page.

The emergency site was very straightforward to add this logic to, and it was done in only a few days.  The university site was a bit more complicated because of the structure of the site within the CMS, but even still we were able to have the SOAP identify the proper edits to make and then publish the site.

Everything works fine in our testing, but of course the ultimate test will be when CIS publishes their monthly Code Maroon test.  If everything goes well you should see the test message automatically published onto emergency, www, and mobile.

Wednesday, October 17th, 2012 Code Maroon 2 Comments

Post-Emergency Summary

Yesterday’s off-campus shooting incident triggered the launch of a Code Maroon and set us into emergency response mode.  While the incident was relatively short-lived, it did nonetheless generate nation-wide media coverage, which in turn generated heightened levels of traffic to the university website.  We are pleased to say that our server architecture held out quite well under the increased load.

Anecdotally, Help Desk Central reported that they did not get any complaints about the site being unresponsive, and CIS system administrators said that the hardware ran smoothly throughout the process.

According to our analytics, the www.tamu.edu site generated 234,450 page views yesterday, while the average is more like 75,000.  Over 67,200 of those came in the 12:00 – 1:00 time frame, with another 50,000 in the next hour.  The index page itself took 172,900 hits, and the “active shooter” emergency response procedures took another 10,900.  The About Us and University Facts pages also experienced higher than normal traffic, indicating that people unfamiliar with the university were looking to find out who we are.

Most of the page visits came in from one of the major search engines.  Huffington Post was the only one of the national media outlets in the top-10 referrers, and their numbers were negligible when compared to Google, Yahoo, or Bing.

The Code Maroon message at the top of the page referred 25,400 click-throughs to the emergency notification site. Unfortunately that’s all we can say about traffic to that site.  We purposefully do not run Google Analytics on the emergency site. Emergency situations by their very nature are likely to generate extraordinary page loads, so we are willing to live with reduced information in order to better guarantee proper uptime in those circumstances.

My thanks to everyone across campus who helped us put this emergency structure in place.  I know we still have room for improvements, but we held up to a major test yesterday and didn’t crack under the pressure.

 

Tuesday, August 14th, 2012 Code Maroon No Comments

Code Maroon and Twitter

Each semester we test the Code Maroon system out. We do so to benchmark the service as well as use it as a reminder for those not on the service to sign up for it.

Recently, e2Campus (our service provider) added functionality for Twitter. So we’re going to “unofficially” test the Twitter component on this next test which is tentatively set for Tuesday, Feb. 17. If you want to be part of the Twitter test, all you’ll need to do is to follow “TAMUCodeMaroon” on Twitter (assuming you’ve got or set up your own Twitter account). In addition to following TAMUCodeMaroon, you can also get it to your phone by turning “device updates” on

We see a real benefit for Twitter because it allows us to extend the CM test beyond campus account holders. This way, those outside the university who might be affected by a campus incident (visitors, those living adjacent to campus, local emergency organizations, vendors/techs coming to campus) can get these emergency notices without having to have an official Code Maroon subscription.

For this test, we’re not going to broadcast the Twitter option on the CM website, nor will the after-test survey ask for feedback on the Twitter send. I’ll post again here on the blog as soon as the test happens. If you have feedback regarding the Twitter component of the test, feel free to comment and we’ll go from there. If it works as well as I hope, then we’ll look at integrating the Twitter component into the marketing materials, information resources, FAQs, website, etc.

Tuesday, February 10th, 2009 Code Maroon 1 Comment

Code Maroon update

As most of you probably saw, heard or were notified, the Code Maroon system was tested out. After emails from Dr. Davis and the Code Maroon team, PSAs by Steven McGee, stories in the Battalion and on local TV stations, we reached over 30,000 subscribers to the system.

Based on feedback from our test sample/group:

  • Almost 90% success rate for text messages
    • Average delivery time was 13 minutes
    • 95% of those receiving a text message got their message in 20 minutes or less.
    • 65% of those received their text message in 15 minutes or less
  • 100% of email received
    • Average delivery time for email 33 minutes
  • 17 support calls to Help Desk Central, 23 support tickets

Now while 90% is pretty good, there were still a number of dropped text messages and the folks over at Telecommunications are looking into the issue with sample numbers of those who didn’t get the text message and from different providers.

This was a good first test, but what’s also important to realize is that we ran the Code Maroon test in essence, in a vacuum. Typically, in the event of an emergency, Code Maroon would not be the only mechanism for notifying people. The Task Force on Campus Emergencies is working on a number of methods and mechanisms to get information out to the campus community in a more integrated fashion using a number of high tech and high touch means.

Thursday, October 11th, 2007 Code Maroon, Ongoing Projects No Comments

Code Maroon and the Fall

With Code Maroon now being completely powered by e2Campus (all the data has been imported) we will be beginning several pushes.

  1. We will be sending out targeted email to those who were in the group of subscribers that were imported into the e2Campus system. For those subscribers, we generated usernames and temporary passwords so that they can access their info in the e2Campus system. The email tells them to go in and change their username/password as well as verify their information.
  2. The Communications Group will be working to increase enrollment in the system using a number of means from email and posters to presentations and video spots.
  3. Once the hoopla of the beginning of the semester dies down, the university will be sending out a test message over Code Maroon to make sure the system is working correctly. Staff from a number of groups will be assessing the distribution and metrics behind the message to ensure optimal results. The plan is for this test to be a semester or yearly occurrence. These test messages will be preceded by communication through email, ads, etc. so there will be forewarning.
  4. Results from subscriptions, responses from communication efforts and feedback from the test messages will be analyzed and used to further strengthen the university’s ability to communicate information quickly in the event of an emergency..
Monday, September 3rd, 2007 Code Maroon, Ongoing Projects No Comments

Code Maroon Milestone

This morning we updated the Code Maroon site.  Registration to the service now goes directly into the vendor system instead of our own databases.  The next step in the process is to export the information already collected to the vendor for inclusion in the system.

Monday, June 18th, 2007 Code Maroon, Ongoing Projects No Comments

Categories

Archives