Making HTML5 and Responsive Design Work for Web Apps Like LockerPulse

When we set out to create the new LockerPulse, one of the major deciding factors in scrapping the old site entirely was the increasing fragmentation amongst web users. In stark contrast to 2009 when we originally launched, our users are now consuming their sports news on phones, tablets, laptops, and desktops, of countless physical sizes and screen resolutions. A site designed for wide screen monitors supplemented by a scaled-back mobile site just wasn’t cutting it anymore.

After evaluating all of the options out there, including developing native applications for iOS, Android, and the like, we eventually decided on building a single HTML5 web app for all platforms using responsive design.

It was quite a challenge for us to build a fully functional responsive site for an application of this magnitude. There weren’t a ton of examples for us to look at that we could use as direct proof that everything we were trying to do was possible. Responsive design also has plenty of limitations that can’t be resolved with simply just media queries.

So, we listed out a set of objectives and started chipping away, hoping that we could get everything working in unison. Thankfully, the end result pretty much met all of our criteria. Below we’ve compiled those requirements and the solutions that we used to create our desired end result.

Every Page Had to Be Responsive

If we were going to be responsive, we wanted to be 100% responsive. That meant not only the LockerPulse app, but the front-end “marketing” site where users sign up for LockerPulse, this blog that’s powered by WordPress, and even our error pages (click here for an example of a 404 page).

Here’s a look at how our home page turned out. This is the “marketing” template as we call it, which is used for registration, log in, help pages, and other informational pages. The first image is at full width, while the second is when the page is sized down to mobile size.

LockerPulse Responsive Design Home PageLockerPulse Responsive Design Home Page - Mobile Version


Now here’s what the app looks like once you’ve logged in to your account. Again, the first image is the full-size site and the second image is mobile size.

LockerPulse App Responsive Design - Full SizeLockerPulse App Responsive Design - Mobile Size


Here’s the app at tablet size, landscape width followed by portrait width.

LockerPulse App Responsive Design - Wide Tablet SizeLockerPulse App Responsive Design - Narrow Tablet Size


We’ve also made sure that each page within both the marketing site and app itself all are functional at all sizes ranging from a large high resolution monitor down to a smartphone.

It Had to Work on All Popular Browsers on All Popular Computers and Devices

Is it possible to build a modern web application that utilizes HTML5 and CSS3 without shutting out a large portion of your user base? We think the answer is now absolutely yes.

CSS3 Media Queries

CSS3 media queries get you most of the way there. Thankfully, the latest versions of every popular desktop browser – Chrome, Firefox, Internet Explorer, Safari, and Opera – all have almost full support for everything that CSS3 has to offer. Additionally, since iOS and Android both use Webkit (the same engine that powers Chrome and Safari), the majority of the tablet and phone market is also using browsers with full support. And since most of these browsers now auto-update, the percentage stuck on older versions is lower than it ever has been.

Browser Support (i.e. Supporting Old Versions of IE)

As is always the case, IE6, IE7, and IE8 are the biggest hurdles. IE8 in particular is important to support because it is the highest version of Internet Explorer that Microsoft is going to release on Windows XP, still one of the most popular operating systems in the world.

Our savior was Google Chrome Frame, a plug-in for IE6/7/8 that allows sites to render pages as if they were being viewed in Google Chrome. From a development standpoint, it’s pretty easy to set up. For IE6 users, we decided that this was all that we’d offer. If you visit our site from IE6 we redirect you to a page that prompts you to install the Chrome Frame.

For IE7/8 though, we decided that we at least wanted the marketing site to work so as to not turn potential users away. We created an IE-only CSS stylesheet using IE conditional statements to clean up a few styles and for the most part the marketing template works. If an IE7/8 user visits LockerPulse and decides that they want to sign up, they will complete registration just like any other user and only be prompted to install Google Chrome Frame upon their first log in:

LockerPulse Google Chrome Frame Usage

The process is very smooth. You click once, wait a few seconds, the page refreshes, and then everything looks and functions as if it was in the latest version of Chrome! It’s not a bad user experience at all.

Depending on your site you may have another browser beyond these that has a large enough user base worth supporting, but for us (and for most sites I’d imagine) that wasn’t the case. After our testing was complete, we also created a chart on our help page breaking down our support for all browsers.

Cleaning Up Aggregated Content

It’s worth noting that LockerPulse has some additional challenges by nature because we’re indexing content from thousands of RSS feeds, all of whom give us their own mess of HTML to work with. We start by running all of the HTML through HTML Purifier with a very specified set of allowable tags, and then do our best to use media queries to properly re-size everything from images to tables to blockquotes. Here’s an example of a story where we stripped quite a bit of formatting but still kept it readable and responsive:

LockerPulse Responsive Sports News Stories

LockerPulse Responsive Sports News Stories - Mobile

Presenting Tabular Data

Displaying large tables of data can get complex on smaller screen sizes. Our solution for this was to use media queries to hide the less important columns in tables as the screen size shrinks. For example, on our baseball team roster pages we show number, name, position, height, weight, age, experience, and salary:

LockerPulse Responsive Design Roster Tables

When this page is displayed at smaller resolutions however, we only display the most critical categories – number, name, and position – and hide the rest:

LockerPulse Responsive Design Roster Tables - Mobile

It Needed to Feel Like it Was Built for Whatever Platform You’re Using

When a user visits LockerPulse on a 1080p monitor, we wanted it to feel like it was a website designed for high resolution monitors. When that same person later picks up their iPad, it then had to feel as though it was built for a tablet, and then later on when that person is on their phone it had to feel like it was built for their phone. When it comes to touch devices, our standard is the native app. When you’re using LockerPulse it couldn’t feel as though it was some sort of lesser experience because you were using a web app and not a native app.

[Side note: to achieve much of this customizability and some of the speed performance in the next section, we use some user agent detection in both Javascript and PHP. I know that the development community sometimes frowns upon doing this, but 1) it's the only semi-reliable way of determining what type of device someone is on, which we use to increase speed, save bandwidth, and make the overall user experience better, and 2) we're using it for non-critical functionality so if it is wrong it doesn't completely ruin the user experience.]

Keeping Custom Wallpaper

One of the most popular features on the old LockerPulse was the ability to pick your own background wallpaper or to upload your own custom image. We didn’t want to get rid of the backgrounds, but we also didn’t want to resort to all of the layer trickery that we used previously. Thankfully the CSS3 background properties are now almost universally supported and we were able to keep the feature in a much more standards compliant manner.

LockerPulse Responsive Design CSS3 Image Background

This makes a huge difference when you’re using LockerPulse on a large screen. Seeing your empty screen space filled up with gorgeous high resolution images goes a long way in making you feel like LockerPulse is meant to be used on large high resolution monitors. As you can see in the responsive app images at the beginning of this post, the background stays in place for tablet users but does not show for mobile users (more on this below).

Adjusting Spacing for Touch

When the browser is re-sized to popular touch resolutions (1024px and below) we increased spacing in situations where links tend to bunch together. There’s nothing more frustrating than trying to click a link on your phone but clicking the wrong one because there’s not enough spacing between the text. A good example of this is on our rosters page. On computer resolutions where the user is likely clicking with a mouse, the team names are spaced closely together in columns:

LockerPulse Responsive Design Touch Spacing

When it comes to the touch resolutions, the spacing is increased so that the user has plenty of finger space to click accurately. It’s a simple media query but we feel like it makes a big difference for the user experience on touch devices.

LockerPulse Responsive Design Touch Spacing - Mobile

Auto-Scrolling to Content on Mobile

Mobile browsers have limited screen real estate. An app like LockerPulse has a lot to convey on any given page, and because we wanted the mobile experience to have 100% of the functionality, we didn’t want to strip anything out of the template for mobile users. With that said, we also didn’t want the user to have to scroll for a few seconds on each page load (or AJAX content refresh) to get to the content.

Our solution: auto-scroll mobile users to the start of the content. This way they’re immediately focused on what they want to look at. From there they can scroll up to find the main navigation if desired. In addition, the URL bar is hidden after scrolling so you’re adding roughly another 15% of screen real estate for the app! This is something we observed on the mobile version of Google Reader. It impressed us how much this simple change affected the usability of the application.

In this screenshot you just see the URL bar and our navigation, no content:

LockerPulse Responsive Design Without  Mobile Scrolling

With the auto-scrolling in place, the URL bar is gone and you can see the sub-navigation along with a handful of headlines:

LockerPulse Responsive Design With Mobile Scrolling

Create an “Installable” Web App for iOS and Android

Both iOS and Android have support for a variety of meta tags that allow you to customize a web app for their platform. Taking full advantage of these is one of the simplest ways to put a mobile web app experience on par with a native app experience. The two that we’ve found to be most helpful are the meta viewport tag, which allows you to control the scale of the site and whether or not the user has the ability to re-size the browser (because our design is responsive we set the scale to 1 and don’t allow the user to scale) and the apple-touch-icon tag that creates a launch icon for the home screen.

LockerPulse iOS Home Screen Icon

Still, one of the things you’re fighting against is people knowing that this is even possible (just ask the average iPhone user if they know about installing web apps to their home screen and you’ll likely get a blank stare). We did two things to try to increase the likelihood that our mobile users will “install” LockerPulse. First, we created an Apps page on our site that explains step-by-step how to add LockerPulse to the home screen so that it launches like a native app. Second, we use the iOS Add to Home Screen javascript plugin to prompt iOS users to install LockerPulse. We place a cookie on the device so that this message shows only once – on the user’s first log in to their account on the device.

LockerPulse Mobile App iOS Install Notification

It Had to be Fast

What use are good coding practices if the site is slow? The old LockerPulse wasn’t bloated enough to affect a desktop user with high speed access, but it certainly was for someone accessing it on a phone using a data connection. And since mobile users would no longer be served a dedicated mobile site, we needed our one single site to be as fast as possible.

Using YSlow as a Measuring Stick

YSlow is a browser extension that measures speed and performance of websites based upon 23 rules that Yahoo!’s Exceptional Performance team has identified. Examples include “minimize HTTP requests”, “make Javascript and CSS external”, and “avoid redirects.” LockerPulse scores an “A” on 20 of the 23 rules (21 of 23 if you factor out external Google scripts for things like Google Analytics). If we were to add a Content Delivery Network, something we plan on doing as we grow, we would score a 23 out of 23. These rules are rules that all web developers should be familiar with.

Minimizing Requests

YSlow’s #1 rules is to “minimize HTTP requests.” The old LockerPulse did a pretty bad job of this. While there are some things that are out of our control (for instance, images from stories that show in a user’s news) there is plenty that is within our control. Our first move was to ditch the somewhat outdated Javscript library in favor of the lighter-weight, more powerful jQuery. We only have two Javascript requests, which are the same for every page on the entire site: the minified version of jQuery and our custom Javascript, which includes any jQuery plug-ins and is also minified. CSS is now minified and entirely contained within one single request. We use the YUI Compressor to minify our scripts.

CSS sprites are also used in place of images wherever feasible. A good example is the icons that show beside our stories. Instead of 40+ images, they’re all contained in one single image.

LockerPulse Responsive Design - CSS Sprites

Caching Images, CSS, and Javascript

Once we reduced the number of requests and minified the files being requested, it was important to configure expiration headers to a “far future date” so that the user doesn’t have to request the same file each time they visit the site. This decreases requests, saves bandwidth for both us and the user, and increases speed. This is relatively simple to configure within a .htaccess file.

One problem arises when doing this though. When a change is made to your code, you need a way to tell the browser that a change has been made so that they request the new file, otherwise the browser will continue to use the old cached version until it expires. The simplest method involves iterating a version number in the file name. For instance, our CSS stylesheet located at is actually requested as When we make a change, we simply iterate to The browser views this as a new file and will then request it. Setting this up requires some basic URL rewriting, described in more detail in this article. There is also a similar technique that is simple to set up on WordPress blogs.

Don’t Load Background Images on Mobile

I mentioned above how important those high resolution background images were to the desktop experience. They’re equally unimportant to the mobile experience so we wanted to make sure that we weren’t loading these gigantic images on mobile. When we detect a mobile device we show just a solid blue background instead of loading a background image. Since mobile devices show the site at 100% width without the background being visible, we’re saving a significant amount of bandwidth and improving the speed without compromising functionality. This is one of the weaknesses of media queries in general. Ideally this could be accomplished with just HTML and CSS, but for now some simple device detection in PHP gets the job done.

AJAX + HTML5 History API

AJAX can speed up the actual speed of a site because you’re only adjusting the portion of the page that changes, while also increasing the perceived speed to the user because they don’t have to suffer through an entire page refresh. Throughout the LockerPulse site we try to use AJAX wherever applicable. In particular, the app itself is almost exclusively AJAX, making the experience much faster for a power user.

One of the big deterrents to using AJAX has always been that it “breaks” the URL bar. If someone bookmarks a page it’s unlikely to return to the same “state” the next time they visit. This was initially partially solved by the “hashbang” solution that Twitter is infamous for using, which we implemented in 2010 per Google’s proposed standards. With HTML5 though, there’s a new Javascript feature called PushState that solves this problem. It allows us to change the value of the URL using Javascript (not just what’s after the # symbol). Take a look at the screenshots below for an example. In this case, when the user clicks the “Detroit Lions” from our NFL team page, the only things that change are the URL and the outlined content. Nothing else on the page is reloaded or requested again.

LockerPulse HTML5 Push State Before

LockerPulse HTML5 Push State After

We take advantage of this for any browsers that support it. For browsers that don’t support it, we fall back to the old hashbang method. We use it primarily on publicly accessible pages (as opposed to those behind a log in) but hopefully it will be used 100% across our site (and all sites) in the near future.

Optimizing the Server Side

This post is really intended to be about HTML5, CSS3, and responsive design, but I’d be remiss if I didn’t at least mention the importance of the server side. Doing things like optimizing MySQL queries or adding RAM have had a greater affect than any of the above. We’re off to a good start, but we’ve still got a long ways to go to optimize the client side and server side for absolute peak performance.

It Had to be a Consistent Experience on all Devices

This is where I think responsive web apps have a huge advantage over the fragmented nature of native apps. Have you ever tried to go from using Twitter on your desktop browser, then to an iPad, and then to your iPhone? It’s gotten better, but each app feels and performs entirely different. There’s a learning curve. Some features don’t perform the exact same way on each. I find that very frustrating. By building one single experience you eliminate almost all of that. I use LockerPulse about 1/3 of the time on my Windows 7 laptop, 1/3 of the time on my iPad, and 1/3 of the time on my Samsung Galaxy SII and everything about the experience feels completely equal. It’s neither better nor worse on one platform over the other. There’s no learning curve when you try it on a new device. It gets out of the way so that you can get your sports news.

It Had to be Easy to Maintain

We’re a small team. Myself and my business partner Mike did all of the design and development work on the entire site. LockerPulse isn’t even our primary business – we own an e-commerce company that takes up the majority of our time. We needed to build something that was easy to maintain. When we fix a bug, we only want to fix it once. When we add a feature, we only want to build it once. Maybe most importantly, when we change something we want it done immediately so that our users reap the benefit immediately.  What we don’t want is to have to wait for an app store to approve something we did. Developing for solely the modern browser is the ultimate “build once, deploy everywhere” experience. The time savings are incalculable. Our entire team can now focus much more of our time on marketing the site, connecting with our community of users, and everything else that’s necessary to run a successful business.

This Included Our Ads Too

One of the coolest parts of the new LockerPulse is our ad platform. We look at our user’s favorite teams, favorite players, and approximate geographic location to serve them offers for clothing, memorabilia, tickets, books, movies, and more, from places like Amazon, eBay, and Nike. These too had to be responsive:

LockerPulse Responsive Design Ads - Full Size

LockerPulse Responsive Design Ads - Tablet Size

LockerPulse Responsive Design Ads - Mobile Size

When users are logged out and viewing news, we’re currently showing them AdSense, which is not responsive. Again, we do a little device detection to guess the best size ad to show them. If they’re on a computer, we show a 728×90 banner, if they’re on a tablet we show a 468×60 banner, and if they’re on a mobile device we show the 320×50 banner that’s become standard for mobile ads. It isn’t always perfect, but it works relatively well and generally preserves most of our responsiveness.

In Closing

In the end we couldn’t be happier to be one of the first in sports industry (or anywhere for that matter) to build a web app of this magnitude using HTML5 and responsive design. If you have any questions for us or if you’d like us to elaborate on any details let us know in the comments below.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>