The results

nd.edu

As part of the ND.edu redesign, we created two different designs for the emergency bar. The first is the standard “notification” that we want people to notice, but not convey a feeling of true emergency. This corresponds to the “Level One: Local and Internal” from Chas’ article.

When we really want to grab the audiences’ attention, we do two things. First, we increase the height of the emergency bar and change the color to red. Second, the feature story is replaced by the emergency notification. This is “Level Two: Local but Critical”.

m.nd.edu

Our mobile site monitors the same file, and in case of emergency the “Emergency” icon is tagged with a notification symbol. Viewing the section then displays the current message. Simple, but effective. We saw visits to this section jump exponentially during our snow closing back in February 2011.

Emergency Script

To further get the message out, we put together a javascript snippet that can exist on any university site. Each page load checks a central script, and in the case of an emergency, adds a bar to the top of the site and displays the emergency title along with a link to emergency.nd.edu. Below is an example of the Notre Dame News site in both previously mentioned states.

Level One:

Level Two:

The Payoff

The huge advantage to this approach is that we can display emergency information on dozens (soon to be hundreds) of Notre Dame sites by changing a single file. The script to display the message is available to all Notre Dame developers to include in their sites, and is a simple cut-and-paste install.

The code for Jeremy’s and my talk and the visuals for my poster presentation are up on my GitHub account Also included are Jeremy’s and my notes for the talks we attended. Slides for the API presentation are on Speaker Deck.

Access Keys

Access keys are a very simple accessibility tool to implement. By doing so, it allows users to navigate to specified sections of your site via keyboard shortcuts (alt + key on Windows, or control + key on Macintosh, although some browsers use other modifiers). So for instance, to add an access key to your header, to allow users to get back to your homepage, you would use the following:

<h1><a href="/" accesskey="1">Title of My Site</h1>

This would allow a user to hit “control + 1″ (or “alt + 1″) on any page of your site to get back to the homepage.

Now one of the difficulties with access keys is letting your users know they exist. One option is to add a title attribute alongside each accesskey, which could tip-off users when they mouse over the element for future reference, like so:

<h1><a href="/" accesskey="1" title="Homepage shortcut key = 1">Title of My Site</h1>

There are other ways to advertise access keys which I won’t get into here (see the Wikipedia entry for suggestions).

So which keys should you use you ask? That’s a great question. There’s nothing in the HTML spec indicating which keys/values should be used, but there are sets that have become widely adopted around the web. According to the UK Government accessibility guidelines, you should use the following:

I’m ok with this list, although I think it’s missing important access keys, as well as including others that I haven’t needed in, well, ever. I typically try to include access keys to the homepage (“1″), content (I use “c”), navigation (“s”) and search (“4″).

After some thought I realized that their concerns and subsequent statement was entirely our fault.

Our development process and mobile strategy in the past consisted of three things:

1. A primary design built on the 960 grid, which is client approved
2. A “webkit” stylesheet for iOS, Android and friends that completely replaced the default style
3. A “handheld” stylesheet for less capable devices

The result was a site that looked exactly like the Photoshop mockup, a second design the client might see if they visit on their iPhone or Android device, and a third that the client would probably never see. The “mobile” styles were pretty much drop-in since we follow a standard mark-up style on all of our sites, so it had little to no impact on the project timeline. However, with our recent adoption of RWD, I’ve found it’s helpful to have a little more time allotted to make sure the design responds well to different screens, and to be able to test on a variety of devices.

The problem is centered around the fact we really only explained our mobile approach to clients if they happened to ask about mobile. It’s just one of the things we included by default because it’s the “right thing to do”. But now that our approach is going to be a lot more visible, it’s time we have the conversation with each client BEFORE we enter the design stage. It’s on us to explain how designs will change and re-flow based on the window width. With a little education about the recent advances in web development, our clients will understand the benefits of this new approach affords their users. Our clients already accept that the final site will not look exactly the same in every browser when compared to the mockup. We already explain that older IE browsers won’t get rounded corners, drop shadows and some gradients.

Remember, we’re the ones that are reading the development blogs, trying all the new tricks and for the most part agree that RWD (when done right) is the future of web development. Our clients will most likely never read A List Apart. It’s up to us to be the educators and professionals we are, do what’s best for our clients, and help them to understand why we’re doing what we’re doing.

One of the basic tenets behind the internet is sharing data. Initially, that was primarily done with HTML. But with the rise of web applications, sometimes plain HTML just won’t do. That’s where API’s and feeds come in. An application with a proper API allows other applications to query it for content and get that content back in a variety of formats, be it XML, JSON, or HTML. Feeds on the other hand are a one-way distribution of data, usually in XML format.

The Problem

Notre Dame’s mobile site (m.nd.edu) is built solely on remote data. Every module draws from an external feed of either XML or javascript or in the case of the Map module, an API. This isn’t a problem since m.nd.edu is built in PHP, which has a well-established ability to fetch remote data and manipulate it. I’m in the process of converting the m.nd.edu application into a native iPhone app using PhoneGap. However, PhoneGap-based applications cannot contain PHP code. As a result I’m converting each of those modules to javascript and HTML. Unfortunately, javascript suffers from one very big drawback when it comes to consuming data… it’s only allowed to access files that exist on the domain running the script. The only exception to this is JSONP.

The Solution

The majority of the external feeds utilized by m.nd.edu are XML/RSS, so this presents a problem when the app needs JSONP. The easiest solution is to make use of a proxy script which creates JSONP from a XML feed. Here’s the rough-draft:

 <?php header('content-type: application/json; charset=utf-8'); if( strlen($_GET["feed"]) >= 13 ) { $xml = file_get_contents(urldecode($_GET["feed"])); if($xml) { $data = @simplexml_load_string($xml, "SimpleXMLElement", LIBXML_NOCDATA); $json = json_encode($data); echo isset($_GET["callback"]) ? "{$_GET[’callback’]}($json)" : $json; } } ?> 

So what we have here is fairly basic. First off, the script is set to respond with the content type of “application/json”. PHP gets the XML from the remote source, then converts it to a SimpleXML object. This object can then be converted to JSON using the json_encode() function which has been available since PHP 5.2.1. The script outputs plain JSON. If a callback function is specified, it will wrap the output in the callback. I wouldn’t recommend using this as-is in production as it’s lacking some error-checking, but it’s enough to get started. At this point, you can use it with jQuery like so:

 $.getJSON("http://yoursite.com/xml2json.php?callback=?", {feed:"http://agency.nd.edu/agencynd-team.xml"}, function(data) { // process data here } }); 

So there you have it. We can now consume remote XML data using javascript. If anyone more familiar with PhoneGap knows of an easier/better way of dealing with this kind of a problem, please share.

Update 2012-02-04

Ben Alman (@cowboy) has released an open-source solution:

• Project page for Simple PHP Proxy
• Github repo for Simple PHP Proxy