Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

intentionjs.com

Post reply on HN
Print view View original

21–30 of 55 posts

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

#21

Post by jmhnilbog »

cheald wrote: post #7
samsnelling wrote: post #2

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 St…

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 yo…

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.

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

#22

Post by untog »

cheald wrote: post #7
samsnelling wrote: post #2

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 St…

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 yo…

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/) are very popular. We need to cover those cases, too.

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

#25

Post by cheald »

jmhnilbog wrote: post #21
cheald wrote: post #7

Earlier quoted context omitted.

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 yo…

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.

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.

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

#26

Post by untog »

benatkin wrote: post #11
cheald wrote: post #9

Earlier quoted context omitted.

Because clients don't send this information to the server (and if they did, its validity would be suspect), and because browser layout engines and CSS are already designed to be independent of specific device metrics. It's a solution to a problem that doesn't need solving.

It sends the User-Agent, which can be used to determine whether it's the desktop or not. It doesn't solve the portrait and landscape changing problem. So some client-side responsive design would still need to be used. 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.

It sends the User-Agent, which can be used to determine whether it's the desktop or not.

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?

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

#28

Post by jmhnilbog »

joshribakoff wrote: post #16
orph wrote: post #4

Earlier quoted context omitted.

So you'd have to refresh the page when you change phone orientation from portrait to landscape?

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…

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

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

#29

Post by cheapsteak »

joe8756438 wrote: post #27
cheapsteak wrote: post #20

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

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.

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?

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

#30

Post by cheald »

untog wrote: post #22
cheald wrote: post #7

Earlier quoted context omitted.

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 yo…

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/ ) are very popular. We need to cover those cases, too.

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.
Post reply on HN