By Christina Truong

Too Big, Too Small, or Just Right: Creating a Website for Multiple Screens

By Christina Truong

For many, planning a multi-screen web experience is no longer an afterthought; it’s the starting point. More and more, people are viewing websites outside of the traditional desktop screen. From tablets and phones to netbooks, laptops, and even TVs, optimizing for a wider audience (and their wider screens) is key. However, there are many considerations to explore before even one line of code is written.

Responsive Web Design

When Ethan Marcotte introduced the concept of creating one website to target multiple screens, the phrase “responsive web design” became part of the vocabulary of anybody who worked in and around the digital space.

With the incorporation of CSS3 media queries, websites can go beyond just increasing or decreasing the width of elements already seen in fluid layouts. Elements of the page can now be adapted gracefully between different resolutions by shifting, resizing, hiding, or even removing different elements. This technique enables the website to respond to the context of the viewer. In addition to maintaining only one code base and updating content for a single site, using an adaptive grid design can also create continuity between each screen’s experience.

At first glance, responsive web design seemed to be the right solution for any mobile website. While it is a great alternative to creating a separate mobile site, there are still some challenges to consider.

The end result of a responsive website will be a single platform that accommodates different resolutions and devices. This is almost certainly better than a website designed for only one viewing device, but it also requires many more decisions and much more extensive planning: additional design mockups will be required to plan each layout, testing will require a wide array of viewing devices, and content strategists will need to undergo a difficult triage process where they decide which content will be marginalized (or removed entirely) from smaller screens.

When making these difficult decisions, mobile designers should remember that people using desktops have different viewing habits than those on a mobile phone. The importance of content and elements depend on the viewer’s device. For example, your phone layout should feature phone numbers much more prominently compared to equivalent desktop layouts. Similarly, your layouts for touch-based devices should have interactive menus that are designed for fingertips instead of cursors. These touch-friendly accommodations could take the form of  large buttons, swipe-friendly design, and a lack of hover effects (you can’t truly “hover” your fingertip like you would a cursor). In general, your mobile accommodation decisions should stem from careful study of the common interaction behaviors associated with each device.

To determine how to redistribute these elements, more collaboration between designers and developers will be needed. Rather than the traditional flow where the designer designs first and then hands the PSDs over to the developer, more design iterations combined with development will be necessary as the site goes from conception to completion.

Mobile Websites

For sites that are content-heavy, creating a separate mobile website may still be a better option despite requiring the maintenance of separate code bases and content. The separate needs of the mobile site and the desktop site sometimes require entirely different changes to the structure and content placement. Whole sections may need to be re-imagined beyond resizing elements, shifting columns and pushing sidebars to the bottom.

MailChimp is a great example of how the distinct mobile and desktop sites reflect how the layout and content has been changed to suit the device used to view it.

The two versions are drastically different in terms of content and page layout. The desktop version includes a variety of resources and product information, whereas the mobile site’s homepage has been simplified and focuses on signing up, product features, pricing, and login. However, the mobile version still provides an option to view the full site to access all of the information available.

To develop desktop and mobile sites as distinct as these, responsive web techniques would not be the right approach.

Mobile, Native, and Hybrid Apps

Choosing between mobile web apps and native apps has it’s own set of complexities. As seen in the previous example, a mobile website can be styled to look similar to native app. Since it is run from the device’s browser (usually under a sub domain), it can be accessible across all devices and does not require any downloads or updates, leading to a wider reach. You can also easily add touch gestures like tap events and swipe actions using libraries such as jQuery Mobile.

Native apps on other hand are built for specific devices in that device’s programming language (e.g. Objective-C for iOS, Java for Android). Since the native app runs from the device, it can access the device’s resources and can be used offline. Native apps are also distributed through the device’s marketplace that can allow it to be monetized and gain visibility.

Hybrid apps are a combination of the two.  Like web apps, it can be written in standard HTML, CSS and JavaScript, but this programming is embedded into the application. It is native because it needs to be downloaded from an app store and runs from the device.

Final Decision

There are so many options for building and maintaining a mobile presence; how does one decide? No two projects are ever the same, so it’s important to consider which options fits the specific project, what the requirements are, and what resources are available. However, with rapid technological advances introducing more ways to view the web, planning a multi-screen experience should be the starting point, not the afterthought.

Do you have any multi-screen projects, frameworks, or experiences to share? Do you consider “responsive web design” to be the one-size-fits-all solution to all mobile projects, or do you find that separate mobile websites and native mobile apps offer significant advantages?

  • Great article. I think that most firms, unless you are oracle or msft, don’t have resources to have a dedicated mobile site with different code, but maybe I’m wrong. We are in the process of developing a mobile site, but it will via a utility that converts a normal site to a mobile site. But I guess the problem will be the interaction behaviors as you mention which will be different for different devices. Not sure how these converters handle that or how to solve that problem. For the native, or mobile web app dilemma, it really depends on the purpose of the application. In general for most, I think that mobile web app with HTML 5 is the way to go. Updates are easier that way.

  • A good introduction into the considerations of responsive web design but it opens up more questions than it answers for me. Having already done two sites with dual style sheets for different media I find it a chore (and takes so much more longer). Truly web designers or site owners cannot afford the outlay for different devices, OS and multi-testing in an ever changing device / evolving technology. And they think it “just works” !! Trying to explain it and the extra cost involved can be a nightmare.

    On the one hand I know I need to know and use this stuff now but honestly the average client still doesn’t understand how PC monitors / resolutions and caching work… maybe I am just tired of the ever-changing goal posts.

    I just want to build a website that works straight from Dreamweaver or well honed HTML code… Seriously most of my time is spent tweaking / testing & bug fixing and all becuase we don’t really have any standards.

    After 15 years battling through the browser wars, validation and accessibility I need a career change !!

  • We recently started working with dudamobile and I am very impressed with it. At the very least it does enable the ‘little guy’ who does not have a huge budget to have a mobile version of there website without breaking the bank. I wonder if there is anything else like it that I don’t know about yet.

  • This is a great article and really speaks to our current situation. We have a full online accounting program that works great in all browsers and operating systems. We want people to be able to use it on their phones occasionally, too. We are in the process of making some minor tweaks to make that a reality. We have discussed building a mobile version of the program, but that is a daunting task. Not only would we have to completely change the UI, but how practical is that in the long run? Sure, it’s great to be able to look up an invoice or something on your phone, but no one is going to do day-to-day accounting transactions that way.

    Christina, what is your opinion?

  • @Lori It would really depend on how much demand or value it would be for your customers to be able to have access to a mobile site vs the effort to create one. Do have any analytics on whether your customers use their phones or tablets that often? It does take more effort and is likely one of the reasons that most websites don’t have a mobile version. You could also simplify the site and just have basic features, like being able to look up invoices, and provide a link to the full site if people want to use the other features.

  • Almost every site we are either building or redesigning now uses a responsive design. Once you have a basic framework, it’s not that difficult. The most difficult element is the resizing of images and even that is not that difficult. Actually It’s been more work to add retina Images.
    I do agree that web apps are a whole different story though.

  • Responsive design is only possible if the client has the financial resources to pay for the research and development on a scale you propose here. In the current economic climate, I do not have clients who can afford this and secondly, mobiles are still a small part of the traffic. It is worthwhile to spend several thousands dollars extra to accommodate 2% of your audience?

    I’m not saying it is a bad idea, but we live in a real world where bottom line thinking is more important then the ideal of having a perfect solution.
    However, I do like the idea of a separate mobile site with customized content and a link to the full site. I think this is more cost effective then trying to put everything under one hood.

  • We are looking to get a mobile site developed but still cannot decide between RSS and bespoke mobile site – costs are important and it needs to be done on the cheap as, who knows, it may all need doing again in a year or so when some new device comes out.

  • I would prefer to use either the Responsive Framework or Jquery Mobile depending upon the situation.
    If there is mobile specific site , Jquery MObile is better option. In case if one design for all approach then resposnive framework is better. Twitter bootstrap and Skeleton are pretty good now supports IE7 too.

  • If such condition occurs like if we zoomed the page , the original design may be lost in that cases you should use following code in your css and make changes according to zoom of page.
    suppose you are at 1024px width resolution of your screen, someone zoomed now your screen is at like 800px relosoln then you can use following cssmedia
    @media all and (min-width:800px) and (max-width:1024px)
    code if page is zoomed

  • Mobile specific sites are always subsets of main site and one of the major issue had been redirecting to main site. But its good to have a mobile site if certain content to the user.
    Whereas responsive site might be good idea if we want to show all the content to the user and hence over all site. Most of the things can be done with good design, table can be bit tricky though.

Get the latest in Mobile, once a week, for free.