Live data from Hacker News

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

intentionjs.com

41–50 of 55 posts

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

#41
post #38

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

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

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

#42
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.

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

#43
post #9
post #8

Earlier quoted context omitted.

Why can't this adaptation happen on the server? Client tells server what the resolution possibilities are ("the current browser size is X by Y, and my screen size (and thus maximum browser size) is W by Z), and server gives back only styles relevant to that size. On mobile devices where the browser is always fullscreen, that means a maximum of two layouts (horizontal, vertical).

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.

I didn't mean to imply that this is possible with technology we have at the moment. A piece of JavaScript code (framework, perhaps) could surely send the needed data, and for those with JS disabled, the page could fail over to using media queries (to be exact, it would need to load the media query version the first time your site is loaded, but could immediately redirect to the lighter JS version if you have JS enabled and the light/JS version would be loaded for future requests).

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

#44
post #40

I thought we all learned to stop creating arbitrary HTML attributes years 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/

I'm not exactly fond of web components or the shadow DOM either. They wreak of XUL/XML.

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

#45
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!

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

#46
post #13

Earlier quoted context omitted.

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.

1) User agents lie. Frequently. 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".

Well a sufficiently complex framework could deal with it, by making another trip to the server if it discovers the code being sent down the first time isn't good enough.

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

#47
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.

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

#48

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…

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.

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

#49

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…

Fwiw, I think Quartz nailed it. Simple, clear, and easy to use at every screen size. At smartphone size, the content menu and content pane shift from side-by-side to Z-index stacked or off-canvas.

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.

http://qz.com/

http://foundation.zurb.com/off-canvas.php

Post reply on HN