How to Create a Mobile Friendly Website [Infrastructure]

How to create a mobile friendly website [infrastructure]

If SEO isn't really a concern, Using different stylesheets with the same HTML is much easier, in terms of maintenance.

What's the best way to make a mobile friendly site?

I added a mobile presentation layer to an operational site about a year ago. Based on the architecture of the site (hopefully this isn't too technology dependent for you) I added a new set of JSPs to accommodate mobile browsers (sidenote: see http://wurfl.sourceforge.net/ for a great way to build mobile pages independent of browser type). Additionally some of the back-end functionality was changed due to the limited functionality of most mobile browsers. So, in short, the integration wasn't as painful as one would expect.

Good luck!

How to make a webpage mobile friendly with css media queries

My advice would be to test the code in a real mobile phone not with a browser if that's what you are doing cause browsers behave differently

Another important thing you must do is add meta view port tag without that it won't work like the one given below

<meta name="viewport" content="width=device-width, initial-scale=1" />

Remove !important from your default css use css specificity instead if its really necessary so your default css should be

.leftSideBar{display:block;}
.rightSideBar{display:block;}

if even that doesn't work you have to show us your entire css or html to identify the problem

how to make website compatibility for mobiles as well as pc's

Well, actually you can do it in different ways. The best solution is some script which checks the UserAgent first. I kow, its not that save, 'cause its easy to change the agent but why should someone do it and with which benefit of it ;)
So this should be your solution. Also you can optimize the websites to the specfic target device/browser. For example, for devices like iPhone, Android or WinMob you ould use Javascript Frameworks to work withthe website content.

I made a little post on another question which could help you aswell: Is there an equivilent of jQTouch that covers iPhone, Android, WebOS and Blackberry OS?

How to design/organize/architect the development of mobile web within a Rails application?

You will 9 times out of 10 be better off if you design the site so that you can use the same codebase for any device, so that it adapts intelligently to your device, and so that it renders the most important/useful content/functionality for each device based on stylesheets or runtime choices of rendering/non-rendering. Remember that, unlike 6 years ago, your primary concern with mobile devices today isn't lack of processing power, but rather a different screen size and different input.

Generally, mobile users do not want to be seeing a crippled or stripped version of your site. They want to see a usable version of your site. What Usable means varies, but it often means that the most frequent functions are very easy to access, while the more obscure options are buried a little bit lower or perhaps not quite as optimized.
Usable might mean that you give them exactly the same functionality as on a desktop, but styled to present better on the mobile. Or that you cut out things that make no sense on a mobile. But you'll be making it much harder for yourself if you set it up so that you have to maintain two code streams, or one code stream that branches very early on, or a fundamentally different application. It's a lot more testing, a lot more coding, and a lot more likelihood of breakage.

We follow this approach, and it works well for our very small development team -- we've successfully used it so that we can use the same codebase to run two different implementations for different customers -- one a very complex desktop-first UI as well as a very streamlined mobile-first app:

• assume that all devices will access the same URL
• assume that 90% of device optimizations will be done using CSS media queries, 7% will be done using jQuery hacks, and 3% will be done using browser detection very early on
• build your application so that the individual UI components or modules can be easily enabled/disabled through code (logic in ApplicationController? Rack Midleware?). We do this by putting our individual "widgets" in partials that are wrapped with checks for enablement of the widget (either in Rails.config or as an instance variable in side ApplicationController) so that we can turn off whether we return the corresponding HTML back to the browser
• use CSS media queries not only to style fonts and widths but also to rearrange menus/functions and other UI items so that they work on the different form factors you require

Generally, the API-for-mobile approach will be of most use to you if you're going to be building a compiled app for a mobile device and are going to be doing the heavy lifting on the UI using the device's UI libraries rather than HTML generated on the server. Then again, if you choose to use an approach such as Backbone.js or Angular.js to handle your front-end display, then going with an API-only approach MIGHT be also a good architecture for you to follow. But then you're stepping outside of Rails a lot more.

Are SPAs (Single Page Applications) suitable for sites aimed for mobiles?

TL;DR: single page applications require more attention to their architecture, especially if you're migrating functionality of an existing website (d'oh, brownfield projects are tough).

A common pro-SPA argument focuses on less downloaded content. While technically correct, it holds less relevance on a cellular connection with high latency. Spoiler alert: all cellular connections are high latency.

• The difference between downloading 10KB and 15KB is negligible, it's the connection establishment overhead that drains all joy from a mobile experience.

• You can rarely influence latency (although using a CDN and hosting in the cloud can), but you can offset its impact. Resource bundling and minification is effective, and the underlying concepts are applicable regardless of the environment used.

• You should be gzipping your content anyway, and the way it works further deflates (haha) the size argument. Basically it focuses on repeating character sequences and is more efficient for things like bloated HTML markup rather than lean JSON. This gets ridiculous for clojure-compiled javascript.

• Always a good tip, but make sure that your content is served with valid Content-Length headers to allow persistent connections.

On the other hand, a common anti-SPA argument goes like this: ZOMG so much javascript. Sure, you can no longer afford to have memory leaks like you "can" on a traditional website (most are remedied as soon as a different page is navigated to), but write good javascript and you will be rewarded.

• Using jQuery on a mobile site is sometimes a necessary evil. Might as well use it properly.

• The more javascript you have, the bigger the relative incentive to have it not re-executed upon every "page load". Any framework you include on a page has to be initialized before it can be used, and that requires parsing and executing its code... on every page it's used. SPA only needs to perform this step once (still, this is not an excuse for poor/missing dependency management).

• This also applies to CSS. When new content is added to DOM following a user interaction, there will be less re-flows and re-paints than a fresh load would incur; there is also no need for the browser to parse stylesheets again.

The real strength of a single page application is in its perceived performance. You and I both know that tapping on a link is not resolved instantaneously, but the user doesn't have to. Making the site responsive to user interactions by adding touch states and a well-timed throbber would dramatically improve the UX. Of course, you can always go the extra mile and pre-fetch certain content. Maybe it would make sense to load the next page/item/photo in the background right after the current one is ready?

Don't discard the fact that SPAs are hot and trendy, plus the motivational factor of getting to play with some fascinating frameworks. Of course, end users wouldn't care about such things, but you get to learn something new and a mature MVVM framework could take your mind off getting this damn ajax to work and let you focus on other aspects of the app.

---

Related Topics