Pragmatic Emergency Preparedness

“This is the Director of Public Safety. We’ve got an emergency. Can you put a message up on every page of the site?”

The idea of such a phone call began to haunt my thoughts after the shootings at Virginia Tech in 2007. I knew how to make quick changes to our site, and I knew how to make broad ones, but I didn’t have a good way to do both at once.

There are several phases to emergency response on the web. The next day, an institution may switch to a more a somber web design which responds directly to the circumstances. The next hour an institution may switch to a lighter, more responsive web presence that can handle the traffic of a national news event. But in the first 15 minutes while an emergency is still evolving, it’s possible for rapid communication to change the course of events and help to keep people safe. How can we facilitate this rapid communication?

A Pragmatic Solution

The best way to be ready to post an alert message on every webpage is to post an alert message on every webpage. The technique I recommend is:

Step 1: Create a small text file to contain emergency alert messages.

This should be a simple file, and it should have a convenient, central, and canonical location. For the purposes of this article, let’s assume the text file is located on the primary webserver within the web document root folder at

include/emergency/alert.inc

When there’s no emergency, I recommend that this file contain an HTML comment:

<!– alert.inc –>

An HTML comment has two advantages over an empty file. First, it’s simple to verify that the comment is present in the HTML source code for a page, confirming that the system is working. Second, an empty file may cause problems with some inclusion mechanisms.

When an emergency exists this file is changed to include a notice:
<p>Alert: Tornado</p>

Step 2: Include this file in every page.

You probably have more than one type of website, service or application where you’d like this message to appear in the event of an emergency. There are various ways to facilitate this (and example code will be provided below) but first you’ve got two details to take care of:

• Make sure that the message file is present in each of these environments. If the filesystem containing the master copy of the file cannot be made locally accessible then you can utilize rsync or similar utilities to maintain a child copy—just be sure that it is always up to date.

• Choose where in each type of page you want to include the file. Immediately inside the openingtag is a good place, or perhaps inside a wrapper. You’ll have to decide whether it’s best to use inline CSS in the message file or to put appropriate style rules in each environment.

Once these matters are accounted for you can set up the inclusion itself. The various techniques for doing so fall into several broad categories:

• For pages which are dynamically rendered upon each page request (e.g. WordPress, Drupal, ASP, PHP) you can use the facilities offered by the platform or framework responsible for the rendering.
• For pages which are served up as static files your best choice is probably server-side includes (SSI). If this is not practical in your particular situation then consider options for including the alert file client-side, using JavaScript tools if they’re already a part of your site, or even an iframe.

Note that these approaches can also be divided into server-side (SSI, platforms, and frameworks), in which the message is inserted into the page before it is sent to the browser; and client-side (JavaScript and iframes), in which the message is inserted into the page by the browser after retrieving the message via a separate HTTP request.

Then, in an emergency…

Just edit the text file to post an alert. Note that you may also need to reset any server-side cache to make sure the updated message text is delivered.

And don’t forget to tell people about this new capability. Make sure they know what’s possible, and work with the emergency communicators at your institution to plan on when, how, and by whom this alert system will be used.

Examples

Server-Side Includes

Server-side includes are available on all major web servers via various modules or options. SSI must be enabled for files of a certain type (often .shtml)—in this case you need to make sure all HTML file extensions support it. Using SSI the contents of another file can be included in a page with a directive such as
<!–#include virtual=”/include/emergency/alert.inc” –>
Consult your documentation on whether your needs call for “virtual” or “file” includes. There is some performance overhead for SSI processing, but never fear: you are very likely already incurring worse elsewhere in the chain.

Platforms

Platform approaches tend to be extremely similar to server-side includes (right down to virtual vs. file includes) but note that they are likely to be mutually exclusive solutions for a given portion of your web presence.

PHP

<?php include (“/include/emergency/alert.inc”); ?>

ASP

<!–#include virtual=”/include/emergency/alert.inc”–>

CFML

<CFINCLUDE template=”/include/emergency/alert.inc”>

JSP

<jsp:include page=”/include/emergency/alert.inc” />

Velocity

#include( “/include/emergency/alert.inc” )

Frameworks

Drupal

See PHP (in Platforms) — you can use PHP include() in your Drupal theme or module (you can also enable PHP in nodes, but this is a risky practice).

WordPress

See PHP (in Platforms) — you can use PHP include() in your templates.

Joomla

See PHP (in Platforms), or if you know that you’re doing and you lock it down appropriately, look into the includePHP plugin, which is used like this:
{htmlfile}/include/emergency/alert.inc{/htmlfile}

Symfony

See PHP (in Platforms) — you can use PHP include() in your templates.

CodeIgniter

See PHP (in Platforms) — you can use PHP include() in your views.

Rails (ERB)

<%= render :file => ‘/include/emergency/alert.inc’,
:layout => false %>

Rails (HAML)

= render :file => ‘/include/emergency/alert.inc’,
:layout => false

Sinatra (ERB)

Tilt.regsiter Tilt::ERBTemplate, ‘inc’
…
<%= erb :’/include/emergency/alert.inc’,
:views => ‘/’, :layout => false %>

Django

{% ssi /include/emergency/alert.inc %}

Express (EJS)

<%- partial(‘/include/emergency/alert.inc’) %>

Express (Jade)

= partial(‘/include/emergency/alert.inc’)

Client-Side Solutions

Consider these simple examples a starting point. Much more is possible.

Note that client-side solutions are limited by the same origin policy, requiring some adaptation if the message file cannot be loaded from the same origin (protocol, host, and port) which served the page. A common workaround in this case involves setting document.domain appropriately in the included content—in this case it would have to go in the message file itself.

jQuery

$(function() {
$(‘#alert’).load(‘/include/emergency/alert.html’);
});
…
<div id=”alert”></div>
Also look into .ajax() (in place of .load()).

Prototype

new Ajax.Updater(‘alert’, ‘/include/emergency/alert.html’,{});
…
<div id=”alert”></div>

JavaScript

Doing this in a sensible cross-browser fashion without a JS library takes more code than we’ve got room for here. The short version is that you

• Create an XMLHttpRequest object (details vary by browser)
• Connect to the server, for example:

• xhr.open(‘get’, ‘/include/emergency/alert.html’, true);

• Check for success,
• Process the result, and then
• Insert it where you need it:

• document.getElementById(‘alert’).innerHTML = alertMsg;

Inline Frame

If all else fails, you can use an iframe:
<iframe src=”/include/emergency/alert.html”></iframe>

Objections

Why a text file?

Because not every page is likely to be generated from a single database system. You’ll know if you’re one of the exceptions, and in that case you can certainly consider simply working with the tools of that system. You’ll also know if you want to consider pushing the alert text file into such a system (via direct database access, web services, API, or other means).

I have no support to get this done!

If you’re in communications and lack support on the technology side (filesystem mounting, file synchronization, etc.) then put your alert file somewhere you do control and pull it into your templates client-side with JavaScript or an iframe.

If you’re in technology and the emergency communications folks aren’t including you in the planning process then make your alert file available across every system you can reach and include it at as low a level as you can utilizing SSI or platform functionality.

Either way once it’s there make sure you tell people about it. A working, existing solution tends to win, and an emergency alert system is more valuable the more key people know it’s available.

But this solution won’t reach everybody (or every page)!

It doesn’t have to. The wider your reach, the better, of course, but remember that anything you do is going to reach more people than no solution. Don’t let the perfect be the enemy of the good.

But who’s going to edit the alert file, and how?

This will depend on circumstances at your institution. Even a root-owned include file or a communications-controlled file on an external server is better than no alert system. Any system at all for putting the file in control of the right people (public safety officers, emergency spokespeople, key administrators) is to be celebrated, but if you can publish an alert when one of these people calls you, that is already a huge success.

Next Steps

Once you’ve got a solution like this in place there are several things you can work on.

First, of course, make sure that the key people involved in emergency planning and communication know you’ve created this capability, and be prepared to remind them in an actual emergency.

Identify the individuals who can make the call to enable an alert message. In addition to the official emergency communicators this list will ideally include one or more of the web professionals who can directly edit the file. But make sure that those who may edit the file all know who is authorized to call for its use.

Strive for an environment in which the file’s editors themselves are given the authority to post a web alert when an institutional alert has already been distributed via other means, or to adapt the wording of the web alert (e.g. to eliminate ambiguity as time passes after the initial posting).

Stand firm against using this alert capability for anything but true emergencies. The presentation (both location and style) of emergency alerts should never be confused with more routine general announcements and notifications.

---

In an emergency, people come together as quickly as they can to coordinate communication and response, but this does take time. This solution allows for rapid, broad changes by an individual web professional. When the situation merits it’s possible to get an urgent message out now. If the gathered team wants to reword the message, change it. It’s just as easy to revise or remove as it is to post.