I've just been reading through Parker, et al, Designing with Progressive Enhancement, and I'm wondering if anyone else has considered if a similar approach might be implemented in Drupal (D7 in particular)?
If you haven't read it, the developers at Filament Group developed a compact suite of JS browser tests (EnhanceJS) that then set or unset a session cookie and allow a server-side script to do things like include CSS and JS and markup (body classes, etc.) that are appropriate to the browser's capabilities.
I'm not a hard-core coder, so I'm not sure how the approach might work in Drupal, but I'm pretty sure it would be a valuable addition. Specifically, I wonder if it's in the realm of possibility to use this method to set a Context (based on browser capabilities, rather than device detection), which could then be used to do things like switch themes, toggle block visibility, toggle layouts (a la Omega/Delta), and so on. For the Omega Framework gang: if it were possible, this might be a way to piggyback on the new responsive layouts in the 3.x branch.
Thoughts?
Comments
WOW. I like this concept.
WOW. I like this concept.
Its a cool idea but not a
Its a cool idea but not a "valid" approach for true Responsive Design. This goes into a completly different direction (one that I dont like at all) than what Omega currently does.
Just to clarify
Could you elaborate on why this is "not a 'valid' response for true Responsive Design"? I'm not arguing at all, but there are so many different (mostly unexplained) approaches to doing this, especially with Drupal, that others may just get to a post like this and be left scratching their heads. :)
And don't get me wrong - I'm loving Omega-land myself, and just sorting out how to add a device Context so as to be able to toggle blocks and image display styles (a.k.a. imagecache presets).
Cheers!
Toggling blocks / regions /
Toggling blocks / regions / flash content / image presets with this is something I wouldn't disagree with (there might be usecases for it) but this is not theme layer material (and therefore nothing Omega should do)... I prefer to change the visualization of content instead of completly removing it for mobile devices, to me this seems like a last resort and we should (in most cases, at least) try to not restrict access to certain page elements, instead change the display in an appropriate way so noone misses any content. This is just the general concept for which I stand and there ARE cases where you would want to restrict access on certain page elements based on the users device and therefore there IS a need for such a (Context) plugin. It can be done with WURFL + Context and it might be Delta material, but its nothing that we should mix up with what Omega does!
Responsive Design for me always means "Yes, we can fix it for your device"
Altering the content of a page based on the users device is more like "Restrictive Design", if you know what I mean! :)
Which layer may be arguable; but the notion isn't.
Two things will remain true for the timeframe we're talking about:
Therefore, the notion that a site owner may choose to only display to mobile devices a subset of all available page blocks on a given page is a valid notion (particularly if some blocks are image-heavy). Particularly if Drupal development follows the "one web" path, where there is no separate mobile site.
(edit update) So whether it's done in the theme later, or in the render engine, or wherever, this concept needs supported. I'm not a good person to suggest which layer.
Usablity research on content for mobile vs desktop
This may be helpful in the debate about a reductive approach to content in mobile device contexts: http://www.useit.com/alertbox/mobile-ux-guidelines.html and http://www.useit.com/alertbox/mobile-writing.html
There are two issues – unnecessary download times and excess content.
Users are far less patient on mobile devices and want to get what they are looking for as fast as possible. If the responsive approach is to retain the full detail of every feature and piece of content on the page, then maybe one way to deal with this is by hiding certain content but making accessible through navigation that is only then visible when that content is not.
I knocked something up for my wife's website as an example. : http://labs.deeson.net/mobile-exp/services.html
Viewed as a desktop you see the full set of treatments, and viewed on a mobile screen, jQuery mobile kicks in and makes each table a page, then reveals navigation to/from those pages.
jQuery mobile is currently way too heavy though – I would prefer to see all the styling functionality stripped out and only the page building / navigation functionality available. It could then be used in a much lighter way to enable this kind of approach.
Having said all that about
Having said all that about jQuery mobile, I just checked out 1.0 RC2 and it is now only 24kb from their CDN (gzipped) and has a CSS version without any base theme – just the structure. This makes it loads lighter and much more feasible for use imo.
I think it would be better if
I think it would be better if you could choose which regions moved under which in the stack, for example, if you had a layout like this:
desktop
[region 1] [region 2]
mobile
[region 1]
[region 2]
or this
[region 2]
[region 1]
all with the same theme.
To me this could be done by adding weights to the regions, so that it will be layering in the way you want as it responds.
I meant Zones for the above
I meant Zones for the above post.
Lazy loading
I chatted with DamienMckenna a while back about introducing Lazy Loading into the render layer of Drupal so that any object (e.g. a block, region or View), could be marked for lazy loading under a given condition. This condition might be that the screen width of the requesting device is less than 420px.
Lazy-loaded content would be loaded on the client side via AJAX when:
(1) the user requests the content by clicking a link or scrolling down the page. Otherwise, the content is not downloaded on initial page load; or
(2) downloaded by the client on initial page load if the lazy loading condition is not met.
This provides the end user with the complete page in all cases, but the option to download ancillary content (deemed by the content provider) under conditions when bandwidth or time should be conserved.
Lazy loading
Isn't this basically coming back to 'restrictive vs responsive' design as pointed out in fubhy's second post http://groups.drupal.org/node/145839#comment-493884
Surely lazy loading is a Context, Delta & WURFL solution that needs some extra ajax to load in blocks/ views on wide screens? I'm not sure stripping down site content qualifies as a responsive solution.
Case (1) would require 'media queried ajax loading' on large screens (breaking the site for no-js & browsers with no MQ support).
Case (2) Would require WURFL or agent detection on the server so that content can be formatted for device size.
Not necessarily restrictive
I think what Fubhy was mentioning is taking a fully functioning site and stripping features away for mobile users as being restrictive design. What lazy loading would do is along the lines of progressive enhancement. Adding features in blocks to the layout via AJAX isn't restricting the user's capability, just giving it what it needs without any of the extras that someone on a desktop or tablet can handle. We already hide portions of the site that aren't necessary for mobile users or disable features that are distracting (superfish menus for example) this just allows for a greater ability for that to occur.
As for your cases
1) any browser that doesn't support js (which aren't many) would just revert to a larger layout of the mobile content. They wouldn't be loading any of the extra content. Lazy loading won't be for all content, just traffic intense ones. So having js disabled just means the extras won't load. Same with non-MQ browsers (also rare).
2) Not necessarily. WURFL has some issues that have been outlined in other threads about licensing etc. so it's not the best way. The ability to model your content to the browser could possibly be achieved by lazy loading but we'll have to test that out.
The thought with Lazy Loading is being able to take down a slideshow that's bandwitdth intense for someone who won't render it well on their screen size or something along those lines. The holy-grail in responsive Drupal is still MQ aware images that are cached for performance etc.
Drupaler and Mobile Ninja
Cellar Door Media - Beautiful Mobile Solutions
The holy-grail in responsive
Yep I can agree with that :)
Maybe A Hybrid Lazy-Load?
Jesse I think your idea of doing lazy loaded content (ie blocks etc.) is one that will definitely drop down on bandwidth usage.
Are you saying, then, to tie in this lazy loading AJAX to the media queries that are going on within Omega? I think being able to say "Lazy load only if in Desktop" to a block or region would provide the ability to still build on a mobile first approach and after the initial 400px or so in height is loaded (which should be the most important data for a mobile user anyways) we would then just load the content based on the media-query and/or if they click a link or scroll.
Using lazy loading ajax that is media query aware is something I think would be a perfect hybrid of restricting data that isn't very necessary for mobile users to download but not being stuck with server-side awareness like wurfl etc. that carry their own pros/cons.
This should be mentioned in the mobile blueskying conversation that is ongoing too as it will will help Drupal stay lean on the server while still allowing the content to be aware of the user.
Drupaler and Mobile Ninja
Cellar Door Media - Beautiful Mobile Solutions
Discussions about the ajax loading of blocks in the past
Hi, i have been wondering about this for a while now while triying to sort out the best solution for responsive menus. there are a few discussions and solutions about the basic implementation of ajax loading
http://drupal.org/node/441312
http://groups.drupal.org/node/24825
even some modules:
http://drupal.org/project/ajaxblocks
http://drupal.org/project/ajaxify_regions
Could some of this be noted on these conversations? i would like to know about the performance details on this approach