You can make complex web apps responsive(adioso.com)
adioso.com
You can make complex web apps responsive
http://adioso.com/blog/2013/06/responsifying-adioso/
13 comments
Is this foundation-mobile plugin on GitHub?
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
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'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
nice, followed you, I hope I don't miss it. will it be released on zurb plugins page or only independently?
Awesome, thanks! We already have a Github repo up (see my other comment), we just haven't pushed a lot to it just yet. We're building it as part of a couple other projects, so we're pulling our code over as we implement it. So far, it's a joint project between us (alfajango.com) and our friends over karmacrm.com.
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).
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).
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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!
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!
[deleted]
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.
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.
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.
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.
So I just tried out adioso on a desktop. It wasn't as responsive as I hoped.
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.
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.
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.
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 ... :)
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 ... :)
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://web24.checkfelix.com/flugsuche/de/fluege.html?what=re...
Maybe it's not so good yet for european flights?
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?
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.
It's about making a webapp UI work well across different viewport dimensions using Zurb Foundation.
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.
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.
> 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.
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.
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...
...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).
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).
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.
Nice writeup explaining an overview of Foundation, Modernizer, etc..
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.
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.
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.
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.
to be fair, the whole of their site seems responsive, not just the landing page.
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.
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.
OTOH, I believe something like Gmail is far more complex in terms of webapps than something with a thousand boring forms.
He meant a rich app with complex interactions, as distinct from a basic text content site.
All the examples were "basic" not "complex" at all. I assume the author's never seen an enterprise app before.
if you define complexity by the amount of admin pages, then it is not complex. You can have a basic crud app with 100 pages of CRUD forms, does it make the app "complex" ?
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.
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.
It doesn't make it complex in the sense of logical complexity, or back end infrastructure complexity, but it does make it complex in terms of user interface layout. Hundreds of pages with thousands of fields.
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.
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.