Well for the iPad, Facebook provided Facebook Touch. That allowed them to control content to all three devices, and if they are well researched, that can provide a better user experienced. As a back-up, providing a link to the full site means you are not leaving anyone out and giving them all the choices they need for their devices. Not that I am an advocate of separate mobile site in all cases, but I thought browser sniffing is determining the specific browser, then providing an error page if a certain browser is not used. That of course is unmanageable. I have not heard that argument here at all including the article.
Good news, everyone! </farnsworth>
I had thought the boston globe example had been desktop-first, I think because whenever I first load the pages, if I’m on a wide screen, desktopy stuff gets loaded, and if I then shrink my screen, I start getting display: none junk. But mobiles aren’t getting those ginormous images.
There was an interview with some of the Filament Group guys who worked on it by ReadWriteWeb.
The Boston Globe page is really cool. I’ll definitely read that article. I notice they have way less Javascript than on a page like CNN. Since CNN has all that Javascript, I wonder what they would do to keep mobile devices from having to download the unnecessary ones. I am wondering out loud how Boston Globe would handle GPS features, like if they had online classifieds or local news, that would not have to be downloaded by the desktop, and how they would be able to insert device specific content, like that, special for capable devices like iPad and smart phones. I guess since BG is a local paper by definition, they don’t have to worry about that.
Having read the article, it seems to me that they worked hard to solve a bunch of problems using Javascript. Simply adding media queries to the CSS would not have worked because of things like ads. I didn’t even think of ads. What happens if some designer builds a cute responsive site, then it gets really popular and people want to advertise on the site? He better know how to solve those problems to keep the site from breaking.
One thing I noticed regarding the use of liquid images is this:
So, what we doing in the HTML is actually referencing a smaller, low bandwidth image and we figured out a little trickery that if you are on a device like a tablet or a desktop that could use the high resolution image and if it does that is a loaded reaction flip. So, if you are on mobile you get the low resolution image and if you are on a browser or a tablet you get the high resolution image. So, delivering the appropriate image to the appropriate device was another technical challenge that took up quite a bit of work to actually work in a real CMS environment.
I sure would like to know what that trickery is. I downloaded one of the liquid images, and saw that it was 29k (not too bad) and 300 pixels per inch. They don’t go into detail about HOW they delivered leaner images to slower devices, but from all they said, it sounds like a JS solution rather than simply plopping a huge image into the markup and letting the browsers scale it (bad idea!).
I could see using the technique if I could find out the solution they employed. I thought it would be as simple as targeting a new image in the media query for things other than background images.
But overall, what reading the article does show me is what I began to discover when looking into this: Simply reading the ALA article by Ethan Marcotte and thinking you’re gonna go out and build EVERY website to be responsive isn’t gonna work. You better know what the problems could be and be able to solve them.
I sure would like to know what that trickery is.
Me too. It’s likely a combination of feature-detection (maybe also with the meta width=“device-width”> tag? which recently became written entirely as a standard now) and Javascript lazy-loading (again based on features detected).
I was glad to hear no sniffing. Sniffing sucks.
I could see using the technique if I could find out the solution they employed.
I’d say, it’s probably also no secret kept by Filament group, though who knows. Open source man. Possibly Filament Group will publish something, like they did when they built that jQuery+ARIA input slider thing.
Ah, this is a recent post… about trying out cookies for serving appropriate images…
http://blog.keithclark.co.uk/responsive-images-using-cookies/
But overall, what reading the article does show me is what I began to discover when looking into this: Simply reading the ALA article by Ethan Marcotte and thinking you’re gonna go out and build EVERY website to be responsive isn’t gonna work. You better know what the problems could be and be able to solve them.
++
I viewed the source code for the Boston Globe website. But there were several things I wasn’t sure what they were for. What do you guys think about posting lines of code here and picking it apart to try to figure out how to do this? Is that legal? Can we do that?
Now that is clever. And the script looks simple enough. Even if Filament does not release all their techniques, I think what is really important now, is that the Boston Globe project has exposed the problems with larger sites. With that exposure, we will probably see more tutorials like the one you linked to, which is very clever. Looks like we are in the infancy of responsive design and once the issues are ironed out, this could start to become the standard. It’s exciting.
Totally agree. And like you said, Ethan’s article isn’t the answer to everything but I think he realized that also from reading his book. But he definitely started us on a good track. There are still issues to be ironed out. But yes, I think this is definitely the way we need to be moving. Have you guys seen this article by Jeremy Keith called “One Web”? I think as more smartphones advance with their technology and as we as designers advanced in this way, designing sites more responsibly responsive, I think this is the way to go, One Web. I don’t know how to accomplish that yet, but I want to learn and I think even with larger sites such as Boston Globe, I think it will become more and more possible to have one site that works and functions well on all devices.
I think the Boston Globe redesign is pretty well done. That said one of problems I have with it that there is a lot of information on each page. Information that in my opinion would be better served on a separate pages when viewing on a mobile device. It is pretty neat the way that it works, moving things below rather then floating the screen area decreases. Still though I don’t really think that creates a more useable experience than having a separate site, geared toward mobile use. That was my initial impression when I first learned about it – before I even knew it was done my the filament group.
I actually work for a newspaper company and we are in the process of creating a completely separate site that behaves just like a native mobile application using JavaScript that gracefully degrades. Really though the goal is to limit the amount of scrolling to find things, you can’t really do that unless you approach desktop, tablet and mobile differently.
By the way its no secret to how the images are being handled on Boston Globe. Personally, I prefer [url=http://www.sencha.com/products/io/]io as its what I have been using for a few months now and works incredibly well.
None the less there is no one size fits all. Based on business goals and/or budget a responsive design may be better than creating a completely separate website that behaves like a native mobile application. It all just depends on the purpose of the site and budget. For small sites I tend to agree that responsive is the way to go, not only in terms of useability, but practically when it comes to the average budget on a smaller site. However, when creating web applications where there is a lot of user interaction I tend to think its best to provide a native application feel, using a separate desktop and mobile approach to the work flow.
To me, that type of image resizing – basically throwing javascript at it… to me that’s just silly.
Thinking on it, an easy way to do this might be to leverage !important and put the media specific embeds first.
@media screen and (max-width:320px) {
.element {
background:url(images/test320.png) 0 0 no-repeat !important;
}
}
@media screen and (min-width:321px) and (max-width:751px) {
.element {
background:url(images/test751.png) 0 0 no-repeat !important;
}
}
.element {
background:url(images/test.png) 0 0 no-repeat;
}
The first two would only be applied and loaded when their condition is true – and if they are, the last one wouldn’t get applied and/or loaded because it’s not !important. That SHOULD prevent the unwanted ones from even loading in the first place…
Though I’d still not be surprised if some browsers did anyways – they seem to love loading things that aren’t even being applied… print.css when you’re not printing, handheld.css when you’re on screen… seriously stupid.
I have just started doing the responsive design thing with @media queries, but I’m not too far into it and I’m starting to resize the pitfalls and the gothas with this method just might outweigh the pros.
Could you explain this statement with examples? I am really interested in your input here. It looks like this string was in Aug 2011, so I am curious to see how you have progressed with responsive design.
Thanks!
@darose; I think I said that so I’ll respond. 
Back when I first started implementing responsive design I was doing the entire thing with media queries and while that works, I’ve found it not to be the best method. Media queries are not cross-browser compatible and while there are polyfills, I’ve found those to be unreliable and I just don’t like the idea of basing my layout on JS. Instead, what I’ve been doing lately is setting my fonts in flexible em’s, setting my widths using max-width and min-width and utilizing the power of CSS3 (the stable parts).
Examples: I start with this (part of my reset):
body { font-size: 100%; }
Then for fonts, specifically my headings I do this (I could also use percentages, I just prefer em’s):
h1 { font-size: 1.75em; }
h2 { font-size: 1.5em; }
h3 { font-size: 1.125em; }
h4 { font-size: 1em; }
h5 { font-size: 0.875em; }
h6 { font-size: 0.75em; }
For widths, here is a snippet from a project I’m working on:
#content
{
width: 80%;
margin: auto;
max-width: 1200px;
}
What I’m doing here is setting 80% as the base width and 1200px as the max-width. This allows me to have a responsive layout but also a means of keeping my layout contained. In this particular example my Content div cannot flow past 1200px keeping my page looking nice on large monitors.
Some great slides on this are here: Responsive Design Mobile First - Slides. They have been very useful to me and have helped jumpstart me towards responsiveness. Post back and show us how you’ve been implementing responsive design.
I still do use media queries but only use them where necessary, and where I cannot leverage normal CSS to accomplish my layout. Usually I can code an entire layout and only use one or two (short) media queries.
My opinion would be this. If you need javascript, use it, but keep things simple. I would keep all javascript limited, and keep it only to stuff that isn’t so browser-based, and instead only stuff that is universal across most browsers. Of course, that might limit some things, so many people may not like that, and for some of you, it might not even be possible. Luckily for me, it is.
From the mobile topic, I would say to have something detect whether or not it is a mobile device, and perhaps transfer to a sub-domain. IE mobile.yourdomain.com/ . Of course, as previously stated, this option might prove to be slightly useless, as it all depends on how smart your code is at detecting mobile devices, and unfortunately, some non-mobile devices may end up being detected as mobile. Of course, I have not gotten to the point where I have even considered mobile browsers as a large opportunity just yet.