First, let me start by saying that I simply can not stop praising the work that has been done on 3.x - this framework will in no doubt serve as a prime example of Drupal's ability to adapt to growing trends.

That being said, I think there are still some things that need to be considered. One of the largest issues I see is utilizing this framework in the real world when it comes to mobile platforms.

One feature I would love to see added to this is the ability to include/exclude js libraries depending on the active media query. Including is easy enough to do on our own of course - I just think that it would provide an even greater achievement for the omega framework if this was able to be done through the UI.

Let's look at an example, not getting too hung up on syntax here, one possible solution would be to use drupal_add_js to include libraries based on the screen width.

if (screen.width < 600) {
 <?php drupal_add_js(); ?>
}

or even js from js (which is 'meh at best).

function addJavascript(jsname,pos) {
var th = document.getElementsByTagName(pos)[0];
var s = document.createElement('script');
s.setAttribute('type','text/javascript');
s.setAttribute('src',jsname);
th.appendChild(s);
} 

addJavascript('newExternal2.js','head');

Excluding the js is another matter. Ideally we do not want to load javascript that is unneeded in a mobile environment. Moreover - we are more than likely going to want to deploy a special library like jQuery.Mobile, and with that inclusion - we will need to specify what libraries should not load when it is active. As well as providing conditions for templating.

Even though the markup structure doesn't really change that drastically - mobile sites using jquery mobile and most other mobile js frameworks utilize the data-role attribute to designate what type of element is being invoked and what relationship it has to its children and neighbors.

I think omega is on the right path for sure - but performance is a real concern in a real world use-case. Perhaps this is more suitable as a supplementary module than as a feature of the core, I am just interested to hear your opinions on the topic.

Thanks!

Comments

lagpro’s picture

lagpro commented

I believe that this cuts to the heart of the "mobile" problem...
Screen size is a main issue in regards to readability and usability but utilizing the device/platform libraries can make a good site great (and/or fast).

I would lean towards a module to do this since most library support is done that way. A good example of t his problem is with menus. If I have a lot of screen space, I can use a mega; less space a horizontal superfish; less space a vertical; less space... device buttons - screen command areas - gestures... etc. The superfish menu plugin attempts to do some of this but stops with mobile devices. So then you would have to use a mobile device menu module and create this kind of mess.
Large -> superfish - turn off mobile
Medium -> superfish - turn off mobile
small -> turn off superfish - turn on mobile and set device context
... oh, but wait, you have an iPad (or equiv)....
Medium -> check for device - turn off superfish - turn on mobile
or
Medium -> turn on superfish and turn on mobile (both)
and that's just menus.

The big question is how to make it easy to support so that it doesn't require changes in the theme and a handful of modules everytime you make a change to the content context.

DRIVE’s picture

DRIVE commented

Would like to weigh in myself as in all of Drupal, Omega is the best theme framework hands down. I have, like many others, invested humongous amounts of time keeping up with it and working towards developing some sub themes and related architectures for it.

Mobile web is a lot more than just the screen size. I know you guys know that so dont take me wrong. Most of my company's clientele are businesses and I dont think there is a GOOD effective way to serve mobile users without developing specifically for what type of device is connecting. My HUGE WIDE MONITOR (referring to most recent Vid on 7.3 lol) is soon getting replaced with an even larger one :D

I dont think you can have a one-size-fits all that can suit the sheer amount of space you can use (and I use every inch of my desktop and still need more space) and then do the "linear shuffle" with a monstrous string of blocks in a users phone that IS actually meant for much more space availability and have it easily shape-shift and be good on a dinky little screen.

If we dont go mobile we'll be run down quick but I for one think that mobile is specifically developed OFF a framework and not the framework trying to chamelionize itself into a phone. We develop a lot of apps with LARGE data and in that case the larger the screen the better. There are simply some tasks that cannot be done on a phone... without specifically having an "app" that serves smart content if a phone is connecting to it. Unless an entity is developing only for a phone, I think the horse has to be before the cart.

If content can look GREAT on my monstrous monitor and the exact same content can also look good on a phone "out of the box" it cant be very good.

Love Omega, have been committed to it but am waiting on moving to 7.3 until I learn more. At some point we have to get to a place where we arent completely changing the framework BIGTIME so often....

I read all your stuff and am paying close attention... THANK YOU for all that you have done... it is huge... so I am a big fan, just wanted to put my 2 cents in.... thanks again :)

himerus’s picture

himerus commented

I agree with everything here at this point.

This move to 3.x for Omega is a huge conceptual change (with little effect on the current 2.x line) I've updated a theme I've been working on in about 30 min to the 3.x version. That will require some documentation, but it IS possible.

Related to the responsive enhancements: It IS still nearly impossible to completely cover any use case for someone that will truly want to use Adaptive/Responsive concepts on a site. Most situations like that are one-offs and hard to consider for in a base theme.

However, I think we've nailed it to the best of our ability in the 3.x line... In a TRULY responsive layout, the issue is for mobile devices, sending the same data to the mobile users as the desktop users without enhancing the load times for mobile browsers. This is a problem in Drupal, and nothing that can be changed/fixed in Omega, or any other base theme that attempts to implement responsive enhancements. The only "real" way currently in Drupal is to still send the entire page data to all users, but use CSS3 media queries and maybe a bit of JS to enhance/change the visual presentation on the fly.

The BEST case for a truly responsive setup will be some of the work going into D8 that will essentially give context a much better position in page rendering, and allow us to truly serve different loads of data to different situations. But for now, we must deal with what we have.

I feel like what is implemented in Omega 3.x paves the way for not only other contributed themes/base themes to follow, but also a path for Drupal core to take in how pages can be visually rendered. The issue with the truly responsive model is this: We could determine things at runtime, and ONLY send the appropriate data (say the narrow 720px grid, or only the mobile layout) to the browser based on capabilities... but that doesn't help when using say a large tablet where in portrait mode, it would best handle the 720px layout, but in landscape viewing could handle the wider 960 grid. That alone is enough reason to send all the data, and allow the browser to determine on the fly what is appropriate. Even one argument is that users don't always have their browsers maximized, so scaling down the size of the window should/could also potentially render a different visual presentation (as shown in my screencast on the new setup).

@DRIVE - I completely agree with you on "At some point we have to get to a place where we arent completely changing the framework BIGTIME so often....". I get it... I really do... and let me assure you (everyone) that 3.x is going to be the last version of Omega for D7... I will not (fingers slightly crossed) stray from that. When I started working to get Omega to D7 a year ago, I took the quickest path to update the D6 version, and just make it work... thus we had 1.x... 2.x became an immediate project to start satisfying my own needs/desires in the process to update the theme to a system that provided much more flexibility via the UI and much less template editing. 2.x is a good piece of work, and while there ARE a few things that annoy me in the sites I've built with it so far, it does work well.

Thanks to Fubhy jumping on board full of passion and drive to help better the project, it was quickly determined that this all needed to become a new full release as many things on the backend DID need to change or be restructured to better suit the long term goal(s). Thus 3.x is born... I'm expecting an alpha release of 3.x Omega AND Delta this week/weekend, and we will be continuing down this path, including FINALLY getting around to the Omega UI which has now the ability to be MUCH more intuitive and flexible based on the simplistic methods in which all the layouts are generated now.

Back to the responsive grid. It might not be a perfect implementation, it might never be perfect, but with the introduction of the narrow/normal/wide grid setup, in which ANY subtheme can declare/override the grid sizes to suit the use case I think this methodology will leave most of the other base themes/grid themes and their maintainers scratching their head for some time to come on how to implement and better the system this is becoming. There is unlimited flexibility in this new system, and with some decent documentation, ANYONE can implement some pretty complex themes based on this framework.

In relation to something "If content can look GREAT on my monstrous monitor and the exact same content can also look good on a phone "out of the box" it cant be very good.", I don't really agree as I think it is completely possible visually to make a site present well on ANY device, and am in the process of a few sites/themes that should prove such. The problem IS just the fact that we (Drupal) still have to send the same content to ALL browsers... THAT is where this concept needs to be improved upon (in Drupal Core).

I would like this discussion to continue. I think it is valuable not just to this project, but to Drupal as a whole.

lagpro’s picture

lagpro commented

Fair enough, moving forward is a good thing :-)

I think it would be a good idea to set context against display size. This would provide some ability to change the content/layout as the screen resizes. The right thing would be to have the screen size thresholds show up in the context conditions. The screen size thresholds should then be supported as an arbitrary list that is checked by the theme as it sizes. Additional parameters can then be supported for device context.

The really really nice thing to do is to wrap all of this up as a "device" context that contains a name, min/max screen size, browser id/context - and add this to the context condition as a "device name".
The theme would provide the action on scaling.

Context is the key for making this really powerful (aka Drupal 8).

WillHall’s picture

WillHall commented

Very good read so far. I completely agree about omega being an absolute pinnacle. There really is nothing more to say about that. :)

In the meantime - because d8 is gonna be a good way off a helper module still seems to be in order. Or a process to complete the same goal (making lightweight mobile themes with omega)

I believe that our only real option is to detect user-agent (which is sad) using http://drupal.org/project/context_useragent - and then using context_php we can unset head elements. add add with drupal_add_js.

Any other possibilities outside of this?

DRIVE’s picture

DRIVE commented

Right On! I agree with you all to a very high degree. I am definitely in on pursuing the phones/pads etc.. We definitely serve a large portion of the millions of types of contents/services effectively on much smaller devices largely through minification and linearization. The "linear" part is what I would want to avoid. If a user is connecting to content from a phone I am going to be looking to "step" them through more "screens" rather than linearize a whole bunch of blocks and fully agree that the "context" as we are calling it is the key. Therefore the device becomes the key of the context and (just read WillHalls post) the same as we detect browsers (ugg) knowing the device right off the bat might warrant say, shuffling a few blocks into horizontal tabs to some degree or deciding that X object does not need to be served unless/until explicitly requested or required.

Reading content, images, video etc on a phone is a given to me. It is *easy* to shuffle that stuff around because people enjoy doing that. Let's take a business form, for example, which has 325 fields for input and that 10,000 people use each day. On a desktop we are stepping them through with not much trouble but when it comes to a phone our "context" has to now "step" them through this process MUCH differently. So when we are building this form should "next steps" be shortened from the get-go so that even a desktop user has the same experience or can the "context" now begin serving the form differently because it is serving it to a phone?

This is where my concerns are about this getting so deep that, as lagpro said, mobile stuff is too closely joined to Omega Core and thus creates host of "mobile considerations" for even the smallest of changes to the architecture? Like after taking my time to carefully create a sub-theme and the day it's ready Omega 7.3 comes out?? lol... You get my point. My subtheme is crap until I update it to 7.3 and I am NOT ;) ribbing you because it is a good example. I dont really want to get saddled with a whole bunch of mobile crap to do all the time (then why/how am I going to use it, I know) but is the mobile side going to actually require more overhead going forward? That technology moves a LOT faster than desktop computing... there are still millions (billions?) of users on IE6!

Hope this makes sense and is worth something. Most of the stuff I do is related to business usage/development so I tend to think about complex tasks and how to break them down sensibly for mobile. A car, though slower and more clunky than a motorcycle can definitely do larger tasks than a motorcycle and likewise a motorcyle can do things a car cant but on a much smaller scale though with more speed :D

I have need for this and appreciate being in on the discussion. I have only been taking part in this community for just under a year so I have tended to soak up more information, help out on some small tasks here and there and take it slow and careful. I spent a number of years donating my time to another platform and it turned out to be all bad. My company has used Drupal over the years but "I myself" have only been working with it for a short while, so I am taking it slow, but do think I can help in some way no matter how small :) I spent the first three months doing nothing but reading on here and experimenting with stuff until I got a feel for "what is going on".

I dont want to muck up this post with garbage so here is the relevance: End of last year I stumbled on Omega. One of the first things I soaked up was a video of a presentation himerus did at a DrupalCon about Omega. In less than one minute I could see that Omega was by FAR T H E way to go for me. Here was a guy with a genuis of a MEGAgem talking about how much he appreciated being able to "stand on the shoulders of giants" when referring to the pioneers of Drupal and Im sitting there going "this guy is a freakin visionary!". You deserve that... your work is cutting-edge and is greatly appreciated.

And to sum up, I will quote the man from his post above:

"...I think this methodology will leave most of the other base themes/grid themes and their maintainers scratching their head for some time to come..."

Good thing you are a giving person...ahaha... cuz while scratching the head they be studying the concepts and code! I see it sneaking into some of the other upper-tier themes... D8, I understand whats coming but you beat them all by miles! BOOM

Off to UPDATE .... 7.3... my subtheme is crap.... .... ... but THANKS AGAIN. I am in on this unless your brain slows down to your bodies speed a little bit. Much that I hope to help with but taking it slow. In the future you might condsider using some of my time for doc writing. AS you can see I am not short on words and really reading, specing and project management is most of my day :) Later! (thanks again Jake)

fubhy’s picture

fubhy commented

@lagpro We can do this... I am just not sure wether the need for it really exists. For CSS files I created the same functionality => Enable / Disable them based on the currently used grid size (narrow / normal / wide). This can also be done for Javascript files in the same way.

Also (now that you come up with this): Do we need to be able to enabled / disable Core and contrib javascript files like with the CSS File exclusion feature in Omega 3.x?

himerus’s picture

himerus commented

@fubhy, @lagpro

The issue here points again back to core issues with how things are loaded and sent to the browser.

With the CSS, we can load up all the files (based on the grid sizes and associated responsive CSS we have selected) and let the browser determine which CSS to present to the user. (based on the customizable media queries for each grid size. This is awesomesauce.

BUT, with JS, it is impossible to do this the same way...

What COULD be done is that the jQuery/JS is loaded via a media query (via custom code) but you couldn't load them all, and THEN only present those JS files to the user based on the screen size, orientation, etc. as we can with CSS.

While this IS absolutely a critical portion to a "truly" responsive system, this is where as a whole Drupal (even D7) falls short, but initiatives are in place to possibly make this better in D8.

So in the current ecosystem of D7, this is just not a viable option for the theme space, but should rely on the themer of an advanced project to be able to implement this type of concept in a way that works for the one-off solution for a project.

And for that matter, anyone that NEEDS functionality like that will likely be competent enough to find the solution that WILL work for that project's needs.

It's a sticky situation, and this is where we need to keep Omega from making "too many" assumptions about what someone is going to want/use out of a responsive system. I think we HAVE done this well... with the customizable/overwrite-able/disable-able grids and the ability to assign them to ANY media query you choose.

But if we went down a path with Javascript files (core, and custom) this would be taking a HUGE assumption on what the themer wants that I feel we just cant do currently in Drupal as a base theme.

WillHall’s picture

WillHall commented

@himerus I don't think that is completely accurate - javascript has an onresize function - if it were utilized to handle which additional javascript files were summoned you could very easily create a very similar responsiveness like we have for css in 3.x.

Though as you pointed out - this is not likely to be a need for every user - I would dare say that most users of omega have no clue what they are working with, and how powerful of a framework it truly is. Though the larger corporations and old school developers that utilize Drupal will, and it is those power users that this would be intended for, as well as anyone who really wants to develop full out responsive on-demand websites.

So, perhaps this isn't an issue for omega as a theme - but perhaps it is something that an omega helper module would bring to the table. Again, we are more than capable of doing this on our own in our own works, however as mobile becomes more and more common - it is going to be an even greater need for Drupal users - and there really is no other framework closer to achieving this than omega.

himerus’s picture

himerus commented

@WillHall... Well put....

Let me re-evaluate for a while here.... I do "get" the onresize events that we could utilize.

My "issue" is how to accommodate the case where we are using something like the following logic:

onResize event: If the scale of the window is equivalent to one of our media queries. Let's say for this example, the browser is now 980px of usable space (which should switch our CSS to the "normal" grid (960), I'd like to use javascript to load in one (or multiple) ADDITIONAL JS files that are also based on settings in the Omega theme settings interface. These JS files were NOT present on page load as it was loaded at a smaller size, but now we DO actually want them.

I guess that YES.. it IS absolutely possible to get this to work.... and it MIGHT be beneficial to have it IN the theme... otherwise, if (another user) created something for this in the module space, how can I ensure that Omega is even closely compatible for this feature. We have our own media queries (customizable) and would somehow need to interact with that module to say "Hey... I've got cool media queries I'd like to sorta make this other cool feature coincide with.."

I DO love this idea... and it WOULD give a huge benefit... but the concept of "doing it right" has me troubled.

</pondering>

jessebeach’s picture

jessebeach commented

subscribe

chiebert’s picture

chiebert commented

I just posted a discussion topic in the groups that I think relates to this all this: http://groups.drupal.org/node/145839. I don't know the answer, but just wanted to see if anyone had read/knew about the browser-testing approach developed by Filament Group (EhanceJS) and thought about ways it could piggyback on the various responsive design efforts we're seeing on d.o...

fubhy’s picture

fubhy commented

@chiebert The idea behind all this is really nice but Drupal just doesn't work that way + It still is Javascript and relying on Javascript is never a good idea. We discussed different approaches for many hours and came to the conclusion that the best possible solution still are @media queries. Thats why we chose to implement those and thats why they are working already :P. We will probably bring a modified version of adapt.js into this to make it work with older Internet Explorers but thats Himerus' project ;).

The @media queries have a really cool advantage that all the Javascript solutions don't have: The page reacts on rezising the browser window constantly without having to run clumpy Javascript that constantly checks the width of your browser and the device that you are using!

chiebert’s picture

chiebert commented

@fubhy: I understand - I'm only beginning to recover from an inherent reluctance to rely on JS myself, and I love the media queries wholeheartedly. My main concern in adding the post in the mobile and omega groups is to find some way (i.e., perhaps a Context) to detect when to do things like serve up smaller images, fewer/different blocks, etc. Since the original post in this issue was musing about ways to serve less data to the mobile environment, I thought I'd refer to the EnhanceJS project, since it's designed to respond to these sorts of things (and more, like older accessibility devices/readers). I'll go on hoping...

fubhy’s picture

fubhy commented

Right... For that it might be a good solution to create a Context plugin that can react on the DEVICE that the user has, not on the browser width though. If, for example, I have my browser window scaled to be really small because I have different browser windows open at the same time and want to see them all at side-by-side and then go to that webpage and that webpage notices that my browser width is really small I would see less content until I make my Browser window full-screen and refresh the Page. This doesn't seem like a good solution. However it would make sense to create a Context that can react on the Device only. This is possible without having to use Javascript because PHP has the possibility to retrieve the user-agent via $_SERVER. This would make sense. We can put that into Delta (as a submodule). That way we could serve less content to, lets say, iPhones or other Mobile devices.

fubhy’s picture

fubhy commented

http://at.php.net/manual/de/function.get-browser.php

WillHall’s picture

WillHall commented

Based on that - you are already going against what is great in 3.x - You are already going to see a different layout - potentially less content - than you would if you browser was larger.

onResize is an event - it doesn't fire constantly just like any other event. It is no different than click, or hover.

I think ruling out a javascript approach is potentially damning.

chiebert’s picture

chiebert commented

@fubhy, re. #15 - I completely agree re. a Context plugin based on the device. Being lazy, I was hoping the Mobile Tools and WURFL folks would get up to speed on their D7 versions, since WURFL seems to be the on-the-spot collection of new devices and MT provides the Context plugin. But then, I'm not keen on all the other bits of MT, so perhaps one should just get off one's [pick your metaphor] and learn how to create a Context plugin oneself... :)

lagpro’s picture

lagpro commented

Keep it simple.... in summary....

Scaling is good because it is an issue with presentation and how much "real estate" someone has to look at something. Mobile or desktop - scaling is a presentation issue. You can clip it, drop it, or rearrange it - that's your options. How do you define that for a page? By context and size

Capabilities and Optimization are different issues. Every device (mobile or desktop) has a different set of capabilities. The browser, libraries, and plug-ins determine what you can do. Some devices can handle the "full monty" and others are lucky they can display proper html/css. So the question here is, "What can I use to display my page?" (capability) and the stuff I can't use I don't want to load (optimize). This should be defined in a device/browser context.

Omega is good for the presentation issue (scaling) and it can be good for handling the capability issues. However, in optimizing the page load (aka Javascript, libraries, Flash, etc.) it is not. Putting it into Delta may be fine or creating other context or library behavior overriding module(s) would be a much better option.

fubhy’s picture

fubhy commented
Status: Active » Closed (fixed)

I think this discussion is more or less over and we did our best to implement this into Omega.