Mobile devices are a large fraction of web traffic: approximately 56% globally, 40% in Canada according to StatCounter.
That fraction likely varies a lot: more on sites that are good on mobile devices and/or have content that people want to access while mobile.
It's fairly obvious that you need a decent desktop and mobile experience on your site. Things that might be different:
There are a few ways to approach that…
It's (decreasingly?) common to see separate mobile sites, like example.com and m.example.com.
This allows a lot of flexibility in what content is presented in either situation.
But it requires maintaining two different sites.
That might not be too bad for dynamic content: different controllers/views/templates but the same database and core site logic.
For static content, it would requires maintaining completely different HTML.
To make this work, you need to do some browser detection and redirect users to the correct
site.
That can be done, but how accurately? Is a Chromebook or 12″ tablet a mobile
browser that should get the small-screen content?
Remember that screen size is only one difference. Also touch interaction and user expectations. The 12″ tablet is kind of in between.
At least: users should be able to select the version of the site they want.
Don't send a useless redirect: sending a user from http://example.com/articles/some-news to http://m.example.com/ is infuriating.
This seems to be falling out of fashion. Responsive design is more flexible and easier to work with…
You can use the same HTML, but separate stylesheet for mobile devices.
This is probably the easiest solution, but can't have big content differences. As usual, start with good semantically-meaningful HTML: that will give you a flexible foundation.
As we saw before: tell the browser you are aware of differently-sized viewports:
<meta name="viewport" content="width=device-width,initial-scale=1" />
Then create CSS that works well in one situation, and fix problematic things with media queries.
figure {
float: right;
}
@media (max-width: 480px) {
figure {
float: none;
text-align: center;
}
}
@media print {
figure {
display: none;
}
}
Good: only one set of HTML content to maintain.
Bad: must have the same underlying content in the HTML. If you want significant differences in the content for desktop/mobile, you can't do it this way.
Maybe you want to minimize bandwidth on mobile by not loading full-size images: that can be taken care of in plain HTML with the <picture> element:
<picture>
<source srcset="/media/examples/diagram-highres.png"
media="(min-width: 600px)" />
<img src="/media/examples/diagram.png" />
</picture>
Or just use SVG, which scales nicely anyway.
But in the modern world, why would you want different (HTML) content for those viewing handheld vs large screen? It assumes different fundamental use-cases.
One more option: ignore the web and put an app in the device's app store(s). (I will admit that I have a pro-web bias here.)
Pros:
Cons:
My feeling: many apps probably could have been decent mobile sites.
An in-between solution: make web stuff look like an app.
Something like jQuery Mobile or Sencha Touch (now part of ExtJS) can create sites that look and work like apps.
This doesn't create an app, but it might be close-enough to satisfy your users.
Apache Cordova (or PhoneGap) or React Native can be used to wrap web content into an actual app.
You write HTML+CSS+JavaScript using the Cordova API. It gets compiled into an app for many platforms.
Good: from one codebase, create apps for many platforms. Possibly re-use web site content/code.
Bad: it's still wrapped in a web view, so might not feel app-like unless you're careful. Won't get native app speeds.