
A different way of looking at responsive design: Intention.js - joe8756438
http://intentionjs.com/
======
unclebucknasty
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
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.

~~~
unclebucknasty
Good points.

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.

------
samsnelling
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
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.

~~~
untog
_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
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.

------
joe8756438
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.

------
akdetrick
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
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.

------
adamlj
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">

------
joshribakoff
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
So you'd have to refresh the page when you change phone orientation from
portrait to landscape?

~~~
joshribakoff
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.

~~~
jmhnilbog
While the demo site doesn't go this far, it would be possible to send minimal
code to the client with basic client-sniffing 'intentions', then use that
information to trigger some wacky ajax or redirect with more targeted markup.

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](http://intentionjs.com/2013/03/12/walking-man.html)).

------
j_k_s
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
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
Nokia Lumia 920

------
sdm
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
This threw me off as well. Hopefully they'll fix it quickly, I think it's a
great project otherwise.

------
vicky6k6
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
wow! they have a nice multi device emulator
[http://codewithsnow.com/emulator/](http://codewithsnow.com/emulator/)

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

------
at-fates-hands
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.

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

~~~
joe8756438
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
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
Yes, intent.remove works as well.

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

~~~
aroman
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
I'm not exactly fond of web components or the shadow DOM either. They wreak of
XUL/XML.

