I built a library website using jQuery Mobile, starting with Jason Clark’s template & tweaking it as I went. I created a genericized version which is available for download & reuse on Github: just click the “ZIP” button to download the whole template. I’ve also used Github Pages to display the template so you can test drive the site to see what it’s like. I will keep it on the latest stable versions of jQuery Mobile & perhaps make occasional improvements as well.
App vs. Web
I chose to work with a mobile website for several reasons. First of all, I am more familiar with the requisite skill set of the web than I am with native applications: I know HTML & CSS well, have a small but growing knowledge of JavaScript, but Objective C & Java are alien to me. Secondly, mobile sites are “write once, run everywhere” & don’t present the versioning headaches that catering to many different devices does. As Android & iOS issue new releases & other platforms (from the Android-based Kindle Fire, to Windows Phone, to the now-open-source WebOS) gain market share, the number of updates to keep any one piece of software running will only increase. By working with the jQuery Mobile framework, I can ensure that my code has been tested on all sorts of devices I don’t have access to & renders properly. Finally, anyone can put up a website if they access to hosting, but submitting an app has associated fees.
It’s also worth noting that building a separate mobile site is really a compromise; arguably, your entire website should employ a responsive design that works equally well on mobile & desktop devices. However, some institutions cannot overhaul their entire site easily (my current one included) & a separate mobile site definitely serves a purpose. In particular, it is far easier to serve a reasonable amount of content with a separate site while serving a desktop site with a bunch of {display:none;} images to a mobile browser is unbearably slow.
Design Considerations
A mobile site isn’t just a miniature version of a desktop one, so here are some principles I worked with.
- Integrate with Other Mobile Sites - the “online resources” section links to mobile versions of LibGuides, library databases (EBSCO has a mobile profile for all their resources—just change the profile parameter in the URI from “ehost” to “mobile”), & other websites. The biggest limitation here is your library catalog: does it have a mobile-friendly view? Ours doesn’t, so it’s a jarring transition for users.
- Integrate with Smart Phone Services - much of this occurs on the “Ask a Librarian” page, where the sms protocol will open a text message app (like “Messages” on iOS) & the tel protocol will do the same with a phone number. But one can extend that principle to any app: are you recommending apps on your mobile site? Have them open in the appropriate App Store. Use of geolocation services also falls in under this principle.
- Buttons & Not Links - anything requiring user interaction needs to be finger-sized so I’ve made extensive use of buttons throughout the site while eschewing hyperlinked text.
- Allow Full Functionality - a mobile experience shouldn’t be truncated; I let users head back to the desktop site if necessary. Ideally, all your content would be available in a mobile-friendly view.
Performance Optimizations
As I discuss briefly in the genericized template, mobile websites need to be even more considerate of connection speed & device limitations. Users might be on weak cellular connections or on devices with less power than a conventional laptop. Thus there are a lot of optimization measures that become quite vital to a mobile website’s success. There are two basic goals to optimization: reduce total file size transferred & reduce the number of HTTP requests.
- Code Minification - all JavaScript, CSS, & even HTML should be minified on the production version. There are lots of tools available to help with this step, from the HTML5 Boilerplate Build Script to htmlcompressor.com.
- Inline All the Things - CSS & JavaScript can be contained in your HTML inside of
<style>&<script>tags which reduces the number of HTTP requests. You can also considering inlining images by base64-encoding them in a data URI, which helps some of the time. - Image Optimization - there’s lots to be said about this topic. My main approach to dealing with images on mobile is simply to avoid them entirely & that’s easy with the advanced features of CSS3. But if you do use images, make sure that mobile users get an appropriately sized image, that the image is run through an optimizer like Yahoo! Smush.It or ImageOptim, & that icon-like images are combined into a single sprite to reduce HTTP requests.
- Caching - on the server side, send your responses with expires headers so that content is cached & turn on GZIP if you can. Beyond that, you can dig into the HTML5 Application Cache which gives you control over which files are cached & which are only available over a network connection.
There’s more to cover here in terms of UI responsiveness—making sure your scripts are efficient, that actions are greeted with immediate feedback—but particulary with a simple website & not a web app your focus should be on reducing file size & HTTP requests.
Redirecting Mobile Users
I wrote a couple of blog posts that cover most of my thoughts on pushing mobile users over onto the mobile site. It is important to redirect mobile devices over to the experience designed specifically for them but most implementations pose problems. In general, I would say there are two primary mistakes that need to be avoided: the “do nothing” approach & any UA-sniffing approach.
“Do nothing” means, essentially, you throw up a link somewhere & hope users will find the site on their own. Even if you’re doing complementary marketing, this is not an aggressive enough approach. Users shouldn’t even have to know a mobile-specific experience exists before they use it. With a redirect in place, you can turn that one-time visit when a user just wanted to see one quick fact into a loyal, repeat visitor who relies on your mobile website to get things done on the go.
Secondly, every browser comes with a “user agent” string that looks like a lot of gibberish with a couple recognizable browser brands thrown in. Here’s an example of Apple’s Mobile Safari UA-string:
Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3
Many web developers try to use these strings to determine the capabilities of a device & then make a tactical decision on what functionality to reveal to it. There are some very good scripts out there—such as Detect Mobile Browsers which has downloads in JavaScript, PHP, Python, (Ruby on) Rails, & just about every other language out there—to help you in implementing a redirect. The problem is user agents change, new devices appear, & someone will always be left out. UA-sniffing is not a future-proof approach.