Responsive Drupal.org: What we want in a framework

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

As part of the Drupal.org code sprint in Portland; Chris Ruppel, Joel Moore and myself have been discussing a new Bluecheese. A lean, tight, and admin friendly theme that lays out a framework for the future. One that would allow us to develop a mobile friendly, responsive design.

What we want

An admin friendly UI

The current bluecheese theme utilises the common 960.gs CSS framework. The layout is defined by inserting “grid-x” CSS classes into the html using template files and preprocess functions. It’s a maintainability nightmare and a high level barrier to making changes. This constructs a technical barrier and spreads the customisation among many files. What we want is a way to handle this layout through a GUI.

A true responsive layout system

The major problem with adding non-semantic CSS classes in the markup hits when we attempt to make this solution responsive. How can the class “grid-8” be reinterpreted to fit into a grid system with fewer columns? We need a way to switch out different grid systems based on the size of the screen. These breakpoints should be based on the content and the design, not current devices. This is different for every project; the content and design is unique. Tools like gridpak.com or gridsetapp.com are emerging that allow us to define these responsive grid systems.

Changing the visual source order based on breakpoints

We need to respect content hierarchy. Simply un-floating everything and making them full width is the path to a shoddy mobile design. Important information appears in the sidebars of Drupal.org. We need to respect this and maintain the visibility of this content. One example would be to move some of the sidebar content above the main content while letting the rest fall below. Another example is moving the navigation from above the content to below. Try out an example by Jordan Moore (Webkit only)

Current thinking is that the CSS Flexbox specification or CSS Regions spec could be the path to this in the far future. Right now, support is a little light.

Fine control over asset loading

“Mobile friendly” sites that don’t consider page weight are missing the point. We need control over when and how we load assets based on feature detection. There is no generic use case we can apply to every site.

So... do we use a base theme?

There has been some heated discussion previously on whether we should use a base theme to provide us with this framework and if we do; which base theme gives us our required solution?

What has become obvious this week is that there is currently no existing framework that fulfills all of these design goals.

Omega

  • Admin friendly UI — Yep
  • True responsive layout system — Nope
  • Breakpoint based visual source order — Nope
  • Fine control over asset loading — Nope

AdaptiveTheme

  • Admin friendly UI — Yep
  • True responsive layout system — Yep
  • Breakpoint based visual source order — Nope
  • Fine control over asset loading — Nope

Zen

  • Admin friendly UI — Yep
  • True responsive layout system — Yep, with some SASS based control over the grid systems. It also touts Gridset App support?
  • Breakpoint based visual source order — Partially yes, with Zen Grids, but see the comment below for fuller explanation
  • Fine control over asset loading — Interesting SASS based control actually.

Arctica

  • Admin friendly UI — Yep
  • True responsive layout system — Yep, but device based?
  • Breakpoint based visual source order — Nope
  • Fine control over asset loading — A bit?

Please jump in and correct me with any of these tests, I haven’t used all these base themes recently so I might of missed some deeper features.

Comments

Define "True responsive

cweagans's picture

Define "True responsive layout system", because Omega is certainly responsive - maybe you have a different definition, though.

Not sure what "Breakpoint based visual source order" is supposed to mean. In most of the themes, you don't manually set breakpoints - it's based on the order that the elements appear in the markup, which is the /sane/ way to do it.

"Fine control over asset loading": Omega allows you to disable loaded assets, including disabling core assets.

--
Cameron Eagans
http://cweagans.net

As far as I can see on

xacobe's picture

As far as I can see on Adaptative you can set a diferent order for mobile and tablets layouts. You can choose whatever left-sidebar will be on top or below the content.

On Omega I coulndt see this feature through UI.

ArcticaAdmin friendly UI —

JurriaanRoelofs's picture

Arctica

  • Admin friendly UI — Yep
  • True responsive layout system — Yep, but device based?
  • Breakpoint based visual source order — Nope
  • Fine control over asset loading — A bit?

No it's definitely not device based. Rather it has device inspired defaults, to give novice user an example of what 5 mediaqueries could be used for.
It's actually a completely flexible system in terms of mediaqueries because you don't just get to set the media queries, also the number of media queries. If right at the bottom of the Arctica theme settings form you change the "Number of media queries" option and save the form, a new theme settings form is generated to reflect your set number of breakpoints (or whatever other mediaqueries you use). This also bubbles through to the media-query based layout administration in the skinr forms.

See screenshot: http://i.imgur.com/88hRW.jpg

This Skinr integration is also what makes it attractive for admins, because it gives total layout control to admins through the skinr-block form, and it allows you to override layout settings in different levels of mediaqueries. Whether this is a mobile-first or desktop-first approach depends on what media queries you used in the theme settings form.

For example, this is what I have done with the Arctica demo site with 3 breakpoints:

Only local images are allowed.

Example of skinr-layout form:

Only local images are allowed.

That's the gist of what I'm trying to do with Arctica. A drawback of my base theme is that it's much younger than the others so we can expect it to be less stable. I also haven't found time to write any documentation. The best documentation at the moment is installing the demo site: http://drupal.org/project/starterkit_arti

Performance

I also saw some talk of performance in the other thread. I've done very extensive performance testing and optimization for Arctica and in that process I had tested a number of basethemes, so I have some data here that might be interesting for you:
https://docs.google.com/spreadsheet/ccc?key=0AncgY8HiyskidE5nZHZpeExoaUc...

What we can conclude from this is that Zen is the fastest theme, the other responsive base themes are slightly slower, except for Omega which is significantly slower.

What I learned from optimizing my themes backend performance is that if you want to do more stuff, and offer more shortcuts to site admins: you're going to pay for it with milliseconds, even if you optimize where you can.

These tests were done on a dedicated ubuntu machine that was not doing anything else beside running the tests so this data is accurate.

Non GUI settings?

leanderl's picture

Perhaps I'm the odd one out. But I would like to see a responsive base theme that offers the option of "non-gui" configuration alongside with all the select lists and settings panels of the GUI. It can be time consuming to configure everything through select lists and different tabs if you know what you want, or if you quickly want to try different versions of the layout. So if a base theme would have a settings file where you could quickly achieve the same configuration as the select lists allow you to, that's something I would find very useful. I like that about the "features" option in the theme.info file, how you can activate main-menu, slogan and other stuff there.

This is on the roadmap for

JurriaanRoelofs's picture

This is on the roadmap for Skinr: http://drupal.org/node/744706 so by extension it's on the roadmap for Arctica.

But using ctools/features is not really an ideal configuration deployment tool especially for website layouts.

If you're going to look into

tsi's picture

If you're going to look into base themes (though I agree with </a href="http://drupal.org/node/1438716#comment-5797010">Snugug that the best result will be by specifically tailoring a theme to your content) - you should probably check out Sasson too.

Sasson

  • Admin friendly UI — Yep, but you have a lot more additional power in your sass files (included).
  • True responsive layout system — Yep, with extra SASS based control over the fluid grid system, configurable breakpoints (optionally via theme settings) and responsive menus.
  • Breakpoint based visual source order — I guess this is possible with some user-agent detection and the Context or Panels module
  • Fine control over asset loading — well, not out of the box.

The point is that with Sasson you don't get a do-it-all-in-your-theme-settings kind of UI but a powerfull toolkit with a modular structure to give you all you need to tailor your own content-driven layout, and even enjoy while doing so (check out the file watcher feature :) ).
I do believe that the UI (theme settings form) is great. for site builders and newbees and for quickly getting a layout up and running, and Sasson do expose some nice features there, but In the end of the day, the true power of a themer is in the text editor, this is where Sasson really gives you the power and the tools to do amazing stuff - everything that can be set on the UI may be set/overridden in code, and many things you just don't want cluttering the form are available when you step out of the UI box.
Last, performance, Sasson is build with a modular approach in mind, it does ship many cool features but everything is optional and if it's off - then it's off. the end user should always get the minimum amount of semantic, clean code needed for displaying the specific project, for example - Sasson do uses 960gs but with no classes cluttering up the markup and with only a minimal set of CSS code sent to the end user - I would argue that any theme that loads all of this stylesheet even if not using half of it is probably doing it wrong.

Some clarifications on Adaptivetheme 7.x-3.x

Jeff Burnz's picture

Changing the visual source order based on breakpoints is kind of tricky to get right 100% of the time in a configurable system designed for site builders who can't dive in a fix something when needed.

That is the main reason why its not offered in Adaptivetheme, and I bet any of the others as well. We can't rely on really advanced CSS methods and properties due to browser support and need for excessive polyfilling.

That said...

Adaptivetheme 7.x-3.x uses layout plugins - and this idea of content source order control is 100% doable. Actually there are two types of plugins - a native page layout type plugin and 14 responsive Panels layout plugins. This gives sites like GDO very powerful layout capability in the hands of site builders.

Fine grain asset loading? Again Adaptivetheme 7.x-3.x does do this, a lot. The theme only loads what is required - its by far the most sophisticated base theme in this regard by a long way. You can control things like all CSS (core, library, contrib) either via the UI or a simple "unset" flag in the info file. There is fine grain polyfill loading - even load none, even down to removing little bits of CSS like rounding error support for IE6/7.

What it actually loads in terms of layout CSS (which is about it) is very small indeed - around 6kb on average, and only what you need based on your settings - all the layout CSS is programatically generated, built during submit of the theme settings and spat out to files, that are then loaded by load.inc, again, depending on your specific requirements. The layout plugins don't even have CSS files, the CSS is built / optimized programatically by the CSS generator functions.

Other asset loading via breakpoints or feature detection is the themers job, add your Modernizr/yep/nope and you are away. Adding Modernizr to your base theme is a mistake because of Modernizr custom builds, we can't make the assumption to load all of modernizr -that would place an undue asset loading requirement on all users when they just don't need it.

Adaptivetheme is a true responsive system, yes, correct, it just doesn't make this huge assumption about what grid to use - you define it. Its extremely smart and simple at the same time. I spent, literally, years thinking about this and working in this field, and found the best and only real way is do-very-little, as opposed to do-a-lot.

On performance, well, AT 7.x-3.x is very, very fast, it uses a lot of drupal_statics and other trickery to remove bottlenecks in Drupal core, yes, really, some of the worst bottlenecks are in Drupal core! It also uses cache sets to cache the layout plugins data structures to speed up the admin - the actual data structures never hit the front end, they are used only in admin for the UI and layout generation system, so there is zero impact on the front end.

As for friendly GUI? Well, sorry, AT has it down here, its deceptively simple and easy to use, because its well designed. Just ask anyone who has actually used this theme, they will tell you, its easy. Do not mistake this for lacking features or raw power under the hood, it reduces very complex and powerful operations down to simple easy to use front end UI. That is good design - both in terms of UX/UI and system.

You also missed one very important point I believe - you want real end user control over page layout, but in a REAL responsive theme you need control over the node content as well - this is where AT kicks ass over all others, period. It uses responsive panels layouts which you can use in Display Suit or Panels, for total and complete control over the layout of each node. Try it, in AT 7.x-3.x, you will get a smile on your face when you start playing with this, its awesome.

And no, it does not require these modules either, you can add them as a way of extending capability, AT also includes layout snippets that places the same capability in the hands of the themer who wants to work in code at the field/node content layout level.

leanderl - you can do this in

Jeff Burnz's picture

leanderl - you can do this in Adaptivetheme - you can have complete control via the info file. It even generates an info file backup in the public files directory with all values from theme settings, you can use for storing your config and very, very fine grain control over your settings, see this: http://adaptivethemes.com/documentation/file-generation-system

There is a section in there about info files, which goes into this to some degree, it needs more docs but its very neat indeed.

Thanks for the tip Jeff, I'll

leanderl's picture

Thanks for the tip Jeff, I'll look into that... Sounds like my cup of tea...

leanderl - yes, a lot of time

Jeff Burnz's picture

leanderl - yes, a lot of time was spent on building this, because often as themers we simply never get the opportunity to migrate the database we are using to build the theme, or we cannot push the files directory at the VCS etc, so we need a way to capture our config other than the database (volatile and vulnerable during development/migrations, which can be daily on many projects, especially large ones).

This is a way around that, to be able to capture the config and migrate it easily to the development/staging server.

Right, I guess Arctica also

JurriaanRoelofs's picture

Right, I guess Arctica also supports that if you use the Nitro module with it:
http://drupal.org/project/nitro

Then you can basically do:
1. Export theme settings
2. Store them as defaults in your sub theme's .info file
3. deploy the modified .info file to some external environment
4. press "reset to defaults" in that environment's theme settings form.

Those features in Nitro are courtesy of Omega Tools btw.

It's the Skinr settings that you will want to migrate often though, if you're using an OTAP street. Though since Skinr uses it's own tables I reckon it's manageable even without using features/ctools exports.

Yes, cool, but, in context of

Jeff Burnz's picture

Yes, cool, but, in context of Drupal.org here we have an issue, and its an issue with all these themes that require modules, they need security clearance and other reviews before going anywhere near D.O. or any of the sub-sites.

You know my view on relying on modules for themes, its fraught with issues, you can do it because its your module, but I can't risk the sanity of 30 000 users going bananas if a module decides to take a year to refactor itself, which is their call, fine, but I can't risk my user base being held up in this fashion. We already seen this happen with one user base and sadly that theme/project is now destroyed because no one wants to take the risk again.

Omega

himerus's picture

To throw a few comments in this ring without sounding overly promotional to Omega, here are a few things I would point out about Omega, which was the FIRST base theme for Drupal 7 to implement any level of responsive behaviors.

In the development of the 3.x branch of Omega (the cool, responsive one) we took (for the most part) the stance of we simply cannot assume too much about what the user wants to do when implementing a responsive design/layout/drupal site.

Omega does currently utilize 960.gs and variants of the grid based on 960.gs (which Drupal.org IS currently using) including the grids at 1200px, 960px, 720px (oh, and don't forget the fluid layout) all while falling back to a stacked mobile layout. While simply stacking all regions in mobile is considered "bad", this is where Omega could make zero assumptions, and by default, stacking them is logical. Any adjustments can easily be done (as they can in any theme, base or custom) to manipulate the mobile layout as needed. The same could be said for the variants of the 960 grid where by default in the 3 non-mobile grid sizes, items simply scale down by redefining the width of grid-xx and container-xx classes... Is this the best long term implementation for responsive/adaptive layouts? No... but it is again not making any assumptions...

With Omega though, Any of these simplified "default behaviors" can easily be manipulated by any means a themer normally would use to adjust the positioning, sizing of regions and grid classes via CSS at various levels. So at a 960 (normal) layout, you may want all the sidebars inline with the content, but at a smaller 720 layout, you may instead want only one sidebar beside the content, and the next to shift down below both items. This can be accomplished with just a line or two of CSS as needed in any situation.

Regarding asset loading...
This is a sticking point for me as truly NO theme has figured this out as a best case scenario... there are modules out there now to assist in the loading of images of a more appropriate size based on the device size. When all the base themes implemented some level of Responsiveness, there was and still is little ability without a LOT of custom code, and potentially hacky methods to manipulate the content sent to the device. And to the original definition of Responsive, it is NOT to be sending different markup to a device based on its size or orientation, but it is to be rendering the SAME markup differently based on the size of the viewport.

This is a point many of us are working in our own ways to solve, and Omega makes ZERO assumptions here based on this, unlike what some have claimed. Omega hides nothing on the mobile version. That is up to the implementation use case, and how it should be handled. I've used on various large projects methods ranging from js/ajax/json loading of some content after determining that a device is not of a mobile size, I've used various modules and custom code to manipulate images sent to the browser, and none of these are particularly elegant solutions at the moment... we are ALL still learning what should be considered "best practice" in this regard, and some of us have wildly different opinions on the matter.. which is GOOD because if we all just agreed, we may be missing out on the true nature of open source.

All of the base themes listed in this discussion (and others) have continually learned from each other... When Omega was born for D6, it was a hodgepodge of features from Zen, Tao, Genesis, Studio, etc. Then some of our own functionality and features were born, and new themes adopted some of those. As a community, it is obvious that base themes are the leaders in the market for functionality and starting points as is apparent by the top 4 themes (including Omega) are all base themes. As Omega continues to evolve, we will continue to learn from others. I may have chosen Method X to overcome something, but maybe Zen did a better job in a new release of that using Method Y, so at some point it all blends into Method Z.

Omega also uses advanced caching using drupal_static and compresses the many media query files (that drupal breaks into multiple groups in drupal_add_css based on the media type into a single CSS file when page compression is turned on. I'm often appalled at some of the comments that Omega is slow and I have yet to see true proof that it is more than a few milliseconds faster or slower in any way than any other theme. A lot of time, energy and care went into 3.x making sure it was as performant as we could possibly make it. Sites like Acquia, Commerce Guys, Georgia.gov (launching in a few days), an Associated Press platform, Maxim Magazine and others might not have used Omega if it was so truly slow...

I think in the long run though, regardless of what base theme Drupal.org runs on that the move to using a base theme that many understand and use on a daily basis (based on usage of Zen, AT and Omega) is a good move, enabling more people to be able to readily contribute to the process over a completely custom theme that only a small handful of people understand the inner workings of. I hope the Drupal.org site WILL adopt the usage of a base theme, regardless of if it's Omega or one of the other great base themes listed.

I think we simply have to remember that while those of us leading the responsive in Drupal charge, that we don't know every perfect solution yet, as they haven't been created yet for Drupal, and in some cases even on the web outside of Drupal... While we all love to have a project where we can play with and test all these new things that we don't get to on every client project, the Drupal.org upgrade is happening NOW, and we must rely on what we know now, what can be done easily now in a reasonable time frame, and get it done!! Moving Drupal.org to D7 is a great step forward, and we all respect and appreciate what those of you leading this charge are doing, and the time spent doing it.

I'm often appalled at some of

JurriaanRoelofs's picture

I'm often appalled at some of the comments that Omega is slow and I have yet to see true proof that it is more than a few milliseconds faster or slower in any way than any other theme.

Hi Jake - sorry I didn't mean to insult Omega or the people who developed it. I did feel like I should point out Omega was tested to be slower because I remember that when I did the tests, the omega project page said it was the "Fastest base theme to date" and I've seen this referenced many times after I did the test so I thought my results to be noteworthy.

I think what should be taken for my comments on performance is that if a theme does "more stuff" it will be less performant. I don't mean to say this makes it a bad theme, the test also lists some of my sub themes and they test relatively slow compared to probabl many other themes but that just makes sense because they do a lot of stuff.

Oh, and exportability...

himerus's picture

Oh, and Omega of course also have it's settings pushed to any development/staging/production environment as all the settings are easily exported back to the .info file for the theme once it is fully configured using Omega Tools.

Any talk about about

msonnabaum's picture

Any talk about about performance needs to be backed up with profiling data. Testing with ab is not going to tell you anything useful in this case.

Use XHProf (remember to disable xdebug completely), look at exactly how much time is spent in the theme functions, look at what functions get called from the themes, etc. This stuff is totally measurable, no need to speculate.

When fixing performance

JurriaanRoelofs's picture

When fixing performance issues you want to profile yes, when doing a comparative test no.

Looking at your test data the

greggles's picture

Looking at your test data the standard deviation is 15% of the mean. Since the differences in performance are ~10% the test seems to have a lot of noise in it and may not be conclusive. You could try increasing the sample size and working to limit the impact of other elements on the test data, but ultimately ab is always testing a lot of factors (apache, network, etc.) when the thing you really want to look at for a theme performance comparison is the CPU time spent inside that theme.

The benefit of a profiling approach is that you can isolate the elements that you don't care about and just look at the item you do care about. If you looked at the time spent in theme() in xhprof it may confirm your previous tests, but could do so with more confidence.

Valid comments, but for the

JurriaanRoelofs's picture

Valid comments, but for the test I specifically reboot the machine into a clean install of Ubuntu and make sure it has not internet activity and doesn't run any services that might interfere with the test; I try to create some sort of sterile environment and the only factor I change between the tests are the active theme. (+a small fusion specific changes that I mention in the notes). I even pre-heat the cpu with some testing so that the first tests don't have a cold-start benefit.

Then I did every test 3 times to see if they dont show any weird variances.

I feel that enabling a profiler would introduce a significant amount of overhead and possibly introduce interactions with what I'm testing.

Adding a profiler would

greggles's picture

Adding a profiler would impact the test if you still performed the test via a tool like apachebench. But if you load the home page and look at the profiler (e.g. xhprof) output for time spent in theme() your results should be much stronger.

I appreciate that you tried to make the environment as static as possible, but the size of the standard deviation shows it wasn't really isolated. When trying to evaluate the performance of one element you should not measure 20 elements - you should just measure the one element.

Thanks for the tip. I'll try

JurriaanRoelofs's picture

Thanks for the tip. I'll try that out as well some time soon.

If I'm to chime in here for a

Snugug's picture

If I'm to chime in here for a moment, you're going about this search all wrong.

If you will grant me to quote Ethan Marcotte, literally the man who coined the term responsive design, "avoid starting large then shrinking down. Approach layout from a mobile first approach. Fits in with progressive enhancement." Your breakpoints should be based on your content as well, not on an arbitrary size (and this will likely mean many different breakpoints). To quote Stephen Hay, "start with the small screen first, then expand until it looks like shit. TIME FOR A BREAKPOINT!" Finally, when designing a Mobile First Responsive website (which is what should be what we're looking to do, not simply create something with a moving layout), we should be bearing in mind Kristofer Layon's Hierarchy of Mobile Motivations and understand that a mobile user's needs are primary navigation and content and that 74% of mobile users are willing to abandon a site if it takes more than 5 seconds to load; everything else is secondary and should come secondary.

tl;dr: Use the lightest weight, semantic, content-first HTML5 base theme you can find (my suggestion being the HTML5 Project, build the site using Sass from a text editor instead of a GUI, and have modules handle assets instead having the theme layer hangle it.

So, with this in mind, let's take a look at your requirements:

  • Admin friendly UI
  • True responsive layout system
  • Breakpoint based visual source order
  • Fine control over asset loading

Let's start with Admin Friendly UI. From reading your requirements, what you're really looking for is a way to build your fluid grid (and it does need to be a fluid grid) quickly and easily and be able to change it without needing to add unsemantic classes everywhere. May I introduce you to Sass, Compass, and the Susy Compass Extension. These three tools allow you to very quickly and very easily build out a fluid grid system tailored precisely to your needs in exactly four lines of code (those four lines being four variables: $total-cols, $col-width, $gutter-width, and $side-gutter-width). Did I mention it sets up a semantic grid, which means that gone are the days of '.grid-8' and in are the days of '@include columns(8)'. May I also mention that 8 columns can still makes sense at small sizes, it's simply a percent of the whole grid (aka there is no need to change total number of columns as you resize).

Next, a True Responsive Layout System. May I suggest that beyond a fluid grid, there is no such thing. Any system that assumes anything beyond that you want a a single column by default without taking your content into consideration is doing it wrong as anything short of that is no longer about your content. RWD is not about how many cool layout changes you can make, it's about providing the ideal experience for viewing and and finding your content as possible on any web enabled device.

Third, Breakpoint Visual Source Order. This is a nice idea, but totally misses the point of content based break points and mobile first. The most Mobile Optimized your site is ever going to get is an HTML document with no styling and no JavaScript. If you're looking to rewrite HTML source order at different widths, you're doing it wrong and probably breaking semantics. If you're looking to see the visual source order at a given size, open up your browser. Besides all of this, you cannot do that without knowing where your content is breaking. How do you know where that is when building content based breakpoints? Practically, how do you envision something like this looking when its possible to have different breakpoints for different blocks on different pages? How would you go about changing VSO when it may break how other things work? You need to design in browser and build reusable systems, not through a GUI.

Finally, control over Assets. Why are you considering a theme for this? Isn't this something better suited for a module? Modules have the same amount of control (or more!) over CSS and Core assets that Themes do, the only reason base themes do it now is to ensure that you have a package to work with until module dependencies for themes works. What about inline images? That's an issue that needs to be dealt with through a module. My solution, Borealis RI takes an Image module first approach to the issue, but admittedly needs some love which, should the need arise beyond my own use cases, I'm willing to put a great deal of effort into to finish polishing it up. There are many other solutions out there as well, some better than others, but all require a module-centric approach. As for lazy loading content, yet another thing better suited for a module than a theme.
As for CSS image assets, those are 100% CSS layer (or should be) and should be base theme agnostic. If you want to get into some fun when it comes to asset management (esp. for rwd), take Compass's Magic Image Spriting for a spin.

So what's a dev to do? My suggestion is fairly simple. Ditch any base theme that is going to try and handle your RWD for you, you need to build it by hand if you want it to look, work, and feel right. Find a theme that does the bare minimum for you and nothing else. I like my Aurora> base theme because all adds in HTML5 Boilerplate's Modernizr build, adds Chrome Frame code, and moves all JavaScript to the bottom of the page (to prevent blocking), it hooks up Susy to your HTML structure by way of theCompass Aura Extension, which aids in building a grid to your content and attempts to give you some basic content (re: typographically significant) based breakpoints, and it's using the HTML5 Project for its templates, making it Drupal 8 Future Friendly (plus super light and super semantic). If you don't want to use Aurora, I'd suggest using the HTML5 Project straight. Use Sass+Compass and design in browser. Install Sass 3.2 using codefilter_code gem install sass --pre[/codefilter_code] to get the superpowered responsive stuff in Sass (also needed for the Aura extension). If you absolutely need a PHP centric solution for Sass, use the Prepro and Sassy modules for PHP Sass compiling and I'll help convert any Compass extensions you want to use, otherwise I highly suggest using the Ruby gems locally. Offload asset management to modules, themes should not be in charge of this and having a stand alone module built would make it easy for asset management tools to find their way upstream into D8 or live as a Contrib module. Always bear in mind that RWD is not about adapting large layouts to smaller ones, it's about giving your users on any device an ideal way to view your content, and it should be done with the mobile user first on the list.

As always, with love,
~ Snugug

While simply stacking all

Jeff Burnz's picture

While simply stacking all regions in mobile is considered "bad", this is where Omega could make zero assumptions, and by default, stacking them is logical. Any adjustments can easily be done (as they can in any theme, base or custom) to manipulate the mobile layout as needed.

Yes, I quite agree. All of use "base-themers" could make many assumptions but we can't, its not possible, unless we want mile long issue queues.

We can do the "preserve visual order thing", but we will do it at a cost, even with documentation. Believe me when I say this - I bet this is one of the most "front of mind" issues we all think about, all the time - how to solve this issue in a configurable system and not break shit all over the place and not make it overlay hard for end users to deal with.

As I said way above, this is in the "too hard basket" a lot of the time, not saying it can't be solved, but that it is hard, and right now none of use have come with a viable solution, not because we are not trying, not looking, testing, thinking and prototyping, but because with today's current, broadly used browsers and technology, this is very hard indeed.

I also agree that stacking/wrapping is a logical thing to do, it makes sense a lot of the time, especially when the last thing you want is visual source order preservation - often this is not wanted, instead users want sidebars pushed down with content promoted to the TOP of the visual source order.

Just 2 euro cents about

betarobot's picture

Just 2 euro cents about stacking in our case block regions on top one another: makes perfect sense as there will be some cases of placing some important stuff (notices) on top of main content.

And/or we are still able to configure that via block visibility. In other words don't forget about already there drupal functionality.

I don't know the base themes

Graeme Blackwood's picture

I don't know the base themes being debated as intimately as their makers, but my instinct is that the lightest weight/fastest theme of all would be on built from scratch as Snugug suggests.

Having said that, I am wary of relying too heavily on SASS, as it can generate very bloated CSS, so it's important to plan well and be as object oriented with the CSS as possible, even if we use Compass/SASS.

Having said that, I

Graeme Blackwood's picture

Having said that, I appreciate the best base themes have been designed to be very lightweight, and it might be silly not to leverage the effort and thinking that has gone into them, assuming they don't suffer from a performance hit due to a load of extra stuff we are not going to need.

Having said that, I am wary

JohnAlbin's picture

Having said that, I am wary of relying too heavily on SASS, as it can generate very bloated CSS

It can create bloated CSS, but only if you don't know how to use it properly. :-)

You can also write crap CSS by hand. :-)

If you use Sass and Compass correctly, you'll end up with leaner CSS. Seriously.

  - John (JohnAlbin)

Absolutely, I am thinking

Graeme Blackwood's picture

Absolutely, I am thinking partly about the various people who will have to maintain the theme too. It's fine being crafted perfectly from the outset, but what happens when stuff gets bolted on etc? That's why it needs to be object oriented and carefully thought through. I know I don't have to say that though!

Thanks for bringing this up

rupl's picture

Both the implementation and documentation issues have been discussed with d.o infra team. We're aware of the long-term issues as maintainership passes hands over the years, both from anecdote and from other d.o projects which leveraged Sass previously. Right now we're opting to avoid it, partially because the permanent d.o team doesn't have a Sassy dev (besides Boyer of course!), and we don't want to introduce undue burden on them.

What Jon said.

Snugug's picture

What John said.

What base themes should and shouldn't do

JohnAlbin's picture

Undoing what a Base theme does

Yes, I quite agree. All of us "base-themers" could make many assumptions but we can't, its not possible, unless we want mile long issue queues.

I completely agree on this point. Actually, that should become part of the criteria for selecting a framework for Drupal.org. How many assumptions are we going to have to undo for any specific base theme?

Fields is a classic one. I would have had Zen 7.x-5.0 out last fall, but I wanted to solve the problem of using the correct semantic HTML5 element for each field. But from the theme layer, there's literally NO WAY TO KNOW the semantics of a particular field. That's why several of us at Palantir wrote the Fences module. http://drupal.org/project/fences

I would highly recommend the drupal.org upgrade team take a look at the new Fences 7.x-1.0 module. The project page gives a pretty good use case. And Fences adds zero database queries to each page load since the Fences configuration is stored with the field configuration. You can contact me directly if you have more questions.

If a base theme is picking field wrappers for fields, then it will override what is configured with Fences. Sad pandas.

Semantic ordering vs. Visual ordering

We can do the "preserve visual order thing", but we will do it at a cost

That's another issue I've been thinking about.

The base theme shouldn't be re-arranging stuff with JavaScript. You could conditionally load some blocks with AJAX if the viewport is big enough. However, I'd question the usefulness of any block that "shouldn't be loaded for mobile users." It is more likely that block shouldn't be loaded for ANY users. Luke Wroblewski's Denver keynote explains this best. http://denver2012.drupal.org/keynote/luke-wroblewski

But once you've decided on the blocks needed for all users, you should think about what is most important.

And the most important thing should be FIRST in the HTML source order. The second most important thing should be second. etc. etc.

Basically, the HTML source ordering should reflect the semantic, natural importance of the content.

The design should reflect the importance of the content.

From within Zen (or any base theme), it has a clue of the semantic importance based on the region name. "Content" is king. That region and its supporting stuff (help, featured) should go first. Then navigation then sidebars.

From the initial wiki info above it looks like there may be some "side bar" blocks that are very important. I would argue that a new region should be created for those important blocks and that they should appear much higher in the HTML source then the other sidebar blocks.

So how do you re-arrange stuff visually while keeping a semantic source ordering? Well, that's what the majority of my Drupalcon Denver presentation was about. I talk about a handful of building techniques that you can use for layouts. They are flexible techniques and not tied to any specific layout method. They do, however, reflect the current realities of the box model and the float model since the newer CSS layout modules are several years away from being "available on 90% of devices/browsers".

You can jump to minute 37 to hear my discussion. http://denver2012.drupal.org/program/sessions/rethinking-responsive-buil...
I updated my slides since the video is missing my laser pointer and hand waving when discussing how things are floated. http://denver2012.drupal.org/sites/default/files/rethinking-responsive.pdf

We need to respect content hierarchy. Simply un-floating everything and making them full width is the path to a shoddy mobile design.

I think you'll see I slightly disagree with this point. Maybe. The way to have a stellar mobile design is to make the HTML source follow the semantic importance of your content. The designs for the larger-sized screens should be based off the mobile one. But maybe we're saying the same thing. Drupal.org should build the markup based on a 1-column layout and then style the "desktop sized" design using that source order.

What about Zen?

Everyone else seems to be jumping up and down about how awesome their base theme is. I'm simply going to point at the feature list of Zen 7.x-5.0 which is on the project page: http://drupal.org/project/zen

But the biggest feature of Zen is it makes no assumptions about your content and your design. It does the most minimally useful thing for all designs and gets the hell out of your way. If you don't like something, you can remove or override or ignore a feature without any performance hit. Don't like normalize CSS? Remove the .info file. Done. Same with every other feature.

Back-end and front-end performance

Back-end performance of Zen has been a critical priority of the project for years. I've done performance tests with ab but they aren't publishable since they suffered from the same giant standard deviation that Jurriaan's tests suffered from. But they basically showed the same thing. The more features in a base theme, the slower it was.

You'll note that I don't talk about how performant Zen is on its project page. This is because I haven't finished my XHProf performance tests. I got some great tips from msonnabaum during Drupalcon Denver. It's on my to-do list. :-)

I think its important for the base theme authors to share and collaborate to improve all of the projects' performance. But the Omega claim that it has “Performance enhancements, making Omega the best performing base theme to date” is demonstrably false. I know others have asked Jake to remove that statement, but sadly he has not.

Ultimately, front-end performance is more critical then back-end performance. Front-end performance is also a critical priority for Zen. That's why Zen 5's markup and CSS footprint is so small. After turning on Sass production-mode compilation, the total CSS is only 14k (including print styles and all vender prefixes like -o and -khtml). If you remove the CSS3-prettified tab styling and the 3 menu images that are included via Data URIs, the size drops to 10k. Zen includes no images and only 2 JavaScripts (which are only loaded conditionally by IE8 and lower, but also minified and pre-aggregated together). The responsive meta tags are the ones D8 will use, but they can be turned off if Drupal.org doesn't need them. (But then turned back on when it does need them.)

A base theme can screw up front-end performance. That should be another criteria for drupal.org. But as long as a sane base theme is chosen, its more important what the bluecheese sub-theme does.

How can I help?

I'm so happy to see all the people volunteering to work on the sprint. And, ultimately, it is your decision because you are doing the work. With the D8 mobile sprint and now rebuilding the D8 theme layer, I don't have time to commit to a lot of work in upgrading our Drupal.org home.

But I would love to help out as much as I can. Can I be a sounding board to the front end developers on the project? I'd be glad to help think out issues before or while things are being implemented. I can answer just about any obscure question in D7's theme layer. And I can be a reference for the Fences module. Or the menu_block module. (Oh! would that be useful on d.o.?) Or for Zen, of course. Or for the Zen Grids layout system which is Sass-based and not tied to any theme.

Do you need some performance tests for the base themes? I can drop some other work and get this done if you need it. Just let me know.

  - John (JohnAlbin)

Great to hear about what Zen

Snugug's picture

Great to hear about what Zen 5 is doing (I must say, haven't kept up w/it), but John makes the point better than I did, so I want to reiterate it: no matter what base theme is chosen, "front-end performance is more critical then back-end performance" and that "the more features in a base theme, the slower it [is]." So, when choosing your base theme, make sure it is as close to as slim and performant as you would code by hand, which is clearly the approach both John and I have taken. Use that as your criteria, and the rest will follow.

WPO is essential

rupl's picture

Trust me, I'm all about frontend performance. That's why we've spent days on this decision instead of just plowing forward. Please be assured that I will obsess over frontend performance until the PM makes me stop :)

Funny thing: my very first reaction was to do frontend profiling of the Omega work that @banghouse had put together, expecting it to be as slow as all the sites listed on Omega's project page. Issue resolved, right? Welp, I found out that with the minimal theme we have on d.o combined with aggressive reduction of the default settings, the performance is far better than pretty much any other Omega site. An Omega subtheme can be massaged into producing very slim output.

If anyone's wondering, here are the results of Omega output with no responsive features using 960.gs (default) . I chose this configuration because it is the scope of our work for this phase of d.o D7 upgrade. I realize it sounds pretty basic compared to the pie-in-the-sky plans we're all discussing for the future, but it's the data we have at the moment.

There is no good choice here…

mikl's picture

Techical issues aside, I don’t think picking any base theme is a good thing for the community. No matter what base theme is selected, the proponents of the other base themes will be less inclined (and less able) to work on Bluecheese in the future.

Secondarily, this will likely end up as a protracted bikeshedding session, eating away a lot of energy that might have been used for productive work, and feelings will likely get hurt as the arguments become heated.

Tertiarily, there’s the signal value in having the theme used on Drupal.org. This will give undue attention to one base theme to the disadvantage of the others. This is not a healthy thing for the community. While I know some of the base theme authors strive for Drupal world domination, a monoculture would be harmful to the continued evolution of base themes. We need competition.

Quaternarily, I think the scale and scope of Drupal.org eventually will require sufficient customisation that a base theme will be more of a burden than benefit. If we must pick one I’d prefer Zen, but for large scale projects, my experience is that base themes are more trouble than they're worth.

Think for the future

gdemet's picture

I'm not here to advocate for or against any specific approach, but I would like to offer a couple of thoughts to keep in mind:

The whole point of choosing a responsive design is to create a site that will work as well in the future as it does today, regardless of what device the visitor is using. As the Future Friendly manifesto (signed by DrupalCon keynoters Jeremy Keith and Luke Wroblewski, among others) points out, "The quantity and diversity of connected devices—many of which we haven't imagined yet—will explode, as will the quantity and diversity of the people around the world who use them."

This thinking needs to be first and foremost in the mind of the Drupal community as we decide what direction to choose for a responsive theme for drupal.org. As the original post states, the goal is to create "a framework for the future". We will not know (nor should we care) whether future visitors will be using their desktop, their laptop, their tablet, their phone, or their Internet-enabled refrigerator to access drupal.org; whatever solution we pick needs to "just work" (as much as reasonably possible) for all of those users. That's why I'm dubious of any solutions that are device-oriented instead of user-oriented.

Retheming drupal.org is also a significant effort. We need to just not just address the problems we have today, but also make sure we're in a good position to address any issues that may come up moving forward. That's why we need to make sure that whatever solution we pick adheres to widely-known and accepted standards within the greater Web development community.

I think these are important things to think about, and I'm glad we're discussing them in the open as a community, because whatever choice we make will be "owned" by the community (and supported by the Drupal Association) for several years down the road.

Personally I would use no

JurriaanRoelofs's picture

Personally I would use no base theme for the bluecheese job, just choose a grid system or roll out your own, and get on with it. Some block management GUI like skinr or whatever other options are out there would be great for webmasters.
I didn't come here to promote my base theme I just explained what it does.

Let's distinguish between

LewisNyman's picture

Let's distinguish between "framework" and "base theme". The title of the thread states that we need a framework. That's a pretty broad target.

I never said we should use a base theme to develop a responsive design that I intend, in fact a quick analysis and discussion showed that there is no present base theme that does all of what we need.

If one of the base themes provides us with that framework in the future, fucking A. If not, we roll our own custom framework. I would rather we worked with a base theme maintainer to create a flexible framework instead of an out of the box solution instead of siloing our work.

For the time being, Drupal.org needs a Drupal 7 theme in the very near future. This discussion will not hold that up.

Jurriaan - yes, I too, I am

Jeff Burnz's picture

Jurriaan - yes, I too, I am just explaining how it works, that is all. For clarification because the new version is quite different to what most have seen before.

mikl - I could not have said it better myself. I 100% utterly agree with everything you just said. Bang on, every point.

For the record I too tend to think Zen is the logical choice for D.O., gdemet and JohnAlbin make compelling arguments, to which some discussion should be added, by the team, which would be nice, to have, at the very least, some discussion on this matter.

How about Lewis you do what

Jeff Burnz's picture

How about Lewis you do what we have always done and work with the community? You know, us guys and gals out here who actually built core and this community over the past 6 to 10 years? Would be nice. You know.

Thank you all for your comments and opinions!

Senpai's picture

We're going to have to close this thread today, because we're past the halfway point of the upgrade sprint and further discussion will now be fruitless and circular.

What an amazing, talented bunch of themers we have in our community! Thank you again to everyone who took the time to weigh in on this very important but touchy subject.


Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805

Senpai's picture

Re-enabling comments now that the planning sprint is over.


Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805

Graham Miller's Responsive Grid System

paskainos's picture

Has anyone seen or taken a look at Graham Miller's Responsive Grid System?

No!

arippberger's picture

No, but it looks pretty cool. Maybe I'll have to try it out on my next project. Love your user picture by the way :-)

Graham Miller's Responsive Grid System to the rescue

trickyricky26's picture

paskainos,

Graham Miller's Responsive Grid System is exactly what I have been searching for. Many thanks for the recommendation.

I have toyed with all of the major responsive base themes but they end up being way overkill for my style and type of projects.

It is definitely worth a look and super easy to integrate if you like the bare bones/non-interface approach to theming.

I wanted to learn the

Mile23's picture

I wanted to learn the responsive stuff, based on a talk given by RaisedEyebrow at PNW Drupal Summit.

Here's their presentation with links to the Zurb Foundation framework and RE's Cogito project: http://www.raisedeyebrow.com/blog/2012/10/more-automation-drush

I ended up using Skeletontheme because it held my hand a little more: http://drupal.org/project/skeletontheme

It's based on the Skeleton boilerplate, and is nice because the 960 stuff works like: .two.columns .offset-by-three which is very readable.

Theme development

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week