31–40 of 42 posts
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.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
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…
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.
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.
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.
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 ca…
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.
Personally I'm still conflicted about using so many different classes for different breakpoints, but I'm finding that the whole "No grid for 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):
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 ca…
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…
Earlier quoted context omitted.
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…
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.
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!