
You can make complex web apps responsive - wernah
http://adioso.com/blog/2013/06/responsifying-adioso/
======
JangoSteve
This is a good writeup. We've started doing the same thing for the startups
we've been building, and funny enough, in almost the exact same way, using
Zurb Foundation and everything.

We found that, as awesome as Zurb is, it doesn't go quite all the way with its
mobile components. It's missing things like full-width padded lists (for fat
fingers), and a few other touches. Which is why we just started building
foundation-mobile as a plugin for Foundation to add the extra mobile-only
interface elements. We have Zurb's support, but we only just started it a
couple weeks ago. We're planning an initial release here in the next couple
weeks.

~~~
cheeaun
Is this foundation-mobile plugin on GitHub?

~~~
JangoSteve
Ah yes, sorry, I didn't post the link because we literally just started it, so
there's not much to see yet (all we have so far is the mobile lists).

It's here though: [https://github.com/alfajango/foundation-
mobile](https://github.com/alfajango/foundation-mobile)

If anyone has ideas for components we should include (or if you want to
contribute), please post on the issues! For example, you can see my own post
for our upcoming full-window, modal drop-downs:
[https://github.com/alfajango/foundation-
mobile/issues/1](https://github.com/alfajango/foundation-mobile/issues/1)

------
mberning
I'm not sure I would classify this as a 'complex' webapp. Not to downplay the
work that has gone on here, which is great, but when I think of a complex web
app I think of one that has dozens or hundreds of screens, dozens or hundreds
of dialogs, extensive use of user roles/permissions, etc.

~~~
Shorel
OTOH, I believe something like Gmail is far more complex in terms of webapps
than something with a thousand boring forms.

~~~
mberning
It depends on what those forms do.

I think we both can agree that something like Gmail is much more complex than
what was presented in the article.

~~~
tomhoward
_More_ complex, sure, but the real point is that they're both significantly
more complex than a basic text content site.

------
rickdale
Just used adioso for the first time. Then I read the post.

From my perspective, it looks cool and all, but the dates load extremely slow
and you have to click the right arrow to pick your dates, rather than pop-up
calendar, which they also use on a different part of the site and works out
better.. Also, I wanted to fly to Vegas, it picked out my local airport and an
8 hour 1 stop trip to Vegas. By selecting an airport just 45 minutes farther
from me, there are 4 hour flights to Vegas. But it didn't suggest those
flights for me, it just took my location by default (from IP) and then shot
out the 8 hour flights.

I don't know, I dont like the design. Too much fluff, not enough ease.

~~~
wahnfrieden
I too had a terrible experience. For a minute after I first searched, it gave
results that were all twice as expensive as Kayak ($1100 instead of $5-600).
There was no indication that it was loading more. I would have bailed at this
point, but I returned to the tab (out of curiosity of their design) and saw it
updated with reasonable flights.

------
danso
Thank you for the comprehensive writeup...even if it can be _done_ , there is
still a good amount of skill and knowledge required to pull it off...too
often, non-designers underestimate the work and design considerations
involved.

That said, I wonder if you are going _too far_ in being responsive? The
1000px+ size, IMO, takes the concept of whitespace too far. For example, the
third most important datapoint -- the arrival date, is located as far as
possible from the two critical datapoints (price and departure date)...in the
narrower versions of the site, the listings are, IMO, significantly easier to
scan. I wonder if you (or rather, your users) wouldn't benefit from keeping
the listings no wider than they are in iPad portrait?

The other choice, of course, is to just move Arrival Date to the left side,
but that's a consideration not related to the responsive design.

~~~
k3n
> too often, non-designers underestimate the work and design considerations
> involved.

The story of my life! In my entire career as a web developer, the hardest non-
technical task I've ever faced is convincing management that we need a
designer. I guess they think all they do is come up with some colors or
something, because there is never any value given to having someone on-hand
that actually knows what they're doing. So frustrating.

~~~
danso
Not just design work though, but also _content_ and features work, which pulls
in product development and sometimes, infrastructure people. Responsive/mobile
design _necessarily_ makes content disappear or moved around, which can
substantially change the function of the site.

For example, in Adioso's implementation:

[http://adioso.com/us/new-york-new-york-to-rome-it-next-
month...](http://adioso.com/us/new-york-new-york-to-rome-it-next-month-
for-7-to-10-days)

...resizing to the mobile width hides the "Lock Flight" buttons that are
normally placed in the far right. So someone had to agree/argue that hiding
those buttons was a worthwhile compromise (as opposed to stacking them on the
bottom).

~~~
k3n
Fully agree. At least 'graphic design' is easier to explain than 'information
design', which most here at work probably think is a farce or a figment of
imagination.

------
iamtyce
Great post, Dan - really well written.

Personally I'm still conflicted about using so many different classes for
different breakpoints, but I'm finding that the whole "No grid for < tablet
portrait" isn't always the best solution.

Quick heads up, the responsive mixin is missing a bracket:

@include respond-to(small-mode) {

For anyone out there using Rock Hammer, here's that mixin converted to work
with Malarkey's breakpoint controls (also with my own custom breakpoint sizing
comments, feel free to remove):

[https://gist.github.com/iamtyce/5778876](https://gist.github.com/iamtyce/5778876)

------
themstheones
Wordpress's admin panel is totally responsive. It's quite well done and
impressive. It's lovely to be able to fire it up on my phone and delete spam
comments without pinching and zooming in on controls.

------
EGreg
What's with all these CSS frameworks which serve one css file for everybody?
Toolkits like GWT have had the sense to serve only what each environment
needs, since 2004. If you are worried about mobile devices being able to
handle things, how about NOT downloading things that they don't need?

Your CSS framework should include a precompiler that generates files for each
platform. Then either the client or the server can decide the right file(s) to
load.

~~~
cheald
Letting the server pick means you're serving the user agent, rather than the
device capabilities. Letting the client pick means perceptual performance
degradation, as the client has to synchronously download and run Javascript
before it can figure out what to request from the server (that is, the
render/layout thread can't be chewing on the CSS while your Javascript is
doing its thing). Given how well text compresses and the cost of a HTTP
connection, I'm not sure that separating things out is going to get you much
of a win.

The comparison to GWT is hilarious, since GWT is a massive mess of dependency
hell that ends up requiring an insane amount of support code for any
particular small feature.

~~~
modarts
The GWT thing threw me off as well. How maintaining a separate stylesheet per
user agent could possibly be seen as an optimal approach is beyond me.

~~~
EGreg
If you have an iPhone, would you rather have a stylesheet that has everything
and the kitchen sink in it (for tablets and desktop environments, all the
-firefox- stuff and IE hacks) or would you rather have a stylesheet just for
the iPhone?

Similarly, would you serve the full jQuery to an iPhone or would you serve the
new jQuery without IE dependency which is much lighter? Heck, you might even
be able to serve Zepto!

~~~
cheald
jQuery 1.10.1 gzipped is 32kb. jQuery 2.0.0 gzipped is 29kb. Quantify "much
lighter" for me?

~~~
EGreg
So why did they do it?

------
dminor
This post illustrates that building a responsive website, while cheaper than
building apps and easier than maintaining a separate mobile website, still
involves quite a bit more work than a desktop-only site.

We're just about finished with a responsive redesign, although one of the
owners doesn't understand why we're "shrinking the website" instead of
building an app for her phone.

------
bjhoops1
Can this approach (especially the nesting of grids in the table example) be
taken with bootstrap as well? Wondering if anyone has any links to a similar
post showing how to leverage bootstrap in a similar fashion.

------
wc-
Anyone have any idea if their landing page is some kind of template? I have
seen it used before and would love to play around with it if it is available
somewhere.

------
macowar
So I just tried out adioso on a desktop. It wasn't as responsive as I hoped.

------
monsterix
Long answer short: No, you can't get a complex webapp resolved responsively
with all its complexity on a mobile.

Two reasons for that:

1\. The mobile browser (excluding the iPad/larger tablets) are yet to achieve
the level or even meet standards, for that matter, where a really good
developer could go an dive and into creating a complex webapp.

2\. Even if point no. 1 is met by vendors (which is questionable) then also
there is a significant difference between the way people interact by sitting
on their desktops and on their mobiles when on the go.

That said, nice piece of work.

BTW we do a lot of this type of work too - i.e. trying to achieve a fairly
complex webapp for all screens. We don't use Zurb or Bootstrap, rather have
our own custom CSS framework built from ground up. I'm hoping for better
support from the vendors soon given there is more competition. It surely will
get better.

~~~
laumars
You're going to have to explain point 1 a little better because it reads like
you're saying that mobile browsers don't have feature rich and standards
compliant engines. And that mobile browsers differ from tablet browsers.
Neither of which is true.

~~~
monsterix
Top off my head (though people have already negatively voted my opinion) here
are a few:

1\. File uploads on iOS is not supported as per standards. Android is making a
difference here.

2\. HTML5 Full-Screen API is not supported on mobile browsers. On the iPad,
Safari doesn't switch to full-screen mode at all, whereas on the iPhone it
does.

3\. Available memory is very very limited. About 5mb or so. So you can't load
too many images on the same page or it'd crash. Not even a complex webapp to
be frank.

4\. Number of ports per connection on mobile browser are fewer than on a
desktop browser. So a complicated/heavy webapp isn't going to make a cut.

There are other serious limitations too.

Like you can't tell the browser to remain in landscape or portrait via your
site if you wanted to. CSS properties like position:fixed or z-index and
binding of events on the layer with highest z-index is buggy or simply doesn't
work.

Other options like raw in-line base64 images inside CSS are not rendered
properly etc. etc. etc. The list could go on ... :)

~~~
laumars
Ah, I understand your frustration now. Thanks for the clarification.

------
Trufa
Cool desgin and interesting post, but it's really not worth much if it doesn't
find the cheapest flights.

[http://adioso.com/at/vienna-at-to-ams-june-21-return-
june-25](http://adioso.com/at/vienna-at-to-ams-june-21-return-june-25)
[http://web24.checkfelix.com/flugsuche/de/fluege.html?what=re...](http://web24.checkfelix.com/flugsuche/de/fluege.html?what=results&params=VIE-
AMS-20130621-0|AMS-VIE-20130625-0|1-e)

Maybe it's not so good yet for european flights?

~~~
markdown
That's way OT. The article has absolutely zero to do with flight pricing, or
the content of the website.

It's about making a webapp UI work well across different viewport dimensions
using Zurb Foundation.

