Best Method for Mobile Website Development

[Marc]

One of the companies that I work for has asked me to create mobile versions for all of their websites, as well as their internal sales system (4 websites total).

I've done a substantial amount of mobile web development in the past under freelance contracts for other companies, but I was wondering about the methods that some of you have chosen to use when creating mobile-friendly versions of websites.

The method I've been using is as follows:

• Within my templates directory, I have two sub-directories - "desktop" and "mobile"
  
• I create a subdomain (m.example.com) for the mobile version of the website (I hate sites that automatically show mobile versions by user agent, etc.)
  
• Within my views file, I have a function that does something like this pseudo-code: if m.example.com then template_to_use = "mobile" else template_to_use = "desktop"
  
• Within each view, I then load template_to_use/template_for_this_view.html
  
• Naturally, the mobile template extends a mobile base template, and the desktop template extends a desktop base template
  

I find this to be the most versatile way to accomplish the task of creating mobile-friendly versions of websites.

However, as previously stated, I'm curious to hear how other people approach mobile web development, as well as the pros and cons that they see with their method of choice.

[coolcoolcool]

I do the same, or I simply make a subdirectory called m and do everything for the mobile side of things in there and redirect to it. I find m.ksmdfmfk.com to feel the same as ksmdfmfk.com/m/. There's really not that many ways of doing it and I find simple = better with most things in web development.

I remember one time I attempted to use JQuery Mobile to build a web application and I ended up spending way more time learning how to develop properly with it and then at the end of the day it wasn't compatible with all the phones I wanted and I scrapped the entire thing and rebuilt it myself.

tl;dr I use a simple method of organizing the directories, allow mobile users to navigate to it, then build it using traditional web methods that are phone friendly.

[Violet]

You do realize that you can make one site but have it display differently based on pixels? This is a blog post that essentially says how to design responsively and why it's one on the better ways to develop. Essentially, rather than create different websites for different devices, have different CSS (or one stylesheet depending how different you want the displays to be). Pros to mobile first - the blog post pushes it? Less content and features you have to keep up with, less time in editing layouts that may not work on smaller screens. Does that make sense?

Edit: Oh, and I don't know if you noticed but that blog has a responsive web theme so it can be viewed  on any device/with any browser size/ with almost any amount of pixels without major issue (resize your browser with that pulled up). 

[Jordan]

Dec 1, 2012 20:51:35 GMT -8 Violet said:

You do realize that you can make one site but have it display differently based on pixels? This is a blog post that essentially says how to design responsively and why it's one on the better ways to develop. Essentially, rather than create different websites for different devices, have different CSS (or one stylesheet depending how different you want the displays to be). Pros to mobile first - the blog post pushes it? Less content and features you have to keep up with, less time in editing layouts that may not work on smaller screens. Does that make sense?

Edit: Oh, and I don't know if you noticed but that blog has a responsive web theme so it can be viewed  on any device/with any browser size/ with almost any amount of pixels without major issue (resize your browser with that pulled up). 

Nice article. That can be a great solution for many websites, but sometimes it is better to have a separate template just because there may be a lot of information that you don't want to load on the mobile version. If the website doesn't have much content in the first place, then it would probably work out very well.

This is partly why Proboards has a separate template for mobile browsers.

[Violet]

Dec 1, 2012 21:07:35 GMT -8 Jordan said:

Dec 1, 2012 20:51:35 GMT -8 Violet said:

You do realize that you can make one site but have it display differently based on pixels? This is a blog post that essentially says how to design responsively and why it's one on the better ways to develop. Essentially, rather than create different websites for different devices, have different CSS (or one stylesheet depending how different you want the displays to be). Pros to mobile first - the blog post pushes it? Less content and features you have to keep up with, less time in editing layouts that may not work on smaller screens. Does that make sense?

Edit: Oh, and I don't know if you noticed but that blog has a responsive web theme so it can be viewed  on any device/with any browser size/ with almost any amount of pixels without major issue (resize your browser with that pulled up). 

Nice article. That can be a great solution for many websites, but sometimes it is better to have a separate template just because there may be a lot of information that you don't want to load on the mobile version. If the website doesn't have much content in the first place, then it would probably work out very well.

This is partly why Proboards has a separate template for mobile browsers.

Very true and I understand the separate templates. But there are features that don't cross over when you have different templetes for different devices. It's one thing for forums to have different websites - because of the sheer nature of forums- and a website you go to only to get information from to have different websites.

In some instances, eg Proboards, designing Separate but/and Unequal (and/or depending on who you ask) is needed. Other instances, like Facebook, designing Separate but/and Unequal should not be done, imo.

[Jordan]

Dec 1, 2012 21:16:46 GMT -8 Violet said:

Dec 1, 2012 21:07:35 GMT -8 Jordan said:

Nice article. That can be a great solution for many websites, but sometimes it is better to have a separate template just because there may be a lot of information that you don't want to load on the mobile version. If the website doesn't have much content in the first place, then it would probably work out very well.

This is partly why Proboards has a separate template for mobile browsers.

Very true and I understand the separate templates. But there are features that don't cross over when you have different templetes for different devices. It's one thing for forums to have different websites - because of the sheer nature of forums- and a website you go to only to get information from to have different websites.

In some instances, eg Proboards, designing Separate but/and Unequal (and/or depending on who you ask) is needed. Other instances, like Facebook, designing Separate but/and Unequal should not be done, imo.

Yeah, I agree, it depends on the type of website. Your solution would definitely be the best way to go if a separate template wasn't really needed.

[Marc]

Dec 1, 2012 21:36:01 GMT -8 Jordan said:

Dec 1, 2012 21:16:46 GMT -8 Violet said:

Very true and I understand the separate templates. But there are features that don't cross over when you have different templetes for different devices. It's one thing for forums to have different websites - because of the sheer nature of forums- and a website you go to only to get information from to have different websites.

In some instances, eg Proboards, designing Separate but/and Unequal (and/or depending on who you ask) is needed. Other instances, like Facebook, designing Separate but/and Unequal should not be done, imo.

Yeah, I agree, it depends on the type of website. Your solution would definitely be the best way to go if a separate template wasn't really needed.

I agree that certain websites need nothing more than a responsive layout. However, I would have to disagree with the point regarding Facebook simply needing to use a responsive layout.

There are a few reasons why I would say this, but the one I'll focus on is simply data usage. The Facebook desktop site averages around 1MB of data per page load, while the mobile version (iPhone, in this case) averages out to only 450KB. This doesn't seem like a huge difference in and of itself, but there are still a fairly large number of mobile users (especially outside of North America) who do not have 3G or 4G network access.

According to a recent article done by PCWorld displaying the differences in speeds from 2G up to 4G, a 2G connection has an average download speed of 18.75KB/s. This means on a 2G connection, Facebook's desktop site would take up to 54 seconds to fully load (personal tests place average load time around 32 seconds on 2G -- luckily I happen to be in an area this week that does, in fact, have scarce 3G support, making it a perfect test area).

Placing page load times aside, however, another thing to consider is monthly bandwidth caps. A recent survey found that the average user (age 13+, so not just teenagers -- stats for teens likely significantly higher) spends just over an hour on Facebook every single day. If we assume a page load (or the equivalent of a pageload [1MB] from scrolling through one's News Feed) for every 2 minutes of being on Facebook, this works out to about 30MB per day. This does not take into account any pictures that are viewed, or videos that are watched, thus likely placing the actual amount quite a bit higher. Using our 30MB/day figure, however, this totals up to around 900MB every month, just from Facebook. Many people only have 500MB data plans, and those with 1GB data plans likely don't want to use over 90% of that on Facebook. The current iOS version of Facebook, however, uses only 400MB of data per month using the same stats, but with the 450KB page size.

There is more to consider than simply a loss of features when using multiple layouts. Facebook is the #1 most-visited website in the world, with over 604 million active monthly users (as of Sept. 2012) -- I can't imagine that they would have simply jumped into the mobile market without doing substantial research into the benefits and drawbacks of the various options they had for creating mobile versions of the service.

[Violet]

With a responsive theme, the site can actually be programmed to not download all the same information. In you CSS, you can say something along the lines of:


@ media screen (max-width 320px){

background-color: #FFF;
}

@ media (max-width 720px){

background-image: ./images/image.jpeg;
}
(minus the spaces between the @ and the media).
Or better yet, in the header of the .html or whatever you're using (of the code would change depending on the language):


<head>
<link rel="stylesheet" type="text/css" media="screen" max-width="320" href="/mobile.css" />
<link rel="stylesheet" type="text/css" media="screen" max-width="720" href="/desktop.css" />
</head>

And have different stylesheets based on screen size (though, yes, this will effect response times on bigger devices).

That image (in the first snippet of code- or even if it's called in the desktop.css) isn't called from where ever it's stored until browser hits a certain size. Unless I am completely misunderstanding how this works, this will help solve the problem of data. Now, I'm not saying that how Facebook is coded is wrong, just that I would code it differently. There should be an option as to which one is pulled up on the mobile device, imo.

And once again, I state that I understand that in some circumstances, there needs to be a mobile version.

[Jordan]

Dec 3, 2012 8:21:45 GMT -8 Marc said:

Dec 1, 2012 21:36:01 GMT -8 Jordan said:

Yeah, I agree, it depends on the type of website. Your solution would definitely be the best way to go if a separate template wasn't really needed.

I agree that certain websites need nothing more than a responsive layout. However, I would have to disagree with the point regarding Facebook simply needing to use a responsive layout.

There are a few reasons why I would say this, but the one I'll focus on is simply data usage. The Facebook desktop site averages around 1MB of data per page load, while the mobile version (iPhone, in this case) averages out to only 450KB. This doesn't seem like a huge difference in and of itself, but there are still a fairly large number of mobile users (especially outside of North America) who do not have 3G or 4G network access.

According to a recent article done by PCWorld displaying the differences in speeds from 2G up to 4G, a 2G connection has an average download speed of 18.75KB/s. This means on a 2G connection, Facebook's desktop site would take up to 54 seconds to fully load (personal tests place average load time around 32 seconds on 2G -- luckily I happen to be in an area this week that does, in fact, have scarce 3G support, making it a perfect test area).

Placing page load times aside, however, another thing to consider is monthly bandwidth caps. A recent survey found that the average user (age 13+, so not just teenagers -- stats for teens likely significantly higher) spends just over an hour on Facebook every single day. If we assume a page load (or the equivalent of a pageload [1MB] from scrolling through one's News Feed) for every 2 minutes of being on Facebook, this works out to about 30MB per day. This does not take into account any pictures that are viewed, or videos that are watched, thus likely placing the actual amount quite a bit higher. Using our 30MB/day figure, however, this totals up to around 900MB every month, just from Facebook. Many people only have 500MB data plans, and those with 1GB data plans likely don't want to use over 90% of that on Facebook. The current iOS version of Facebook, however, uses only 400MB of data per month using the same stats, but with the 450KB page size.

There is more to consider than simply a loss of features when using multiple layouts. Facebook is the #1 most-visited website in the world, with over 604 million active monthly users (as of Sept. 2012) -- I can't imagine that they would have simply jumped into the mobile market without doing substantial research into the benefits and drawbacks of the various options they had for creating mobile versions of the service.

I was just agreeing with the argument that it depends on the type of website and the content it contains when considering which solution to use; I don't even use Facebook so I'm not too familiar with the amount of content on each of their pages. That said, though, great post as it really does show how important it is to research before you start coding.

A fun fact about Facebook is they wrote an open source application (HipHop) that converts all their php code into C++ which is then compiled. This increased their server performance by 50%...Just one of the reasons why php is a terrible language, though it's fine for small applications.

[coolcoolcool]

You'd need to be developing for a pretty large scale web application for php to show any noticeable efficiency issues. 99% of the time when I'm doing any kind of web development I'm more worried about functionality than overall efficiency, because at the end of the day being compulsive about load times and bandwidth will just make you unproductive. Obviously, something as big as say the google search engine or something as intensive as facebook is an exception, but they also have algorithm developers working tirelessly to improve things in the back end that normal users probably will never even notice. 

Although, I find developing templates that work on both mobile and desktop devices can be a pretty big hassle in itself. It's usually easier to just build a separate mobile version of the webpage, especially if you have a lot of pre-built functions and classes to draw information from. It also allows you the freedom of not loading huge style sheets or libraries like JQuery, if you really don't have any use for them on the mobile side of things. It's expected that a mobile version of a website will be simple, so whenever I'm working on one they tend to turn out lightweight and purely functional and they still end up looking well-designed. 

[Jordan]

Dec 3, 2012 20:33:19 GMT -8 coolcoolcool said:

You'd need to be developing for a pretty large scale web application for php to show any noticeable efficiency issues. 99% of the time when I'm doing any kind of web development I'm more worried about functionality than overall efficiency, because at the end of the day being compulsive about load times and bandwidth will just make you unproductive. Obviously, something as big as say the google search engine or something as intensive as facebook is an exception, but they also have algorithm developers working tirelessly to improve things in the back end that normal users probably will never even notice. 

Yes, I very well know, but it's more than that, though. People learn PHP because it's really easy to use (which is fine). However, the language itself is just bad in my opinion. Hell, the creator of the language is quoted saying: "I was really, really bad at writing parsers. I still am really bad at writing parsers.". I know the parser has been re-written, but I just can't stand the implementation of the language such as various syntactical decisions, the poor OOP implementation (they should re-do it or get rid of it), and it's overall bloatedness. It just seems really unorganized and random, and it makes it easy for developers to write terrible code. Obviously speed isn't always the main concern, I completely agree with that (I mention hip-hop way too much; it's just interesting to me), but PHP is limited. Enterprise Java web development may the most powerful right now, but it's not free. PHP is great for a lot of things (personal use, small freelancing projects), but for any serious project I would really recommend to choose a different language. You'll get paid more if you knew more useful languages used in the industry.

$0.02

I haven't slept in 24 hours so hopefully this makes sense.