It's astonishing how much "responsive design" gets thrown around as a buzzword...however, unlike a lot of buzzwords, "responsive design" actually means something and implementing it has implications systemwide...Across legacy sites, I've almost never seen it implemented in a way that didn't hide critical information, often because the designers and the people in charge of the legacy CMS probably don't coordinate enough. Things like, "Make everything that isn't in a p or image tag go to the bottom of the page" can hugely affect the context of certain elements.
For example, I worked on a site that hand hand-coded captions for photos and so those captions ended up having tags that were displayed:none when the device had a low-enough width. That's not great for photos that require the context of the captions.
It's astonishing how much "responsive design" gets thrown around as a buzzword...however, unlike a lot of buzzwords, "responsive design" actually means something
Unfortunately, it is one of those technical terms that is now so widely misused by people who don't know what it originally meant that it is becoming diluted to the point of uselessness. The original principles of responsive design as outlined by Marcotte are one, but only one, useful set of tools for adapting web sites/apps to support users with different devices.
These days, any web site whose CSS says @media somewhere is getting described as "responsive", which makes it difficult to have intelligent conversations about alternative strategies, such as those that don't use flexible grids or techniques for adapting media other than static images to different viewing/listening situations.
Indeed. The thing that annoys me about responsive design is when I browse on my phone and can't find what I'm looking for so I "Request Desktop Site" and it's the same! Grrr. Even worse when they STILL serve me all those images, but they are just hidden, eating up my limited bandwidth. Double Grrrr.
No, that's not correct, at least in my experience. "Request desktop site" usually means "reload the same page, but send a User Agent string so the server thinks I'm calling from a full desktop browser". This works for websites where the server does some UA string sniffing and sends different html+assets for different types of devices.
The same works in reverse. In Chrome Dev Tools I can set the UA to iPhone/iPad/Android (http://imgur.com/mJY6lP6) and I should expect to see a mobile version of the site. Of course, with Responsive this does not work since responsive looks at screen size, not UA string.
For example, try changing your UA string in Chrome to iOS 6 and visit http://www.bbc.co.uk/
Both the OP and your reply emphasize the what/why... are there any resources available explaining how? If not, it sounds like this is a great opportunity for some blog posts!
Along the line of "you won't have time to edit eveything" is you should have some form of legacy rendering, so that your old images/assets can look "decent" in the new layouts/containers without actually updating everything. This might be as simple as providing alternative layouts for old image sizes, etc...
Depends. If you want to get a budget and work to do in a big corporation, that's exactly how you should do it.
You simply need to drop your petty concerns about the quality of your work at start looking at building your own personal fiefdom within the empire. Learn the critical formula, success = ass_kissing + buzzword_compliance, and you're off on your magical race to the middle! Within 20 years, you'll be staring at the layoff pink slip in your hand, looking back on a life of mediocrity and forward to being unhireable anywhere else, wondering what went wrong.
For example, I worked on a site that hand hand-coded captions for photos and so those captions ended up having tags that were displayed:none when the device had a low-enough width. That's not great for photos that require the context of the captions.