The difference between a Responsive for Mobile Site and a True Mobile Site
A lot of people seek input from their associates when looking to buy a new site. The most recent run-ins we've had with this is "Responsive". That's excellent, we love to hear that our clients want the latest tech, however, there is a difference between a "True Mobile Site" and a "Responsive for Mobile Site". Let me explain. There are pros and cons to each approach of making a mobile friendly web experience.
True Mobile Site
This seems to be arguing the difference between a rectangle and a square. The immediate difference is the /m or /mobile URL. Some sites, when visited on a mobile device, will redirect your URL to URL/mobile. This new /mobile URL is a completely different site utilizing a separate folder system of images, pages and style sheets. This also allows for a smooth load time using less bandwidth. These websites will look more like mobile apps with their images and navigation optimized for mobile devices and utilize a user-agent session switch button. This button allows you to switch from mobile to full site if you need all the information. Since mobile users are generally not interested in reading massive amounts of info, new page content can be used for the mobile pages. This brings in the problem of duplicate content that Google frowns upon. Since you now have two "separate" webpages with mostly the same content, Google may push you down in the rankings for being a "copy-site". The way around this is by either using PHP If/Else tags or the Canonical header tag. A canonical tag means that you are telling Google where the page info came from, just like citing your sources on a paper. Using PHP If/Else statements is half-way in between a Mobile Site and a Responsive Site. The tags allows the backend to ignore loading heavy images from the desktop site that would bog down loading and bandwidth. But you'd be using the same pages and folders for both sites, which can get a little hairy.
Another downside to Mobile Sites is that mobile detect is not always accurate. An Android Galaxy Tablet is viewed as a mobile device where an Apple iPad displays a desktop 960 website. A mobile site is not going to look very good on a such a large tablet so you'd want the regular site to show up. There are definitely some bugs to work out with mobile-detects and what device software believes itself to be.
Responsive for Mobile Site
A Responsive Site for mobile is done with Media Queries. You may want to read our post on Media Queries to get a better grasp of what these are. In summation, media queries are styles that force new rules depending on screen width. One can show, hide, expand and unfloat divs and other elements at different widths (these are called "Breakpoints"). So @1600 pixels, @1200 px, @1024 px, @650px and @350px. You're even allowed to set orientation: landscape/portrait, for mobile device rotation. Most designers use percentages instead of set widths to code their elements these days so the widths are a bit fungible. No doubt you've seen some responsive sites that do this, if not feel free to grab your window corner and shrink its width down. You may see the site change based on its width, that's responsive coding. There are pros and cons to responsive sites as well. One of the biggest is loading. Instead of serving up mobile friendly images like a true mobile site, you would be shrinking down a much larger desktop site image, meaning bandwidth is getting bogged down with downloading scaled down, and hidden divs. Remember that sleek, sexy slider on the homepage? you can't see it anymore, but you're phone does. That's being hidden as well. Now, there are work-arounds for some of these issues, but they are still heavier than a true mobile site.
One thing is your site will look great on any device and uses the same styles for each page and no duplicate content. The downside, it may not be fully optimized and will take up bandwidth. Also, your code gets a bit hackish and confusing with all the hide/show styling and you start to essentially load two pages, or three if you're coding for the new iPad Mini, but that's a whole other post.