Does not really work. Because it just renders stuff in an iframe. But actual devices behave quite differently. For example an ipad fools the website about its pixel size. So it renders very different from how its displayed here.
For example meteor.com fits nicely into my ipad and even into my android phone. But this page makes it look like it does not fit at all.
Also tried other sites and had the same effect. Sites that have no magic css/js to cope with different screen sizes or devices. They work on the devices and not on this website.
Maybe I understood it wrong, but, wasn't the point of this showcase to show how it should look rather than how to make it look like that in all of the devices?
I think it wasn't meant to be the kind of thing you open in your different devices and look how it looks rather, this is how content should adapt, does it make any sense?
The tool is for demonstrating what's meant by "responsive design" to lay/non-web people. So it isn't trying to show how a non-responsive site without any "magic css/js" like meteor.com might display, or replicate the behaviour of any specific device or mobile browser. It's specifically NOT designed for actually testing designs - you need to do that with actual mobiles and tablets.
That's why you set the initial scale to 1.0 when you're designing a responsive website. This disables the default iOS behaviour to scale a website to fit within the screen.
One thing in favour of the idea of professional-body approved programming qualifications is that we could take them away from people who do this. Anyone who implements "no-scaling" and anyone who worked on a browser that pays attention to it.
It's awful for usability, and behaviourally as obnoxious as letting the caller decide what ringtone a callee's phone should play and how loudly, or breaking the 'back' button, or having a 'you can't close your browser or power off your device while looking at this website' option.
The scaling behaviour can be just as bad for usability on a site that's been well optimized already for mobile display.
As an example, iOS zooms when you select a text input field. If I've already adjusted the design to work nicely at 320px wide, the zooming is unnecessary, makes the page look odd, and the user has to manually zoom back out when they dismiss the keyboard. Another problem example is where the "zoom" multi-touch events conflict with something like Google Maps - should the browser zoom the page, or the map div?
Disabling zooming just makes it function more like a dedicated app - they don't zoom either. If you want to take away people's programming qualifications for making positive steps towards usability, I'm glad you're not in charge of the professional standards.
If you've fixed the design to 320px that's about half the width of my phone screen and a quarter of a portrait tablet screen.
Dedicated Apps are dedicated to my device, mobile web pages aren't.
Mobile Safari doesn't automatically zoom because Apple were to rushed to take that feature out, it auto zooms because Apple went out of their way to add it. Same with the phone/tablet/whatever. You don't know why I'm zooming either, maybe I'm in a moving vehicle or using it at night in low brightness and can't see well, or without glasses or when tired or while holding something else and viewing at a distance or anything.
As a principle, content is there to be used not to be aesthetically perfect, and content overriding the local display device is giving control to someone without the context to make useful decisions.
I know apps don't zoom - haven't we been complaining about resolution independence in desktops and implementing magnifiers and ctrl-scroll and other clunky workarounds because of this for many many years?
> If you've fixed the design to 320px that's about half the width of my phone screen and a quarter of a portrait tablet screen.
Take a look at Twitter's Bootstrap. It has a variety of different responsive design levels, not just one at 320px. Great example of how a design can fit many different devices.
> Mobile Safari doesn't automatically zoom because Apple were to rushed to take that feature out, it auto zooms because Apple went out of their way to add it.
Yes, and the reasons they did are good ones - many sites don't have a responsive design.
You know what else Apple went out of their way to add? The ability for a web developer to disable the zooming feature!
> ... maybe I'm in a moving vehicle or using it at night in low brightness and can't see well, or without glasses or when tired or while holding something else and viewing at a distance or anything ...
A trade-off I'm willing to deal with. There are accessibility features in iOS and Android for most of those situations, so I'm fairly comfortable making the site work best for most people instead of the small number edge cases.
You know what else Apple went out of their way to add? The ability for a web developer to disable the zooming feature!
Implementing a complete specification isn't "going out of your way", it's very much in your way. It's also not saying you endorse every feature therein. (From a quick search, this appears to be a part of CSS specifications: http://dev.w3.org/csswg/css-device-adapt/#the-lsquouser-zoom... ). Creating features from scratch is going out of your way. And creating features which allow you to zoom in on any site feels like a strong endoresement that zooming in is generally useful.
Take a look at Twitter's Bootstrap. It has a variety of different responsive design levels, not just one at 320px. Great example of how a design can fit many different devices.
More sites aren't designed well than sites which are designed well. I'd rather put my moment by momnent usability of something ahead of the designer's musing about what "should be more usable" any day. And the abuse of such a thing is to disable zoom for the designer's sense of aesthetics over the user's sense of usability, and I suggest that happens much more than the designer using it to increase usability. And that's a trade-off I dislike having to deal with.
It's a proposed part of the CSS spec because Apple created the viewport meta tag. I'd call that "creating features from scratch". Go on, find an example of the viewport tag prior to the implementation in iOS.
I think the jump is more realistic, it means the resize event will only be fired once. Which is what the orientation change on a mobile device would do.
http://responsive.is/ animates the iframe resize meaning the event will be repeatedly fired.
Scroll bars are frustrating given the amount of effort put into this, plus the sites I tested aren't rendered the way they actually appear on an iPhone meaning I wouldn't be confident showing this to clients.
This doesn't work with sites that return 'X-Frame-Options: SAMEORIGIN' or 'DENY', which is probably the simplest and best click-jacking countermeasure. It's used by some big sites (e.g. Google), and increasingly used by modern frameworks (e.g. in Django 1.4 it is not yet on by default, but extremely easy to enable - just uncomment one line in the default settings file).
I'd love to be able to send an email to some potential clients along the lines of 'Have you thought about responsive design? Here's why it matters in the context of your current site.'
Nice idea, would be even better executed if the "embedded webpage" would be clipped to the device frames during resize.
Clicking on the landscape iphone while in portrait iphone mode shows the full landscape embedded webpage on top of the frame while the frame resizes, which is kinda jarring.
I'd just like to say, thank you very much for the heads up here. This looks SERIOUSLY cool and seems like it would solve all the niggling issues we've been having with mobile web development. Can't believe nobody else here has jumped on this
Wow. Thanks for the all responses people. There are some really good suggestions here. I have added the project to GitHub for anyone interested in improving the tool.
Great idea. One improvement might be to make the mobile view look more like a mobile device; now it looks very much like the tablet. Perhaps the borders (sides in portrait, top and bottom in landscape) could be thinner.
If they don't like it when you're at this stage, you're in trouble! How are people presenting/explaining responsive designs at the concept stage? Designing in browser? Multiple mockups? Mood boards and style guides?
One of the common "mistakes" I see with these tools is to base the iframe size on exactly 320 or 480, etc. The scroll bar should be outside of the width of the "device".
Yes. But clients will understand this one better, with different known devices right in front of their eyes. Some of our clients can't map a resized browser window to a smartphone <-> tablet switch.
I agree. Just pointing out that it's not doing anything to emulate any of the behaviour of any device. It's still rendering as whatever your browser will show for those sizes, same user-agent/css/javascript behaviour. Still, as a demonstration tool it will be very useful.
For example meteor.com fits nicely into my ipad and even into my android phone. But this page makes it look like it does not fit at all.
Also tried other sites and had the same effect. Sites that have no magic css/js to cope with different screen sizes or devices. They work on the devices and not on this website.