Multi-Screen Site Dev that is Not quite Responsive

Forum Moderators: not2easy

Message Too Old, No Replies

Multi-Screen Site Dev that is Not quite Responsive

Fiver

9:24 pm on Dec 12, 2013 (gmt 0)

Hi!
I'm working with a large video-based site moving from an m. strategy to a one-URL site strategy. When I asked if they were going to responsive design they said 'not exactly'.

They're serving slightly different HTML (not just css) templates for desktop / tablet / touch-mobile / dumbphone.

Reading through the Google documentation they emphasize responsive design, and the 'same HTML' being served on a one-URL site. My question is, just how similar does that HTML have to be?

In this case they would serve fewer videos per page, for example, on mobile.

I can push for making things as similar as possible between versions in terms of text and links, but is that enough for Google, or does the HTML really need to be the *same*? Right now they say about 75% identical links and content, moving towards 90% in v 2.

I can't imagine this is a unique case, but I can't seem to find definitive answers out there, just a whole lot of 'responsive-design is recommended'.

lucy24

10:22 pm on Dec 12, 2013 (gmt 0)

It sounds as if you're describing one of the three possible approaches [developers.google.com]: *

1. Sites that use responsive web design, i.e. sites that serve all devices on the same set of URLs, with each URL serving the same HTML to all devices and using just CSS to change how the page is rendered on the device. This is Google's recommended configuration.
2. Sites that dynamically serve all devices on the same set of URLs, but each URL serves different HTML (and CSS) depending on whether the user agent is a desktop or a mobile device.
3. Sites that have separate mobile and desktop URLs.

We're talking about #2, right? Do you include a "Vary" header? google seems to expect one:

As it is not immediately apparent in this setup that the site alters the HTML for mobile user agents (the mobile content is "hidden"), we recommend that the server send a hint to request that Googlebot-Mobile should crawl the page, too, and thus discover the mobile content. This hint is implemented using the Vary HTTP header.

They go on at some length about the header.

* Really https, but Forums refused to play nice.

Fiver

4:36 pm on Dec 13, 2013 (gmt 0)

Thanks for the reply lucy24, that does lend some reassurance that the HTML differences (as opposed to just css) are acceptable - I have read and we plan to implement the HTTP vary header, but there still isn't a lot of information about just *how much* the content can be seen to vary.

One persons opinion on what is good for mobile can differ from another, and the devs I'm working with want to strip navigation and content elements from category pages, which makes me nervous. Just wondered if anyone had experience with that.

drhowarddrfine

6:50 pm on Dec 16, 2013 (gmt 0)

Completely stripping navigation (and content?) elements is dangerous. People will always look for it on every page. Otherwise they need to realize to use the back button but that's a usability faux pas.

What we are doing on a redesign is considering collapsing the main menu to a clickable in the header bar. Then the menu slides into view.