I just haven't seen a really good implementation of it from a behavior perspective, regardless of what framework or technique is used under the hood. I mean, stacking a three column desktop layout into a single long column for phones is not desirable to me.
And, when I view a full desktop site on a phone or tablet with higher resolution (which is where devices are going), it is typically very readable with the browser's auto-sizing to fit. In rare cases, there is always zooming when necessary. But, resolutions across devices will soon be such that supporting at most two different resolution ranges would be all that is required, if that.
Even if there are rare cases wherein a specific UI can benefit from desktop space where available, with responsive design you'd be making a conscious decision to build a less desirable experience for mobile and other devices. That would imply a separate site with its own UI, optimized as much as possible for the smaller screens. In this case, why try to do so much with each page? Media queries, extensive markup, etc. are effectively adding big, nasty if statements throughout the code. It is ungainly and hard to maintain, even while delivering a sub-par experience. So, if you really are trying to deliver a remarkably different experience per screen format, then it is better to consider a separate site/page-set, IMO.
I think higher resolutions, better browser capabilities, and other changes will make responsive design a "remember when" in the not-too-distant future. And Web designers/devs will breathe a collective sigh of relief, just as we have all done in the past when various painful and short-lived fads went the way of the dinosaur.
But again, maybe that's just me!
I'd like to add that responsive design doesn't have to be an annoying exercise in which developers try to flatten a full-featured site into one column. On the contrary, they can begin by developing a site that works well for mobile, then expand it into a Desktop version.
Designing the mobile experience first can be conceptually useful because it helps developers zero in on the features that are most essential. I did this recently while creating a mobile browser-based geocaching app. I would have liked to have created a single version for mobile and Desktop. Device resolutions are improving, as you said, but I knew that my prospective users had iPhones and Androids with relatively small screens.
Developing a minimalistic version of my Web app in the beginning helped me to focus and hone in on the most important features. This approach may not work in all cases, but I think it's a useful aspect (maybe a side effect) of responsive design.
I probably should have been clear that the one column thing was just an example. I agree that there is certainly more to responsive design than that, else it would be much easier!
But, what you mentioned with regard to being more thoughtful about the design and distilling it to its minimalistic essence is partly where I was going, except to a different conclusion. That is, if such a clean, focused design can be achieved, then what results is a Web app that could likely work well across devices.
But, if that minimalistic design leaves much to be desired on the desktop (i.e. a remarkably better experience can be delivered because of the additional available real estate, well then we are likely talking about a fundamentally different design. In that case, I say build it out separately vs. trying to have each page, CSS, etc. pull double-duty.
>Developing a minimalistic version of my Web app in the beginning helped me to focus [...] it's a useful aspect of responsive design
Good point. But, I think that's more a side effect of mobile-first than responsive design.
Select an article, and the content menu slides off canvas revealing the content pane with the article. Use the back arrow in the top left to get back to the content menu.
I also like how the trend of responsive/mobile-first design focuses developers and designers on content and performance over chrome and whizzbang, reducing information and sensory overload. Microsoft's Metro design language being one of the most developed expressions of those goals.
I'm really looking forward to the usual HN pessimistic discussion on why this is bad/wrong/could be done better. I know a lot of people don't like the negativity, but I really enjoy it because I get pumped up about stuff like this. WSJ is pretty reputable too.
MIT licesnse for everything
Copyright (c) 2012 The Wall Street Journal,
> Where should your advertising code get placed when you're on a desktop? Does the page require an alternate slideshow widget on touch enabled devices?
These are adaptive content concerns (the type of content served is adapted to fit the client, generally through progressive enhancement), rather than a responsive concerns (the content served is presented according to the client's metrics and capabilities). Completely valid use case here, IMO. Pitching it as an adaptive content library would be much nicer, because there actually is a need for good tools to do that well, whereas responsive content is basically fully handled by media queries and a tiny sprinkling of non-presentational Modernizr.
However I really have to challenge the idea that separating content and presentation concerns is a worthwhile endeavor.
The idea of CSS selectors was introduced to reduce the coupling of style and markup in the name of "separation of concerns" and is arguably the least-maintainable technology we have to deal with on the Web today. It increases complexity because markup and presentation will always be tightly coupled and hey, they're pretty cohesive too, and CSS gives us a big global namespace and thrown-together specificity semantics that aren't backed by any underlying theory.
Now that we have ARIA the accessibility excuse for separating presentation from content loses much of its weight.
And really, how many times have you completely reskinned a site with just CSS? You can't even change the order of inline items.
BTW, I'm not a CSS hater per se -- I really like media queries, how it describes text, and many of its layout options -- but the idea of using selectors to decouple it from the DOM has resulted in far more problems than solutions.
Counter-point: content and presentation are not always separate. Particularly in news (this comes from the Wall Street Journal) immersive articles like Snow Fall (http://www.nytimes.com/projects/2012/snow-fall/) are very popular. We need to cover those cases, too.
A few notes:
This solution will, in most cases, be part of a broader "responsive" strategy. Would all content from larger contexts get delivered to a mobile device? Shouldn't! But that's not this library's responsibility.
The library is an abstraction of responsiveness, for lack of better term. intention.js creates a framework for describing thresholds (mobile-phone) on an axis (width) and how they change. The thresholds and axes described here and in the documentation are not part of intention.js, they're an implementation of common responsive concerns.
The separation between presentation and content is entirely up to the developer or designer implementing the library. For example, you may decide to implement the application of grid specific classes on width-context change (presentation). But maybe you only care about swapping high res images out for the smaller ones on high speed connections or devices that have high res displays (content). Or a combination of both presentation and content: you would like to place a section of the page somewhere else in the evening, a portal to long form articles. you get the idea...
Going forward I'm looking into creating generators for implementations of intention.js for common responsive concerns (variety of widths, touch, etc.). Removing the dependencies on jquery and underscore. More documentation! And etc.
I've always thought the real promise of responsive design is "mobile first", delivering a basic document that works on its own, then enhancing layout/resolution for larger viewports and browser capabilities using CSS. This approach basically does the opposite.
With that said, if you disable JS on the author's page it still renders content fine.
<div id="all" class="standard" intent in-width: in-container: in-orientation:>
<section id="smallCode" class="clearFix standard" intent in-width: in-container: data-pattern="2">
<div id="pseudosmalltablet" intent in-pseudosmalltablet-class="toggleOrientation" in-base-class="null"></div>
I think a hybrid approach would be too tedious for someone developing a website to do, in order to get the payoff of sending less to mobile browsers, but it may be worth implementing in a framework.
2) A user agent doesn't encode any information about the actual metrics of the device.
Doing layout by user agent is basically a worst-case hellhole of browser-specific codebase fragmentation. There's a very good reason why best practices have been trending away from "test for vendor class" and towards "test for agent capabilities".
What is "desktop"? An MS Surface Pro would report as a desktop browser, but it's a touch interface. You can also resize the browser window- what then?
So some client-side responsive design would still need to be used.
Which is the point. The server can't know conclusively so why make it try?
Nice emulator: http://codewithsnow.com/emulator/
Github for example serves different markup to mobile, while simultaneously implementing responsive design on client side.
Responsive design is great until you force my phone to download 0.25mb of HTML it will never render. So what I'm suggesting is two layouts, both responsive.. one for desktops, other layout (also responsive) is for mobile devices.
Many 'intentions' respond to live events, so sometimes it makes sense to give all the markup up front. Take a look at some of the goofier examples, like animation (http://intentionjs.com/2013/03/12/walking-man.html).
But I kinda of agree, if you are browsing at 400px's you shouldn't be getting stuff for 1024px's. And vice versa.
I like the concept of what they're doing, but if their site is using it, then I'm not interested.
If I'm on a desktop browser and my window size is the same width as a tablet, then rearrange things to fit in tablet size rather than keeping at the desktop size and forcing me to scroll left/right. The demos work nice when you change devices but when you adjust your desktop window you get the same site whether you're 800px wide or 1920px wide.
I'm at a point where if I see a responsive library, it really has to be a big leap over what's currently out there. Not sure this is a huge leap from existing options.
Also is there a more in depth documentation on this or are you on the dev team?