Mobile Web Development Strategies

Mobile devices have come a long way in the last few years. As powerful as their desktop counterparts, mobile devices are profoundly different with touch screens, GPS, accelerometers, cameras, and other sensors, not to mention smaller screens. So many differences demand an entirely different experience. We then have the challenge of bringing those designs to life in a sustainable, maintainable, and effective way. We use several key strategies including device detection, progressive enhancement, and responsive design.

Device Detection allows the web server to know which particular device is being used, and to serve up an entirely different web page for that device. Going to the same web site could give you something completely different whether you are on your laptop, iPad, your brand new Android phone, or that old phone from several years ago that allegedly has Internet access. You could build one website for all, but chances are it would only look good on one of these devices. Device detection lets you target each one separately, for its own unique experience. Not only can you target all mobile devices globally, but you can actually target each specific type and version, from iPhone 3 to Blackberry 6.

Device detection by itself has a major drawback. There are hundreds of possible devices out there, making it costly to build corresponding websites that would be difficult to maintain. Responsive Design is an alternative to this. One website is created that morphs according to the device’s screen width. For instance, a desktop may show a three-column-wide layout, whereas these columns would be stacked one on top of each other for mobile. Responsive design works great for static content. It starts to show some limitations with rich web applications.

Among the many mobile devices out there, screen resolution is only one of the differences. Rich web applications require the use of javascript. Progressive Enhancement checks for javascript support, and if found, adds extra style and functionality that only javascript can give. Older phones will get a basic experience while newer smartphones can utilize modern technology.

So which of these strategies is the best one? Well, that entirely depends on what you’re trying to build, and you don’t have to pick just one strategy. You could use device detection to send the user to a mobile version that uses progressive enhancement, but this is just one possibility.

http://coding.smashingmagazine.com/2009/04/22/progressive-enhancement-what-it-is-and-how-to-use-it/

http://www.alistapart.com/articles/responsive-web-design/

Issue with $(document).ready() on jquery mobile

One of the first things a developer learns with jQuery is the use of the document.ready function.  It’s a good place to initialize your scripts well before all of the images are loaded in the onload event. A  jQuery mobile site on the other hand works differently.  It’s a single page application, meaning that each of the screenviews aren’t individual “pages” in the traditional sense, but multiple screenviews loaded into the DOM at once.  It’s what allows jQuery mobile it’s fancy and responsive transitions.  It’s a nice feature, but where do we initialize our scripts? Well, we put them in the pageinit event like this.

$( '#myPage' ).live( 'pageinit',function(event){
alert( 'This page was just enhanced by jQuery Mobile!' );
});

The #myPage selector is for a specific page. If you want your pageinit globally use the ‘div[data-role=”page”]’ selector. To bind make sure you use the .live instead of the .bind method. This will insure all future pages that haven’t been created yet get the bind as well.  Prior to the beta 2 version we used the pagecreate event instead of pageinit. A change was made in that version to bind jQuery mobile’s widgets with the pagecreate event. Pageinit comes after the widgets have been initialized so it will typically be the one you want. If you’d rather call a script before the widgets you should use the pagebeforecreate event. The pagecreate should rarely be used.  The only reason I could think of using it, is if you’re trying to create your own widgets for the framework.

Simplifying vs Complicating Performance Optimization

Simplifying your code for performance can and should be done throughout development. Complicating your code for performance should only be done after profiling has been done and bottlenecks have been identified.

During the entire development process it’s good to constantly refactor.  Reducing all extra steps and other cruft in a programs logic can not only improve performance but it makes your code more readable and decreases file size.  Reducing it to it’s poetic essence isn’t what the Knuth was talking about when he said “Premature optimization is the root of all evil.”

Once the code is working and perfomance analysis is done (I use dynatrace), certain bottlenecks appear.  Optimizing these issues sometimes requires complicating your code in order for it to perform better.  Here are some examples from a nice post by Doug Avery.  Replacing jQuery with native javascript can take out extra executions in a heavily trafficked loop but at the cost of increasing your code and making it less readable.  That’s why it’s critical that you only do this complicating type of optimization after performance analysis has been done and bottlenecks identified.

Using Landing Pages to Improve Performance

The landing page, that simple inviting page that beckons the user to explore.  It gives a taste of what’s to come and it builds up to what’s behind the curtain.  The calming simplicity tells the user to brace yourself for the site you’re about to view.  Their are several UX reasons for having one, but they also offer an opportunity to greatly improve your site’s performance. Here are two ways:

preloading files

measuring speed for future consideration

Reading JSON from Cookies

What’s the point in writing cookies if it’s hard to extract the values later.  I prefer to write JSON into my cookies.  This makes turning a cookie into a javascript object a very simple process.  I use jquery and the cookie plugin.

var json=($.cookie('the_cookie'));
var obj = $.parseJSON(json);

Now your cookie has been converted into a javascript object and you’re ready to rock.

On the other side, if you want to create a json on the client and write it to a cookie you could use json2.js as well as cookie.js