Do Mobile And Desktop Interfaces Belong Together?

Advertisement

The term “responsive design” has gathered a lot of well-deserved buzz among Web designers. As you probably know, it refers to an easy way to dynamically customize interfaces for different devices and to serve them all from the same website, with no need for a separate mobile domain.

It solves one major problem, and very elegantly: how to adapt visual interfaces for mobile, tablet and desktop browsers. But when unifying a website, you have to solve problems other than how it will appear in different browsers, which could make the task much more difficult than you first realize. A solid design has to account for differences in interaction when using mouse pointers and when using touch gestures, as well as the bandwidth constraints on mobile users.

You might also have to restructure content according to how much information it makes sense to present on each screen. And the new breed of mobile Web apps that leverage HTML5’s offline capabilities might have to be built much differently than conventional desktop websites. Hopefully, after considering these problems, you should be able to implement a responsive website that is suitable for all devices; but you’ll need a fallback plan if that’s not possible.

This article looks at how a typical responsive website is targeted to mobile handsets and tablets, contrasting it with its desktop-facing sister website. It considers how such a website might also be deployed as a cached HTML5 Web app, and why you might want to do that instead. For various reasons, discussed here, you might decide to target your responsive design more narrowly as a hybrid for smartphones and tablets, keeping it separate from the desktop interface. For those of you who opt for this route, the remainder of the article will explore ways to better integrate the different websites, or Web apps, and how to make it easier for users to learn about the appropriate interface, get to it and stay there.

A Responsive Design For Mobile And Tablet

The BBC recently started rolling out a new version of its mobile news website1, which serves as a perfect example of how to adapt an interface very effectively just by detecting the screen’s width. Below is the same page viewed with different layouts targeted for the iPhone and iPad. You can see the interface transform dynamically by viewing it in a desktop browser and resizing the window:

BBC mobile UI2
BBC tablet UI3

The single-column mobile interface transforms into a multi-column interface more suitable for tablets, with a richer set of navigation options appearing at the top of the screen. While the multi-column interface is a bit more complex, it’s still cleaner and less cluttered than most desktop-facing websites. BBC News, along with similar websites such as the Boston Globe4 and Smashing Magazine, exemplifies the trend towards “mobile-first” design; i.e. starting with a clean mobile design and progressing upwards as needed, rather than trying to jam a full desktop-style interface into a single column. Most responsive websites rely on CSS media queries that reference screen widths, but they can also respond to specific browser features and exhibit fallback behavior that “progressively enhances” an interface.

These techniques are so easy to apply that you might wonder why not all websites are built like this. It could simply be due to inertia, in which case developers need to do a better job of spreading the word. But the next section explores what may be deeper reasons.

Why Desktop Is Different

The adaptive interfaces referred to above are a healthy development, one that could lead to uncluttered desktop interfaces in the future. Still, there may be times when mobile or tablet interfaces should feature a different set of content than for desktop browsers. For one thing, media queries use up precious bandwidth. The BBC’s desktop design5 features a much richer set of content around the margins, such as ads and sidebars, which you’d typically exclude from the mobile interface.

BBC desktop UI6

Unless you perform feats of conditional loading for various regions on the page, any content that you hide using CSS’s display: none declaration is still served to the browser, perhaps at considerable cost over a mobile network.

A desktop page also features a much richer set of navigation options, especially up in the banner. On many desktop websites, users have drop-down menus to access nested categories in a single move. But in mobile interfaces, each set of navigation options is usually presented one at a time; for example, with iPhone-style sliding drill-down menu panels. You might also have to fix navigation elements to the screen, so that users don’t have to scroll to the top of the page to access them. Imagining how you would consolidate such requirements within a single hybrid website might be fun, but it can certainly get complex. Desktop websites can also rely more heavily on navigation driven by search, which is more difficult to manage with virtual keyboards.

Below is the sort of adapted mobile interface you might encounter in the wild. Those tiny navigation tabs might be fine for a desktop interface, but they are uncomfortably small for a touch interface and should serve merely as visual cues. Increasing their size would only crowd out other screen elements and limit the total number of tabs you could use. In this situation, swiping left and right to navigate the panels would be natural for mobile users. You could certainly add support for touch gestures to a mouse-driven website, but that’s another input mode to account for and to integrate in the interface.

789

Most of all, mobile users are usually in a different frame of mind than desktop users. We can’t really make any precise assumptions about the context of the device usage, but compared to desktop usage they quite often will be standing up and walking around or driving, and sometimes just scanning their handset or tablet. This might call for less detailed content than what you would use for more focused desktop users. Instead of presenting all of the day’s news items, for example, tracking unread items or the most popular trending items might be more important. Users might also want different content depending on their location. Even viewing a browser in full sunlight calls for a higher-contrast design, with fewer details that would make you stop and squint. Other times, such as when waiting for a connecting flight, mobile users will have more time on their hands and attention to spare. Overall, mobile contexts are far more varied than desktop and laptop contexts.

Even though mobile handsets and tablets are much more varied in size, their similar usage patterns and reliance on touch gestures could make deploying a responsive interface for those devices easier than deploying one that also targets desktop browsers.

Mobile Web Apps Vs. Mobile Websites

Using media queries to adapt an interface is a powerful technique, but we must recognize how superficial it is. It does little to address the particular needs of cached mobile Web apps, which could be built much differently than conventional websites. Consider how the BBC’s website is deployed. Users navigate links to load separate pages, and the overall set of available URLs shifts as the news changes.

A Web app might rely on the HTML5 application cache. A small set of HTML and other files would load once and install in a browser cache, and then populate data dynamically using AJAX. Assuming that you also cache the data, users would be able to open the application and retrieve the news in the absence of a network connection (a common “reading on the subway” scenario), with data updating once the browser detects that it is online again. It’s a much looser system that adapts to the more wide-ranging needs of mobile users.

A cache is implemented as a manifest file that’s specified at the top of the HTML file and evaluated before the rest of the HTML loads:

<!DOCTYPE html>
<html manifest="appcache.php">
<!-- the rest loads conditionally -->

The manifest lists all of the component files that need to be cached. The example above uses PHP to specify the correct MIME type within the markup, rather than as a server configuration option:

<?php header('Content-type: text/cache-manifest'); ?>
CACHE MANIFEST
# version 1.0; change version# or other content to update app
CACHE:
index.html
css/styles.css
js/app.js
img/home.png
img/about.png
img/back.png

The first time you land on the page, all of these files will be cached. After that, they are reloaded from the browser’s cache without ever touching your server. Only by changing the content of the manifest will the files be refreshed from your server. The JavaScript might communicate separately via AJAX, but typically with some sort of fallback for offline use.

This way of structuring a website as a fixed-footprint package of files doesn’t adapt well to more conventional server-driven websites. There would be no point in caching an application whose set of component pages changes frequently, as the BBC’s does with each batch of news.

Web apps are becoming popular because they offer developers a cross-device alternative to native application platforms. Most features of native apps can be implemented as browser-based apps, executing on the client as if the app had been formally “installed” from an app store. Web apps can be accessed on most platforms using icons on the home screen, and they might be set to hide browser controls in order to take total control of the interface. Once a Web app is saved to the home screen, there may be nothing to indicate that it is being implemented as a Web page.

The following lines, placed in the page’s head region, target different devices with different-sized home screen icons, with the precomposed fallback that is supported by some Android browsers:

<link rel="apple-touch-icon" href="img/app_iphone.png" sizes="114x114" />
<link rel="apple-touch-icon" href="img/app_ipad.png" sizes="72x72" />
<link rel="apple-touch-icon" href="img/app_nokiaN9.png" sizes="80x80" />
<link rel="apple-touch-icon-precomposed" href="img/apple-touch-icon-precomposed.png">

The following line enables full-screen Web apps on iPhones. Thus, when the user selects the app from the home screen icon, nothing on the screen would tell them that the app is running in a browser:

<meta name="apple-mobile-web-app-capable" content="yes" />

These three features — the application cache, home screen icons and full-screen mode — are what most strongly distinguish mobile Web apps from ordinary Web pages. To get into more details about the Application Cache, make sure to read Jake Archibald’s article Application Cache is a Douchebag10 on A List Apart.

Traffic Control

For all of the reasons discussed above, websites that were created specifically for certain device classes might be easier to control and optimize. Either forking or consolidating a website has its pros and cons. Having a single access point means that the same URL will serve the content to all devices without the risk of losing context, but with the extra cost of designing and maintaining a structure that fits all needs. Developing separate websites tailored to different device classes means you can focus on highly optimized content, but at the cost of maintaining more than one design. With the latter approach, you might also have to consider ways to maintain context when the user jumps from one interface to the other.

On many websites, if you land on a page with the “wrong” browser, nothing happens. Many websites seem to assume that users are aware of the availability of a separate mobile website and don’t account for the likelihood that they’ve landed on a random desktop-facing page via a Facebook or Twitter link. At the very least, each website should link to its various interfaces, as done at the bottom of many BBC pages:

1112

Alternatively, consider placing such controls prominently at the top of the page, otherwise the availability of an alternative interface might not be obvious. Pages designed for the desktop usually don’t specify a viewport13, so they would load with tiny content on mobile devices. The user would have to zoom in to view the page, then scroll to somewhere around the bottom of the page to find the link, if they even thought to look there. Assuming that visitors to your website have just arrived from the planet Neptune is not a bad idea.

The BBC uses another approach, simply redirecting many smartphone browsers from the desktop website to the mobile website. If you decide to navigate back to the desktop website using the link at the bottom of the page, the URL will be appended with a ?mobile, which prevents another redirect from firing. That works during each browsing session but is not saved as a preference.

You could instead prompt users to go to the other website, but be sure not to do so every time they visit, or else it will get annoying. The simple example below is relevant if you host different websites on the same domain. It sends a prompt and uses jQuery to cache the answer as a domain-wide cookie. The matchMedia API offers the ability to test the same set of CSS media queries that you use to assign the layout, but instead calling them from within JavaScript:

function checkRedirect() {
    // media query
    var query = 'only screen and (max-device-width: 800px)';
    // from a page on www.foo.com
    var mobileUrl = 'http://m.foo.com/';
    // does the user already prefer desktop UI?
    if ($.cookie('preferMobile') == 'n') return(false);
    // is app running on a mobile/tablet browser?
    if (!!window.matchMedia && window.matchMedia(query).matches) {
        // has user already stated preference for mobile UI?
        if ($.cookie('preferMobile') == 'y') window.location.href = mobileUrl;
        // get user's preference
        if (confirm('Would you like to try the web app instead?')) {
            $.cookie('preferMobile', 'y', { path: 'foo.com' });
            window.location.href = mobileUrl;
        } else {
            $.cookie('preferMobile', 'n', { path: 'foo.com' });
        }
    }
}

The destination page would have to feature a control to reset the preference. Otherwise, users who change their mind would have no easy way to view the desktop interface without once again being redirected to the mobile interface. If you used the browser’s localStorage feature to cache the preference indefinitely, then its scope would be limited to each host name, rather than available across the entire foo.com domain. So, cookies are still good for something.

Once you’ve refined the basic redirect mechanism, devote some thought to how to retain more detailed context. Otherwise, users might become disoriented when they navigate back to the information they originally expected. If the URL structure for each website is the same, then a contextual redirect is as simple as modifying the host name:

www.foo.com/news/local/041912/police-log/
m.foo.com/news/local/041912/police-log/

If the mobile interface is implemented as a cached Web app, then the information would be passed more like this:

www.foo.com/news/local/041912/police-log/
m.foo.com?category=news&subcategory=local&date=041912&item=police-log

The Web app would then dynamically respond to the query portion of the URL.

Promoting Your Web App

Many websites present splash screens that alert users to a native iPhone or Android app, but there’s no simple way on a Web page to check whether such an app is already installed. There’s also no way to open the app so that the user can view the content they are looking for.

Because they’re basically Web pages, Web apps are easier to integrate with your other Web pages. Matteo Spinelli has a useful “Add to Home Screen14” script that tells users how to install the mobile page as a Web app. So far, there is no single Web application-store portal to help users find Web apps to install, so the script might be the best way to raise awareness for now. The script points to the button on each handset that the user needs to press in order to save the Web app. These screenshots show how it looks at the bottom of the iPhone and at the top of the Nokia N9:

1516
(Source: Let Me Spell It Out for You17)

This useful feature can be set to prompt users to install the page only after they have landed on the website more than once.

There’s not yet any reliable way to track how many users follow through and save the page as a Web app. But you could enhance your website with an interesting workaround for the iPhone. If a page is enabled for full-screen viewing and the user saves it as a Web app and then loads it from the home screen, the browser controls will disappear from the interface. At this point, the standalone property will indicate that the user is accessing the full-screen app from the home screen, which you can interpret as a preference:

if (window.navigator.standalone) $.cookie('preferMobile', 'y', { path: 'foo.com' });

However, the standalone property is contextual. It returns true when the user loads the page directly from the home screen, in which case the page will have no browser controls. But if the user navigates to the page conventionally within the browser application (such as via a redirect from a desktop-facing page), then the browser controls will still appear and standalone will return false. So, it’s a good way to track interest, although not to track the lack of interest among users who later decide to remove the Web app.

The W3C is formulating a more comprehensive full-screen specification that might fix such problems in browsers. Until then, apply a flexible screen layout to account for visitors who land on the page with or without browser controls.

Conclusion

This article asks whether your desktop and mobile interfaces really belong together and whether they should work as a single client-adapted website. This question has no single answer, but asking it is important. We’ve explored some of the reasons why the answer might be no, particularly if your needs are complex.

But your goal, as a developer with a vision of a unified design and an appreciation of technical elegance, should be to be able to answer yes, having dealt with those issues. Just don’t focus too much on visual design to the neglect of variations in interaction design, information design and underlying deployment. Be prepared if the answer is no. If you find you have to split off your desktop website, find ways to make the overall experience as graceful as possible for users, regardless of whether they land on one of your pages via an external link or via a home screen icon. That’s the whole point of responsive design.

(al)

↑ Back to topShare on Twitter

  1. 1

    Nice article!

    Regarding promoting your app on the webpage; Apple has announced a new feature in Safari (iOS 6) called Smart Banners (or Smart App Banners). This is simply a small banner-area displayed at the top of the browser.

    Here you can promote your app with a direct link to AppStore. The code for implementing this is really small. I think it’s just a meta-tag actually. The App is shown with the app-icon, a little description, and a link to open it (if installed), or a link to download it. I think this is quite clever.

    I know this is Safari-only, but it might be possible that we’ll start to see similar features in other browsers as well. Seems like they’re all establishing their own “app store” these times.

    http://www.imore.com/smart-banners-safari-ios-6-offer-quick-shortcuts-app

    2
    • 2

      The author is correct in asserting that media-query, responsive design approaches are performance drags on smaller devices since content is merely hidden after being loaded. This is a very primitive means of achieving content-on-demand and a major step backwards in front-end architectures.

      0
      • 3

        I think those that have written about responsive design extensively, have said that no content should ever be hidden from the user just because they’re on a mobile device. In fact, some have even said that if it doesn’t need to be shown to mobile users it doesn’t need to be shown to anyone, so remove it.

        That’s why sites like BBC News, continuing the article’s example, can’t really use responsive design fully, because the full website uses large amounts of images, css and javascript which is stripped out in the mobile version.

        However, you’re right, if you hide most of the content you load, it’s very wasteful!

        0
  2. 4

    I’m really getting frustrated by comments like this “Most of all, mobile users are usually in a different frame of mind than desktop users.” and this “Instead of presenting all of the day’s news items, for example, tracking unread items or the most popular trending items might be more important.”

    First of all, why do people feel that users have different needs on mobile than desktop. Using news as an example, top/popular/trending stories are important to mobile users, however they are just as important to desktop users. The first thing the user is looking for hasn’t changed.

    Also, how often have you sat on the couch watching tv and used your mobile phone to consume content? I’ll bet quite a bit. Does that mean you want a limited amount of content? No. Users are using there mobile phone to access your content more and more. Some users may never access your site with a desktop. Shouldn’t they have access to all the same content.

    I’m not saying that the interface shouldn’t change to make accessing the content easier on a small touch device, however we should be careful when making assumptions that mobile users only want certain pieces of content. I work for a large content site and we have done a large number of user tests that have all come back with the same user priorities across all devices.

    29
    • 5

      Very well said, Dave. But this may be the point for large content sites. As the name says – content sites. The site depends on content while users actually read it. When you build websites for big platforms that earn a dollar with conversion or that guide users to click specific links, things are very different. You have a different scenario and may want to optimize the mobile experience, so that people click your link faster and so that the conversion is high. When users really want to read everything, they’ll click the “full site” link for sure.

      0
      • 6

        I disagree! Why on earth would you shun and inconvenience a mobile user just because they want to see “everything”??

        As Dave said, there are so many users who never visit the website using a Desktop machine, so while they may indeed click “full site”, they’ll then be given a huge site that they have to swim around in and while they may make the effort to read the article, they won’t be as satisfied, and probably wont continue to use your site.

        It doesn’t matter what the site is, or how the site is making money, if you need the user to click specific links to earn money, place them at the top, more prominently, change the layout. But don’t hide the rest of the content so *you* can gain while your *users* suffer!

        2
    • 7

      I’m curious as to whether people have done surveys, analytics, or focus groups to determine whether mobile and desktop users are doing the same tasks. Personally, my mobile phone usage is a subset of what I do on the desktop, while my tablet usage is similar in scope. However, I’m reluctant to assume that other users consume content the same way I do.

      2
  3. 8

    Fantastic article!!

    0
  4. 9

    Great article!

    As a Front End Developer that works on Enterprise level sites this great be a good way of getting the ‘best of both worlds’ when building websites that can know server side what the type of device is and adjust accordingly all while keeping a base responsive layout!

    0
  5. 10

    Mike great article thank you for putting this together. I’m hopeful with continued improvements in html 5 features we can continue to blur the line between native apps vs web apps

    0
  6. 11

    Dave is right, some people never use desktop. Limiting content for mobile devices is a bad way… since in most cases bandwidth is not the problem.

    That’s why I made http://responsivedesigntest.net … to test my designs.

    We run a job portal for students and a lot of them do access the site with their phones. Limiting content would be a bad move.

    4
  7. 12

    I love all the buzz around responsive design, but here’s what gets me the most about it.

    I agree users have the same intentions on desktop as they would on mobile as Dave said above; and I certainly think it’s a performance nightmare as Ronny said, especially given that browsers pre-fetch content making responsive design with media a near impossibility. But isn’t the whole point of responsive design to respond to the users needs? If users have a small screen they get an optimized version of the site showing all the content necessary to help them consume the site owners content; and if they use a tablet they get all the benefits the tablet/touch interface has to offer, and a desktop interface gives them more room to browse and consume content. This is great that technology like media queries have been created and exploited for all sorts of intriguing techniques and sites.

    But who’s to say that users care about whether the site runs on the same code base. This is one thing as developers we always forget; and this is the one thing that, while I agree with the idea of responsive design, I disagree with how people chose to implement it. It’s not about us or how pretty our code is; its about the user and how they can consume our content and accomplish with it what they set out to do in the easiest way possible. The user doesn’t care if we use 2 different code bases to give them a mobile-optimized site and a desktop-optimized site. We care because we think its easier to maintain. I challenge that a responsive designed site is easier to maintain then a well developed MVC site with multiple views for mobile, tablet and desktop.

    I work on a fairly large site, one of the top 20 according to comscore based on traffic. I built the UI for the desktop version using PHP, HTML, CSS and JS/jQuery. We use an MVC framework for the PHP/HTML and no CSS preprocessors. The code is clean and very easy to read and understand. And with the work I’ve been doing lately, its going to improve drastically. I’ve also built our mobile optimized version that is going to release very soon and its built on the same MVC framework using a lot of components from the desktop system. If we were to change the designs up a little bit more to match a consistent style guide, then I could probably accomplish a lot more code reusability. I’ve also been challenged by my superiors to come up with a responsive test to see how that would run and I have to admit, it was easy to implement; but its very hard to follow and explain to the rest of my team, doesn’t look the best and I don’t’ see users open the site on their desktop and resizing all that often so now one will see the smoothness in the response.

    All that aside, I wish the responsive movement would turn into less about the implementation and more about the idea/concept that we need to give users different experiences and more optimized ones for the various platforms there are and will be in the near future.

    3
    • 13

      If you had said this a few years ago I may have agreed, but there are so many devices being released now and all with varying screen sizes. That means it would make it much harder to have multiple implementations the amount you would need would keep growing, unless you made your multiple implementations some what responsive. If you go that route you may as well just make one implementation and work a little more on the responsiveness.

      With regards to the issues you found on your responsive test: it would only be hard to follow because it’s a new mindset give it some time for you and your team; you can accomplish any of the same looks I am sure again this may be a learning curve; and I often resize web pages and the more it becomes available to people the more people will want it on every site, so get on the band wagon before it’s too late.

      The responsiveness movement to me means no matter what device I’m on or what my browser size is set to, I get an experience that is: similar in design; functionally optimized; and I can’t stress this one enough gives access to the same content. I even believe that if your advertising for desktop sized browsers you should be advertising for mobile sizes as well (yes I’m talking to you SM). I’m going to stop myself here though as I could continue on a whole separate tangent on ethical advertising (this ones not directed at you SM).

      3
  8. 14

    A very good and comprehensive article but this article is more towards problems than solutions. I hope another article with solutions to these problems is followed up.

    Performance is the reason which stops me implementing media queries. As you are still loading the content which mobile screen don’t need.

    I hope a good solution can be found through which we can load only the required assets (in a required quality) which a mobile screen need.

    0
    • 15

      Use a mobile first design, that means design for mobile devices then use your media queries for desktop sizes instead of the other way around. If required you could also load the needed desktop css and images using javascript.

      1
    • 16

      I think that’s why the article references BBC News, they have so much content and Javascript enhancement that they can’t have one page to fit all. In which case you have to redirect or offer the alternative, as the article suggests.

      Robert Speed also makes the good point that mobile-first generally works around this problem, The Boston Globe uses javascript to draw in the images for the Desktop version of the site after it works out what size the screen is, it serves mobile images to everyone so Desktop users get double the number of requests, but mobile users get the most optimised experience. It’s not perfect, but it moves the burden on to the Desktop user who is generally more likely to have fewer bandwidth restrictions than the mobile user!

      2
  9. 17

    First, just one big prop to this article, it brings up all the right questions!

    It really amazes me how people think about “Responsive” Development and how little they know about it. This isn’t about a specific individual, it’s more generally speaking.

    To get to RWD and talk about its performance, we should take few steps back and see how the desktop version is performing first and after that move toward different technology.

    “Responsive” should not limit the content no, however it also can’t be 100% the same as mobile content. Content doesn’t apply to all sites equally, just imagine BBC, CNN or Fox to load their desktop version into mobile, that wouldn’t look good would it?

    Now going back to article itself. Mobile Apps and “Responsive” layout are two different things, if we load in the “special” app just for mobile users, well that’s no longer “Responsive” per se, because we’re stepping out to e.g. Google’s http://www.howtogomo.com. True “Responsive” layout when talking about news would be http://bostonglobe.com, try resizing the browser on Boston Globe and do the same for BBC or similar.

    Thanks,
    Emil

    2
  10. 18

    Nice article, I wasn’t aware that there were quite so many ways of providing a near native app experience using a web app! As has already been said – the app store integration is one of the last (and sadly most important) steps.

    As I and others have already said, the scenario in which a mobile device is used shouldn’t at all be generalised as “quick, in a rush” type situations, I’m sure I’ve heard something along the lines of 40% of mobile users for a site won’t ever visit it using a desktop computer, so if you’re hiding content for the mobile site you’re hiding it from a possible 40% of your users!

    Other than that (and my surprise to see adverts on BBC News, being from the UK where we don’t get them!), this is definitely a useful article. I especially like the “Add to Home Screen” prompts!

    0
  11. 19

    Well, on a personal note, I bought a mobile device for quick browsing and fast access to things I need.

    I personally do not want to waste time and my 1gb limit loading up a responsive desktop website with all the same things as the desktop version. Imagine a whole responsive website with images etc etc with limit of 200MB . And now that LTE has been lighting up all over canada and the usa, data is being consumed very fast. I personally like to see desktop and dedicated mobile development. Responsive is nonsense and so blah. Majority of responsive websites all look the same and very boring,using the same grid system layout etc .

    Though tablet users, want to experience the desktop web on a tablet. That was the whole point and marketing of a tablet.. Experience the desktop web on your tablet, therefore why are people making responsive website for tablets, let them experience what they bought the tablet for.

    1
  12. 20

    Regarding the “Promote your webapp” section: It’s a nice idea, but unfortunately it is broken, since a lot of mobile web surfing is done via embedded browser windows in apps like Facebook and Twitter. Which means that users find themselves with a splash screen with an arrow pointing at…well, nothing.
    I guess in the future this could be solved with API-based access to core phone functionality. But that’s a long way from now.

    0
  13. 21

    I’m curious about how publishers in particular grapple with advertising within the responsive paradigm. I note that when I shrink this page down, the advertising disappears. I love that as a user, but something tells me the advertisers paying for this may not dig that.

    Next are the ad units. For each ad, are multiple sizes loaded – adding more cost to creative?

    Finally, what ads link to must also be responsive. In a mobile site, you know your ads have to link to a mobile/responsive page, but can you do that also in responsive?

    Fun fun.

    -1

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top