9 ms·

A different way of looking at responsive design: Intention.js

134 points by joe8756438 13y ago

samsnelling 13y ago
I think this is absolutely incredible. This is exactly how I've always envisioned responsive design. 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, http://wsj.com/ http://wsj.com/
- cheald 13y ago
  My biggest complaints with it are that this mixes up content and presentation concerns again and we already have great tools for declarative responsive design. After however many years of working to get people to separate their content from their presentation, tools like this rush back in and encourage people to again start smashing them together. Being a Javascript tool, it also means that if a client doesn't run your JS for whatever reason, your entire site becomes rather unusable (you'll notice a lack of default/fallback classes and whatnot in the examples provided). > 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.
  - jmhnilbog 13y ago
    The lib is very, very flexible, so you could code a responsive site that worked via non-JS methods, then use it solely for progressive enhancement. It's basically a way to set arbitrary content rules within the content (A relates to B in a certain way when this is true, and in a different way when that is true) and define the interactions, reasonings, and timing in the script.
    - cheald 13y ago
      Completely agreed, and I like it a lot for that use case. I'm just not wild about it basically being pitched as a married-to-the-markup alternative to CSS.
  - untog 13y ago
    After however many years of working to get people to separate their content from their presentation 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/ http://www.nytimes.com/projects/2012/snow-fall/) are very popular. We need to cover those cases, too.
    - cheald 13y ago
      Acknowledged and agreed. I work in news, and believe me, Snow Fall comes up frequently. But, it's worth noting that while the presentation is a major part of the experience there, it's also an extremely mobile-unfriendly experience. It's a beautiful, gorgeous presentation that makes some very specific assumptions about the classes of devices it's going to render on - entirely the opposite intent of something like this library.
  - peterhunt 13y ago
    I'm concerned less about clients not running JS (well, Googlebot, but solvable) but more about the first-load page experience being weird. I wonder how they've solved this. 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.
joshribakoff 13y ago
Ok, but its still client side which I don't like. You're making the mobile device download all this markup, and then utilize further CPU cycles to discard that markup. It should run server side.
- orph 13y ago
  So you'd have to refresh the page when you change phone orientation from portrait to landscape?
  - webdevsometimes 13y ago
    The server could just give the requesting device what it needs to display the content in both orientations. That doesn't necessitate also giving it the layout for 10 other possible screen sizes.
    - Tobani 13y ago
      While most mobile devices have exactly 2 size, that may not be a good assumption. There are some devices that support split-screen and you would end up with more that just 2 sizes. You could send a list of all possible sizes, but If the split-screen is customizable it maybe not be feasible to enumerate all of them.
  - jmhnilbog 13y ago
    You user can define the 'measurer' function, and what triggers a measure. I think the defaults check for the onorientationchange event, with a polling fallback.
  - joshribakoff 13y ago
    Unintentional straw-man argument. If the device adapts from 400px width to 300px, then there's no need to send me the markup that's applicable to 600px. 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.
j_k_s 13y ago
That's interesting, but I'd expect their website to actually use their own product appropriately when viewing from my mobile devices. The "examples" page works, but isn't really in a well designed format - font headings are too large, text is pushed all the way to the far left without a single pixel margin causing it to look like the page should scroll horizontally, etc... I like the concept of what they're doing, but if their site is using it, then I'm not interested.
- jmhnilbog 13y ago
  What device is looking wonky? It's much more likely the CSS just needs a fix. It sounds like the library itself is working correctly.
  - j_k_s 13y ago
    Nokia Lumia 920
adamlj 13y ago
I had a look at the source and I must say I really prefer how Bootstrap does it. Compare: <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> etc. to <div class="col-md-6"> <div class="col-xs-6"> <div class="hide-xs">
cheapsteak 13y ago
How would this work with dynamically injected HTML (e.g. client side templates)?
- deleted 13y ago
  [deleted]
- joe8756438 13y ago
  there's a method intent.add you pass your node to and it will perform all manipulations on it and keep it registered for any future changes.
  - cheapsteak 13y ago
    Cool, thanks. I assume there's an intent.remove as well? Also is there a more in depth documentation on this or are you on the dev team?
    - joe8756438 13y ago
      Yes, intent.remove works as well.
aviswanathan 13y ago
Interesting demo site design as well. Not sure if I love it, but the speckled header was definitely memorable.
akdetrick 13y ago
While very well executed, the basic idea of delivering a document that doesn't make sense without javascript just seems wrong to me. 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.
- bstar77 13y ago
  I'm not sure what mobile first has to do with javascript dependencies. The reality is that all modern browsers (and web sites in general) expect a working, modern javascript engine. With that said, if you disable JS on the author's page it still renders content fine.
- lukifer 13y ago
  My rule of thumb is simple: web apps can require JS, but web sites never should.
rubiquity 13y ago
I thought we all learned to stop creating arbitrary HTML attributes years ago?
- aroman 13y ago
  I don't think anything could be further from the truth. If anything, I think HTML is very much embracing this direction with web components and their underlying technology, ShadowDOM[1]. [1] http://www.w3.org/TR/shadow-dom/ http://www.w3.org/TR/shadow-dom/
  - rubiquity 13y ago
    I'm not exactly fond of web components or the shadow DOM either. They wreak of XUL/XML.
sdm 13y ago
Very interesting. The main issue I see is it assume all desktops to be equal. Responsive design is about supporting a range of viewport dimensions and not about about a range of devices. 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.
- connerbryan 13y ago
  This threw me off as well. Hopefully they'll fix it quickly, I think it's a great project otherwise.
at-fates-hands 13y ago
How does this library do anything better than Bootstrap, Foundation or any of the hundreds or so frameworks/libraries already out there?? 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.
unclebucknasty 13y ago
Reading the comments, I guess I am the only guy who still doesn't believe in responsive design in the first place. 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!
- hawkharris 13y ago
  I appreciate your concerns about responsive design, namely the logistical and performance-related issues of creating a separate user experience for mobile devices. 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.
joe8756438 13y ago
Author here. Thanks for all of the comments it's been fun watching the dialog unfold! 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.
vicky6k6 13y ago
Folks check this out a clear alternative to responsive design and intention.js ( 100% server side .. easy to follow) http://www.codewithsnow.com/portal/snow/gettingstarted http://www.codewithsnow.com/portal/snow/gettingstarted I am downloading the tomcat version now ….
- vicky6k6 13y ago
  wow! they have a nice multi device emulator http://codewithsnow.com/emulator/ http://codewithsnow.com/emulator/

134 points by joe8756438 13y ago

I think this is absolutely incredible. This is exactly how I've always envisioned responsive design. 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, http://wsj.com/ http://wsj.com/

cheald 13y ago
My biggest complaints with it are that this mixes up content and presentation concerns again and we already have great tools for declarative responsive design. After however many years of working to get people to separate their content from their presentation, tools like this rush back in and encourage people to again start smashing them together. Being a Javascript tool, it also means that if a client doesn't run your JS for whatever reason, your entire site becomes rather unusable (you'll notice a lack of default/fallback classes and whatnot in the examples provided). > 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.
- jmhnilbog 13y ago
  The lib is very, very flexible, so you could code a responsive site that worked via non-JS methods, then use it solely for progressive enhancement. It's basically a way to set arbitrary content rules within the content (A relates to B in a certain way when this is true, and in a different way when that is true) and define the interactions, reasonings, and timing in the script.
  - cheald 13y ago
    Completely agreed, and I like it a lot for that use case. I'm just not wild about it basically being pitched as a married-to-the-markup alternative to CSS.
- untog 13y ago
  After however many years of working to get people to separate their content from their presentation 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/ http://www.nytimes.com/projects/2012/snow-fall/) are very popular. We need to cover those cases, too.
  - cheald 13y ago
    Acknowledged and agreed. I work in news, and believe me, Snow Fall comes up frequently. But, it's worth noting that while the presentation is a major part of the experience there, it's also an extremely mobile-unfriendly experience. It's a beautiful, gorgeous presentation that makes some very specific assumptions about the classes of devices it's going to render on - entirely the opposite intent of something like this library.
- peterhunt 13y ago
  I'm concerned less about clients not running JS (well, Googlebot, but solvable) but more about the first-load page experience being weird. I wonder how they've solved this. 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.

joshribakoff 13y ago

Ok, but its still client side which I don't like. You're making the mobile device download all this markup, and then utilize further CPU cycles to discard that markup. It should run server side.

orph 13y ago
So you'd have to refresh the page when you change phone orientation from portrait to landscape?
- webdevsometimes 13y ago
  The server could just give the requesting device what it needs to display the content in both orientations. That doesn't necessitate also giving it the layout for 10 other possible screen sizes.
  - Tobani 13y ago
    While most mobile devices have exactly 2 size, that may not be a good assumption. There are some devices that support split-screen and you would end up with more that just 2 sizes. You could send a list of all possible sizes, but If the split-screen is customizable it maybe not be feasible to enumerate all of them.
- jmhnilbog 13y ago
  You user can define the 'measurer' function, and what triggers a measure. I think the defaults check for the onorientationchange event, with a polling fallback.
- joshribakoff 13y ago
  Unintentional straw-man argument. If the device adapts from 400px width to 300px, then there's no need to send me the markup that's applicable to 600px. 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.

j_k_s 13y ago

That's interesting, but I'd expect their website to actually use their own product appropriately when viewing from my mobile devices. The "examples" page works, but isn't really in a well designed format - font headings are too large, text is pushed all the way to the far left without a single pixel margin causing it to look like the page should scroll horizontally, etc... I like the concept of what they're doing, but if their site is using it, then I'm not interested.

jmhnilbog 13y ago
What device is looking wonky? It's much more likely the CSS just needs a fix. It sounds like the library itself is working correctly.
- j_k_s 13y ago
  Nokia Lumia 920

adamlj 13y ago

I had a look at the source and I must say I really prefer how Bootstrap does it. Compare: <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> etc. to <div class="col-md-6"> <div class="col-xs-6"> <div class="hide-xs">

cheapsteak 13y ago

How would this work with dynamically injected HTML (e.g. client side templates)?

deleted 13y ago
[deleted]
joe8756438 13y ago
there's a method intent.add you pass your node to and it will perform all manipulations on it and keep it registered for any future changes.
- cheapsteak 13y ago
  Cool, thanks. I assume there's an intent.remove as well? Also is there a more in depth documentation on this or are you on the dev team?
  - joe8756438 13y ago
    Yes, intent.remove works as well.

aviswanathan 13y ago

Interesting demo site design as well. Not sure if I love it, but the speckled header was definitely memorable.

akdetrick 13y ago

While very well executed, the basic idea of delivering a document that doesn't make sense without javascript just seems wrong to me. 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.

bstar77 13y ago
I'm not sure what mobile first has to do with javascript dependencies. The reality is that all modern browsers (and web sites in general) expect a working, modern javascript engine. With that said, if you disable JS on the author's page it still renders content fine.
lukifer 13y ago
My rule of thumb is simple: web apps can require JS, but web sites never should.

rubiquity 13y ago

I thought we all learned to stop creating arbitrary HTML attributes years ago?

aroman 13y ago
I don't think anything could be further from the truth. If anything, I think HTML is very much embracing this direction with web components and their underlying technology, ShadowDOM[1]. [1] http://www.w3.org/TR/shadow-dom/ http://www.w3.org/TR/shadow-dom/
- rubiquity 13y ago
  I'm not exactly fond of web components or the shadow DOM either. They wreak of XUL/XML.

sdm 13y ago

Very interesting. The main issue I see is it assume all desktops to be equal. Responsive design is about supporting a range of viewport dimensions and not about about a range of devices. 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.

connerbryan 13y ago
This threw me off as well. Hopefully they'll fix it quickly, I think it's a great project otherwise.

at-fates-hands 13y ago

How does this library do anything better than Bootstrap, Foundation or any of the hundreds or so frameworks/libraries already out there?? 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.

unclebucknasty 13y ago

Reading the comments, I guess I am the only guy who still doesn't believe in responsive design in the first place. 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!

hawkharris 13y ago
I appreciate your concerns about responsive design, namely the logistical and performance-related issues of creating a separate user experience for mobile devices. 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.

joe8756438 13y ago

Author here. Thanks for all of the comments it's been fun watching the dialog unfold! 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.

vicky6k6 13y ago

Folks check this out a clear alternative to responsive design and intention.js ( 100% server side .. easy to follow) http://www.codewithsnow.com/portal/snow/gettingstarted http://www.codewithsnow.com/portal/snow/gettingstarted I am downloading the tomcat version now ….

vicky6k6 13y ago
wow! they have a nice multi device emulator http://codewithsnow.com/emulator/ http://codewithsnow.com/emulator/