The client, however, found this a bit confusing—once they had expanded the hidden list, it wasn’t obvious to them how to close it. They wanted to be able to click somewhere else on the page and have the list close so they could continue browsing. No problem, I figured, a few JavaScript tweaks and we’d be all set. Simply putting a click event on the body element to close the list would be pretty straightforward.

Lets take a look at the code we used:

function initFauxSelect() {
  $('a.showSelect').click( function(e) {
      e.preventDefault();
      var $theList = $(this).parent('.fauxSelect').next('.selectList');
      hideShow($theList);
  });
}
 
function hideShow(obj) {
  $theList = obj;
  if ($theList.is(':visible') ) {
    $theList.hide();
  } else {
    $theList.show();
  }
}

It’s a simple click event on a.showSelect that calls the hideShow() function. If the list is visible, hide it, otherwise show it.

I figured it would be as simple as binding a new click event to the body tag whenever we show the list. The new event would hide the list when someone clicked elsewhere on the page. Let’s look at the updated hideShow() code:

function hideShow(obj) {
  $theList = obj;
  if ($theList.is(':visible') ) {
    $theList.hide();
    $('body').unbind('click.fauxselect');
  } else {
    $theList.show();
    $('body').bind('click.fauxselect', function(e) {
      $theList.hide();
      $('body').unbind('click.fauxselect');
    });
  }
}

Now, whenever we’re showing the list, we’re creating a new click event on the body that hides the list. It also unbinds itself once its job is done. If someone closes the list by clicking a.showSelect again, we also unbind the event just to keep things clean.

However, I ran into a problem. The event I was binding to the body was being called right away, which stopped the list from ever appearing! It seemed a bit strange, as my assumption was that you’d never want your new event to fire as the same time as the current event.

Thankfully, there’s an easy way prevent this from happening. In our original click event on the .showSelect element, we need to stop that event from bubbling up the DOM.

function initShortcutsSelect() {
  $('a.showSelect').click( function(e) {
    e.preventDefault();
    e.stopPropagation();  // ----- ADDED THIS LINE
    var $theList = $(this).parent('.fauxSelect').next('.selectList');
    hideShow($theList);
  });
}

By telling the event to stopPropagation, it never bubbles up the DOM, never reaches the body and never calls the new click event you bound there until the user actually clicks the body.

1) Decide which content to put on your mobile site

One of the first challenges when starting a new mobile project is deciding exactly what content to offer your mobile visitors. There are a few differing opinions in the industry right now; some people strongly believe in the One Web, while others believe that the experience should be re-shaped for the medium. This could mean a new website, new content, and a new information architecture as well as a design optimized for mobile.

2) Mobile enabling your site isn’t as simple as adding a new stylesheet.

CSS, the language used for applying styles to your website, currently provides a method for specifying where those styles should be applied. This functionality is provided in the form of a ‘media’ attribute applied to your stylesheets. Supported media types include screen (your computer), print (for printing a web page), and handheld (small screen, handheld devices). Unfortunately, support for the handheld media type is limited and buggy. If it were, it would theoretically be as easy to reformat your website for a mobile device as it is to reformat it for print. There would of course still be other considerations—hiding a large banner image via CSS will not stop it from being downloaded over a slow connection to a mobile device.

Because of the lackluster support for the handheld media type, we’re generally stuck with device detection: if a user hits the site from a handheld device, we route them to a separate mobile website. Websites built for mobile use a very similar markup language as regular websites. However, just like some desktop browsers offer different levels of standards support, so do mobile browsers—and there are a lot more of them!

3) Understand the different levels of mobile browsing

At least here in the U.S., we are just starting to see a big push toward phones that are really optimized for browsing the web. With devices like the Apple iPhone, Samsung Instinct, LG Dare, and the G1, every major wireless carrier now offers a decent phone for web browsing. While the iPhone (with its bundled version of the Safari web browser) is easily the winner for web browsing, the other devices aren’t far behind. All the major browser makers also have versions of their browsers that run on mobile devices.

However, there are still a lot of older phones in use whose browsing experience is basic, at best. Even popular devices like the BlackBerry tend to have a sub-standard browser compared to the devices listed above. It’s definitely a challenge to optimize your site to work on the small screens and bad browsers of the older devices, while trying to take advantage of the bigger screens and better rendering ability of newer devices.

4) Play to the strengths of the platform!

So, this should be fairly obvious—it’s a mobile device! Build a site that supports what a user needs to do when they’re on the go. Things like making telephone numbers into hyperlinks that automatically dial the phone can make all the difference to a user. Limiting content to what’s really important and removing images for faster page load times might be painful at first, but as you strip down to the essentials,  you’ll start increasing the usability and value of your mobile site.

5) Test on a range of devices

Testing is definitely one of the bigger challenges we have to deal with. There is simply no way to test on every device. However, with the right combination of devices you can get a great idea of how your site will perform across a wide range of different devices. On page 62 of Cameron Moll’s book, Mobile Web Design, Joe Shepter explains how Yahoo! employed this technique when developing a new mobile site for FIFA.

To make sense of the chaos, Yahoo!’s team first selected a target
group of ten phones. They were all widely distributed, and their
browsers ran the gamut from high-end to barely functional. As the
thinking went, if the site worked perfectly on all of them, it would
perform reasonably well on the rest of the world’s phones.
- Joe Shepter

The folks at MobiForge recommend a similar process:

One way to approach this problem is to focus on five classes of devices that span a range of capabilities. Of the hundreds of devices available, supporting five mainstream devices makes a great place to start. Obviously supporting more devices ensures greater compatibility with more devices and developers should always endeavor to do this, but supporting five devices disparate devices can do the job.

There are also plenty of emulators to help you along, but are definitely not a substitute for the real thing.

6) Use the resources available to you!

Ok, so I know I said 5 pointers, but everyone likes that last extra freebie, right? One last thing to keep in mind—there are resources available to help you along. Aside from the emulators to help with testing (which can be much quicker to use when still in development), there are some web sites that will help check your website to see if it’s ready for prime time.

• W3C mobileOK validator: Similar to their HTML validator, but results are specific to mobile sites
• ready.mobi: “evaluates mobile-readiness using industry best practices & standards”

And of course, partnering with a company who’s been through it couldn’t hurt either. We’d love to answer your questions if you’re thinking it’s time to make the leap into mobile for yourself. Contact us and let’s talk about it!

Unfortunately, the height of the page being pulled in would vary wildly. This led to a fairly disappointing experience where the page was either far too long, or content in the iframe was cut off and the user had to scroll within the iframe to see everything.

We came up with what we thought might be an interesting solution. If the page loading inside of the iframe (the child page) could calculate its height, and somehow let the parent page know, the parent page should be able to reset the height of the iframe.

With a little inspiration, we came up with a pretty neat solution that we’d like to share. Our solution requires that you have the ability to edit the code of both the parent and child pages.

The child page being loaded into the iframe will simply reset the location of the parent page, and include a hash with the height of itself.

1
2
3
4
5
6
7

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.js"></script>
<script>
var parentUrl = "http://example/iframe-outside.html";
setHash = function() {
    parent.location = parentUrl + "#" + $('body').height();
}();
</script>

We’re using jQuery here to easily get the height of the <body> tag.

On the parent page that includes the iframe, we’ll again use jQuery and write a small function that gets the height from the hash in the URL, and uses that to reset the height of the iframe.

8
9
10
11

function setHeight() {
    var newHeight = parseInt(location.hash.substring(1)) + 50;
    $('#hashFrame').attr('height', newHeight);
}

We ran into a bit of an issue: the page we were loading was taking a few seconds to load, and we didn’t want to set our height on the iframe until the content within the iframe had finished loading (and it had a chance to set the proper height to the url hash).

More jQuery to the rescue! The jQuery .load() method allowed us to call our setHeight() function after the iframe had finished loading.

12
13
14

$('#hashFrame').load( function() {
    setHeight();
});

Putting it all together gave us a great way to use our new application inside our legacy application, and make it faily seamless to the end user.