The days of a fixed-width 960-pixel-wide web design are behind us. The markets for smart phones, tablet devices, and personal computers have created and environment where websites need to function on vastly different screen sizes and form factors. Desktop monitors can be over 2,000 pixels wide, while some phones are less than 400 pixels.
Now, high-pixel-density display, like the iPad’s retina display (which has a higher resolution than most desktop monitors) are complicating the problem even further. The first and second generation iPads had a resolution of 1024px x 768px. The third generation iPad is the same size, but its resolution is 2048px x 1536px. It leaves us with two devices that have almost exactly the same physical dimensions, but drastically different resolutions.
Variations in pixel density size, and form factor have forced the industry to reevaluate how a website should be experienced. Couple that with different operating systems and multiple browsers, and we have a potential nightmare. We need solutions to present users with good experience, no matter what device they’re using. I’m now going to introduce a couple of common solutions to this problem and briefly discuss their pros and cons.
A mobile site is built specifically for a mobile device, but with the aim of reflecting a desktop site of the same content. When a user goes to the site on their desktop computer, they are routed to the version of the site that works best for their desktop monitor. Similarly, if a user visits the site on their phone, they will be directed to the mobile version of the site that has been specifically optimized for small devices. Look at the comparison below.
It’s a fairly straightforward approach: If you need a site that works on both the desktop and smartphone, make two sites. Any visitor to the site will be routed to the version that works best on their device. Taking this approach involves a number of technical hurdles, through. For instance, how do we accurately detect which device is displaying the site? How do we maintain the same content on two separate websites? What do we do for tablet computers or notebook computers?
Granted, all these problems have solutions, but it’s worth noting that designing two sites that are supposed to act as one adds layers of complexity that would otherwise not exist.
For the most part, mobile sites have fallen out of favor, but I still think they have their place. If the experience that your desktop site provides differs significantly from the experience that you want users to have on their phone, a mobile site is probably a good choice. Because they can both be designed independently, from the ground up, special considerations can be made for each site that have nothing to do with the other.
I think that mobile sites have a place with web apps. High levels of interaction and functionality can be hard to translate from a large desktop version to a tiny handheld devices. On a desktop computer, a web app can be laid out in multiple panels. Some areas can show readouts of information, while others have controls for manipulating that information. Data can be pulled on the fly using Ajax, so the whole app might be one page. One a small device, each part of the app (the readouts, the controls, and so on) might need to be on separate pages. The entire structure of the app may be completely different, even though the content is the same. Because of the wide variance in how the two sites need to be built, a mobile version might be the most appropriate.
In a word: duplication.
If you build two sites, everything has to be done twice. Sure, both sites can pull from the same databases; I’ll bet they’d even share a great deal of server-side code, but everything else has to be done twice. All the UX work, design work, and front-end development is automatically duplicated. Duplication means time and money.
The other issue with a mobile site is that “mobile” is more than just one device. As we talked about at the beginning of this section we have to accommodate dozens of sizes, resolutions, and form factors. Are we supposed to build a site for each possible device?
Mobile sites are an attempt to give users a rewarding experience no matter how they access the site or what device they own. Providing a site for each possibility is next to impossible.
So, the question becomes; “If I want to avoid duplicating my efforts, and it’s unnecessary to provide completely different experiences for the user, how do I build sites that work on all devices?”
These days, the answer is responsive web design. A couple of years ago, Ethan Marcotte wrote an article for A List Apart about something he called responsive web design. Rather than going over the details here, I’d suggest you give it a read.
I will, however, explain how responsive design works in simple terms. As I mentioned before, we aren’t concerned with the details of implementing a responsive design at this time, but because we need to know how responsive design affects our process, it’s important to understand how it works. Responsive design is a method of combining fluid layouts (which shrink and grow as a browser is resized) with media queries (CSS conditional statements that apply styles if certain conditions are met) to produce a site that can shift and change depending on the browser window’s resolution.
For instance a media query can check to see if the maximum width of the viewport is less than 480px, and if so, the style will be applied. If the viewport is greater than 480px wide, the style won’t be. Media queries can also be used to detect if the device is in landscape or portrait orientation, as well as other qualities, giving us tight control over when styles are applied and how. Each media query creates a breakpoint, where the fluid layout will changed based upon the new styles for that resolution. A breakpoint is the point where the next media query resolves true and new styles are applied to the design. Responsive designs allow us to create websites that change to best sit the pixel dimensions of all devices.
Responsive design is completely resolution-independent. It’s easy enough to do, in a technical sense, and it allows for one codebase across all devices. We only need one stylesheet and an HTML document to create a responsive layout in almost all modern browsers. Instead of focusing on the many resolutions of each mobile device, we can create breakpoints for out content and design. We can look for the places where the fluid layout starts to break down and create breakpoints to handle the transitions between differing page widths. The image above shows how as a responsive site becomes wider, the media queries trigger and adjust the layout to be best support the content.
Finally, and I think most importantly, responsive design forces us to consider almost exclusively the presentation of our content. We have to focus on structuring out content, so that responsive design is possible. We are obligated to think about how our content will appear on a huge range of devices: How will we show content on a mobile phone that gills a desktop monitor? If we have to cut down on content, what will we want to display on the phone? If certain content is unsuitable for the phone, should we display it on the website?
Honestly, I’m hard-pressed to identify many problems with responsive design. As I mentioned before, media queries have no support in older browsers, but we have multiple workarounds at our disposal. Still, a couple of sticking points do mater when adapting your workflow to accommodate responsive design. The first sticky wicket is that responsive design requires a change in approach for designing a website. Because the design has to adapt to multiple form factors and resolutions, we’re required to give more consideration to markup. How do we design a site that can function well on a 400-pixels-wide smartphone yet can scale to 2,000 pixels without a hitch? It’s simple enough, but it does take a willingness to embrace the dynamic nature of content and quite a bit more forethought.
With static-width layouts, only when the design is complete do I even think about markup, because I know that I can mark up just about anything in a semantic way. I just design what I want and worry about the markup later. However, taking such a gung-ho approach with responsive design is not recommend; otherwise you might find that you have to spend more time wireframing the breakpoints in your designs in order to write clean, semantic HTML and CSS.
Read more: http://www.webdesign.org/comparison-between-responsive-design-and-mobile-sites.22252.html#ixzz2OerL7FPB