Spark update: responsive layouts in Drupal

Today, I'd like to share designs we've created for a "responsive layout builder" for Drupal that we hope to include as part of the Spark distribution. I'm very excited about this because it brings mobile and responsive web design to the masses.

We've worked on this "responsive layout builder" concept for many weeks, and I believe the result is groundbreaking. While other layout building approaches hand-wave responsive design and produce messy markup, our approach promises to be simple to use, produce clean and semantic markup. At the same time educating the user on the logic of responsive design. Once implemented I think that this is something that could really push Drupal to the forefront of the competition.

What better than to show you what we have come up with? The following 8-minute video walks through the designs, and also provides a bit of background on the Spark project:

Special credit goes to Kevin O'Leary from Acquia for being the driving force behind this work.

Technically, this is intended to layer on top of the Panels module, for better forwards-compatibility with Drupal 8. We hope to integrate this work with the research and prototyping actively being done for the Drupal 8 Blocks and Layouts initiative.

Acquia is actively seeking implementation partners for this and other important work. If interested, please contact Angela Byron. We'd love to work with others on this.

You may remember that two weeks ago, I shared a video of an in-line editing prototype that we'd like to add to the Spark distribuion in addition to this responsive layout building tool. Its implementation is well underway in the Edit module.

As you can see, things are starting to move along quite nicely. Please join the discussion in the Spark issue queue if any of the above functionality sounds exciting to you and you'd like to help!

Comments

Larry Garfield (not verified):

This looks like it's halfway between a GUI for Zen Grids and a TNG version of the Panels Flexible Layout. Given that the latter produces truly godawful markup there's plenty of room for improvement, but I don't see anything here that suggests this would do any better. Given how easy Zen Grids is to use, does this even need a complex GUI?

June 22, 2012 - 17:28
Steve Persch (not verified):

This is not an either-or question for UI vs. Zen Grids. It's a question of whether this tool generates new CSS on the fly for each configured region or if it puts a class on the configured region that matches the region to an existing CSS rule. In either case, an existing tool like Zen Grids could handle the actual CSS generation.

For either of those approaches, on-the-fly-generation or class matching, there is no need to reinvent the grid system wheel of margins and floats. Zen Grids and other tools have answered those problems pretty well already. (Full disclosure: Larry and I work with the Zen Grids author, John Albin Wilkins, and I've added to its documentation.)

On the question of markup, I don't think a tool like this would produce markup the way the Panels Flexible Layout does. From the demo, this UI looks like it would be nearly all CSS for its layouts. Markup would only need to be added when "grouping" which would add a wrapping div or other element.

June 22, 2012 - 23:25
Kevin Oleary (not verified):

That's correct, steve. I worked closely with Jesse beach when putting this together and one of our goals was design something that, when implemented, would generate as little markup as possible.

June 23, 2012 - 14:01
effulgentsia (not verified):

An alternate Panels Flexible Layout builder plugin based on a grid system like Zen Grids is exactly how to think of this. This solves two limitations that exist with the current Flexible Layout builder:

  • It removes all those extra div wrappers, because it's not based on a "columns"/"rows" model. In this design, div wrappers are only needed when grouping regions to control what constitutes a sibling for media query float control, which is exactly the situation in which a front-end coder would also add a div wrapper. The ability for a UI to produce the same markup structure as what a coder would produce has been a long sought goal in the Drupal community.
  • It allows you to use a UI to make a "phone" layout with the "Sidebar A" region below the "Content" region (or hidden), a "tablet" layout with the sidebar A region to the left of the Content region (or hidden), and a "desktop" layout with the sidebar A region to the right of the Content region, with all 3 using the exact same markup (just CSS media queries controlling the region widths, visibility, and sibling left/right float).

"Given how easy Zen Grids is to use, does this even need a complex GUI?"

There are lots of site builders, content editors, marketing department managers, etc. who want to create layouts visually, without writing HTML and CSS code by hand, even "easy" Zen Grids code, so yes.

June 23, 2012 - 04:12
Anonymous (not verified):

Zen grids is powerful and cool but I would certainly not call it "easy" (at least not for non-coders like me). Having said that I think that using CSS preprocessors may be the best way to go and if zen grids offers a shortcut to implementing this design then I'm all for it.

June 22, 2012 - 18:41
John Albin Wilkins (not verified):

Zen Grids was specifically designed to be used by non-coders. You just need to know how to use CSS and a tiny bit of Sass (which is an extension of CSS). No math, just the ability to count.

I'm not sure why problems you are encountering. But the best place to discuss that is http://zengrids.com/help/

The demo looks pretty damn good. Its improved a lot since the early sketches I commented on.

I particularly like the reverse Tetris mental model. It accurately describes the reality of using floats and clears when building layouts with the DOM. I'm sure that it does not match the mental model of most designers, but it is a simple analogy that they should be able to grasp in order to improve their ability to create designs that are actually possible with the DOM.

June 26, 2012 - 23:33
Hoopz (not verified):

The important question though is, does this "reverse tetris" model of building layouts match how users typically think when they're building pages? Whatever UI you create, it has to match the mental model of new users who approach it.

The central idea behind this mockup seems to be that you create complicated layouts by shrinking items, which causes other items to fit in the spaces created. This is rather unintuitive, because it means you cannot alter any item in isolation, and every change has some side-effect. If you have a page consisting of a top and bottom, and you wish to alter the layout of the top, this model would tend to suck in regions from the bottom to fill spaces created, possibly ruining the entire layout below.

The natural model of page layout as a two-dimensional process, not something that reflows like a DOM, or as this seems to do, even more unpredictable than a DOM, e.g. when sizing regions from the left.

Furthermore, it also doesn't teach or show the user initially how to achieve a certain layout, particularly more "mondrian"-like frame sets, for example a main feature spanning a certain height, flanked by multiple smaller items on the side. This is generally achieved with pre-built layouts, and by snapping together individual framesets, e.g. 2-column, 3-column, etc. and assign regions to the slots created. It would allow you to start from a skeleton template where you drag in your specific regions. If you create an open space, it would stay empty, until you choose to fill it.

Finally, this UI also has the problem that labeled regions bear no resemblance to the content that will ultimately go in them. No attempts are made at pre-visualizing this content to provide a more direct view on what you're building, and you wouldn't find out you've assigned a region to the wrong spot until you save and attempt to use the layout. Proportions, typography, content, media, etc are entirely absent.

If your aim is to build an intuitive tool, you should approach it from the end-user, not from the narrow technical view of "vertically stacked regions are one way to build layouts".

June 23, 2012 - 11:33
Mark (not verified):

I think the isolation would be achived to some degree by the grouping feature, so if you have the typical header, body, footer layout you could work in each group without effecting other areas. Can you give an example of when this would not suffice?

Also I actually the demo is very intuitive, vertically stacking is the only way to go imo, horizontal means nothing because the height is dependant on the content...

June 25, 2012 - 11:55
Kevin Oleary (not verified):

Hi Hoopz,

These are all interesting points, many of which were considered in our design process. Let me give you some background on our thoughts.

"does this "reverse tetris" model of building layouts match how users typically think when they're building pages?"

Short answer to this is no. The act of building a responsive design that dynamically re-flows based on the viewport size is not "typical" but it is the new reality that designers and site builders are living with. What we have attempted to do is expose the logic of how the CSS works without forcing the user to understand the code.

"This is rather unintuitive, because it means you cannot alter any item in isolation, and every change has some side-effect."

This is exactly true, In responsive design you cannot alter any item in isolation. All of the items in a layout have relationships to all the other items. Hopefully our design clarifies to the user what those relationships are.

"The natural model of page layout as a two-dimensional process, not something that reflows like a DOM, or as this seems to do, even more unpredictable than a DOM, e.g. when sizing regions from the left."

I agree that this UI will require the user to think differently but i'm not sure how any design that solves the problem of multiple viewports would not do this. It is not a two dimensional problem, introducing flexibility essentially adds a third dimension.

"generally achieved with pre-built layouts"

Your comment about pre-built templates is a good one. We hope to include several of these, what this tool offers, though is a way to step beyond that into something much more custom.

"labeled regions bear no resemblance to the content that will ultimately go in them."

The user can, if they choose, name their own regions.

"No attempts are made at pre-visualizing this content to provide a more direct view on what you're building, and you wouldn't find out you've assigned a region to the wrong spot until you save and attempt to use the layout. Proportions, typography, content, media, etc are entirely absent."

This is a great point. This tool does only deal with a narrow part of the larger problem space. We are currently working on an extension of this design which takes these concepts and applies them in context with your site content.

"If your aim is to build an intuitive tool, you should approach it from the end-user, not from the narrow technical view of "vertically stacked regions are one way to build layouts"."

Stacked regions map to the true underlying structure of HTML, you can choose to conceal, or reveal that for the user. Our goal here is to balance the needs of the user with the realities of current technology and front-end best practices. Someone else might design a tool that somehow automagically lets the user create completely unique fixed layouts at different breakpoints using complex markup and a boatload of javascript, but that does not map to responsive design and would doubtless be very difficult to maintain.

June 25, 2012 - 18:42
Daniel Harris (not verified):

As a non-coder this looks great and very useable.

One of my big concerns with responsive website creation is that I want to make the layout fluid between the breakpoints. I may have a number of target "tablets" that have varying resolutions but I don't want to create a breakpoint layout for each and every one of them. Hence I need a breakpoint layout for "tablets" in general, that have a certain resolution range, that will expand to fit the whole browser window and not leave any "white space" columns on either side.

I see there is a fluid/fixed setting in the "Add a region to this layout" but that would only act upon that region and not the whole layout, right?

Any light you can throw on this?

Cheers Daniel

June 23, 2012 - 16:15
philsward (not verified):

Overall, I like what I see. I was disappointed that the demo didn't include a desktop layout, so I am left to assume this handles that as well. As an active user of panels, the layout of this seems far more intuitive than the current method and if this puts the entire theme process in ours hands, even better. I am a non-coder and rarely mess with the theme template. If this gives me the ability to alter the entire layout of a theme on the fly, I think it is a great start. Only question I have: will it provide a way to have templates for things like nodes, user profiles, taxonomy etc.? Or is this strictly going to be at the very top level of the theme process?

June 23, 2012 - 20:54
Igor Flista (not verified):

Awesome work!

June 25, 2012 - 15:45
jobnomade (not verified):

Usually when you write CSS for responsive websites, you target a range of view-port widths. The media queries apply for example <480, or 360-480, etc. So I agree with Daniel that this should be considered. In addition I have a question.

How does the responsive layout builder works with themes, base themes, core themes?

Cheers,
Jan

June 27, 2012 - 10:21

Add new comment

© 1999-2014 Dries Buytaert Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.
Drupal is a Registered Trademark of Dries Buytaert.