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.

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

Anyone who owns an iPhone 4 has experienced the beautiful new Retina Display. Text is amazing, colors are vibrant, but apps and sites that are not updated to handle this display usually look less than stellar. This is because the Retina Display, which has a display that is twice the resolution of most devices, scales images up so they appear to be the “correct size”. The solution to this is to target these devices using a media query and replace the graphics with a higher-quality version.

Use case: m.nd.edu

My first opportunity to work with and fix this issue was for m.nd.edu. The first step may also be the most difficult. Through trial and error I worked with our designer Jim Gosz to re-create the entire interface in both standard and double resolution. For this article, I’ll focus on the home-screen icons, displayed here at double the size to accommodate the Retina Display. Below is a screen-shot from the iPhone 4 simulator which shows how the images appear pixelated due to scaling.

Bring in the Big Guns

The original icon size on the home-screen is 57×57 pixels. For the Retina Display, Jim created additional icons at 114×114. I chose to follow the naming convention Apple uses in its SDK to target the high-res images by adding the suffix “@2x” to the file-name. So for low-res devices, if the standard icon is “icon-news.png”, the RD devices would be “icon-news@2x.png”. To get these into the mix, I added a media query into the css file that targets the Retina Display:

@media all and (-webkit-min-device-pixel-ratio: 2) {
    #home-news a {background-image:url(images/icon-news@2x.png);}
}

However, after refreshing the screen, the images look like this:

Obviously not ideal. This is where the background-size property comes in. By adding

#homenav li a {background-size:57px 57px;}

to the Retina Display portion of the style-sheet, the 114px images will display at 57px and thereby make everything appear at the proper scale. The background-size property will also accept “auto” as a value. So I could have used “background-size:57px auto;”. With this in place, the icons appear as below:

I think we can all agree that looks much better. Is this something I’ll use on every site I build? Probably not. Creating multiple versions of each graphic is labor intensive. But for mobile specific sites, it’s definitely worth it. Especially since we’ll be seeing more devices arriving soon with similar screens.

Copy, Paste and Tweak Your Way to Mobile

First off, create an empty your mobile stylesheet and link it up:

<link href="/css/mobile.css" media="handheld" rel="stylesheet" type="text/css" />

Grab your print styles and paste them into your mobile stylesheet. You’ll need to take a few of the items you hid (such as navigation), bring them back and give them some style. As with print, focus on what’s important to this user experience and hide what’s not.

Branding is Still Important

We’re going to use the same in-line images we included in our print stylesheet to brand our mobile site. How you have them set up in your print style may be all you need. If not, feel free to use "width" on them to make them fit. I typically recommend against using css to change the height/width of images, but I make an exception in this case.

Images

Since most of your content images are going to be wider than the screens of most phones, you should add max-width:100% to images in your content.

Text

One of the first things a basic mobile user should see on your page (either immediately preceding or following the header) is skip links. This is a list of anchor tags to key elements on your page. At a minimum, it should include links to navigation and content. As an added bonus, these links are helpful to screen readers as well. Be sure to hide this list in your print and screen stylesheets.

When it comes to body copy on the web, there has been a long-standing serif vs sans-serif debate. As a personal preference, I usually go with sans-serif for screen body copy (serif for titles), and serif for print. If you look at my print stylesheet, you’ll see the following font stack:

Georgia, Times, "Times New Roman", serif

For screen and basic mobile, I’m using:

"Lucida Grande", Lucida, Helvetica, Arial, sans-serif

And Off We Go

If recent trends tell us anything, it’s that an increasing percentage of web users are going to be accessing our sites on small screens. As developers, it’s our responsibility to to give at least a passing nod to these users and give them a pleasant experience. Offering basic mobile styles is the first step.