Choosing the right Mobile Solution (Part 1)

Share This Post

Mobile devices aren’t becoming the de facto means of communication and entertainment; they are already there. As a result there is a lot of noise about which method of developing a mobile site is best; creating a single site that formats itself to the device you are using to view it (called responsive design) or a completely separate mobile site that is created with the intent of being viewed on mobile devices.

But do you know which method would be best for your site? Let’s take a closer look and decide….

Both methods have pros and cons. Let’s take a look at the pros of creating a separate mobile site first.

A separate mobile site could have a shorter development time simply because you’re working with a fresh slate. This comes into effect when you are working with a complex site with a lot of content.  While all content is important, not all content, and how that content is displayed, is created equally.

Let’s say you’re are a real estate agent. Of course your listings are important.  Having your listings be viewable by the end user is extremely important. But is it important to showcase every one of your listings, as can be typical on a desktop site? In short, no. The user is only interested in seeing a listing that meets a certain set of parameters (x number of bedrooms, in a certain school district, etc.)

Now some technical mumbo-jumbo. All content has to be retrieved from the server, creating what is called render time. Render time is the time it takes when the device first pings the server saying that it is trying to view a web page until the webpage, and all of its content, is viewable. Render time usually isn’t an issue with most desktops as they have high speed internet connections. But for mobile users they are dependent upon a connection quality that can literally and drastically change between one block and the next.

If we were to create a separate mobile site the unnecessary content items could simply be eliminated from the mobile page and would not be requested from the server. And if it’s not requested, it can’t effect render time.

So in our example above, I would eliminate the page that shows all the listings and replace it with a search function that will return only the listings that the user is interested in seeing. This creates not only a faster render spend (compared to a full listings page), but also a more streamlined user experience since the user does not have to wade through information that they don’t want to get what they do want.

Check out our next installment to see what the cons of this approach, responsive design considerations, and which approach might be right for you.