It also seems to load pretty quickly over 3G - so they've been economical with the resources tool. My biggest concern would have been that they went overboard with Javascript libraries to make the page map equally well on the mobile as it does on the desktop - only to forget that mobile bandwidth is generally shite. But that doesn't seem to be an issue here.
All in all, they've done an impressive job.
I think we both can agree that something like Gmail is much more complex than what was presented in the article.
Google Maps has 1 screen ,but all the infrastructure required to make it work is complex, and the code required to display maps is too. That's what a complex app is. Not an app with 100 screens of CRUD, reporting or whatever.
When building these kind of enterprise CRUD apps there will usually be a lot of commonalities between pages, but also there will be tons of little edge cases that only apply to a couple pages and usually need to be addressed individually. You could certainly argue that better design might eliminate those edge cases, but the reality is that designers/developers working on enterprise apps aren't usually given the opportunity to do the extra work to really work out all the kinks.
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.
It's here though: 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
It'll be released independently, but we've been talking to the Zurb people (they're pretty cool), and they said they'll link to it from the Foundation homepage and will help us implement or change things in Foundation if we need to (and if it's a good idea of course).
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.
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.
For example, in Adioso's implementation:
http://adioso.com/us/new-york-new-york-to-rome-it-next-month...
...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).
I like what you did with your responsive tables. They look good.
Also, is this really a "complex" web app. Doesn't really seem like there's a ton of fields to fill out or data to present. I was hoping someone was finally doing a writup on a data-dense app with many/complex fields of data entry with some best practices (this is the article I'm waiting for, though you have a good start).
BTW, I'm a fan of Foundation, so I was excited to see how others are using it.
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.
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.
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.
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 ... :)
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.
http://adioso.com/at/vienna-at-to-ams-june-21-return-june-25 http://web24.checkfelix.com/flugsuche/de/fluege.html?what=re...
Maybe it's not so good yet for european flights?
It's about making a webapp UI work well across different viewport dimensions using Zurb Foundation.
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):
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.
