As you may or may not know Blocks and layouts is a design problem that I have been working on for the better part of three years since I first started working at Acquia. Back then Jeff Noyes, Dries and myself were just focused on introducing drag-drop blocks to Drupal Gardens and didn't have a view to the wider problem of layouts because really at that point seven was not even out and it just seemed too big a problem to solve.
None of the many iterations on those initial designs never made it into development but I continued refining the ideas and pushing them further and further into the realm of layouts. Of course over that same time period of time others in the community were working on this same problem with panels, display suite context etc. and this groundswell led Dries to start this initiative. Earlier this year after Kris became B+L initiative maintainer I shared some of the more unified blocks and layouts UIs that I had been working on with him. He had some great feedback and ideas but at that point he saw a mountain of plumbing work (basically re-architecting parts of core with concepts from the contrib modules above) that needed to get done before he could even think about UI.
Then came Spark. The primary goal of Spark has always been the content authoring experience we have also tried to push some significant improvements to the site builder experience, notably layouts. Our work so far has produced or improved on a few foundational elements that we can build on like dynamic regions, global breakpoints and grids and our responsive layout builder.
Meanwhile others in this group like chx, jenlampton, attiks and johnalbin have been working on really important stuff like re-architecting the theme layer, integrating twig, trying to solve the responsive images problem, using CSS preprocessors or even possibly pulling in a frontend framework like Twitter bootstrap or foundation.
My goal has been to try to keep an eye on all of these developments and think about how we can bring them together to produce a unified, cohesive site builder workspace. The designs I am showing here are an incomplete version of that but they are beginning to come together into something that can achieve Dries’ goal of end-to-end site building without the necessity* of writing code.
What’s here?
-A single UI that brings together layout, block placement and styling
-Integration with work that has already been done on responsive design
-Integration with responsive layouts (layout)
-A speculative “style” tab showing how contrib might create plugins to this UI that allow users to scope to the building blocks they built their site from and style them.
What’s missing?
-The UI that lists all of the users layouts and lets them sort, filter, perform operations etc.
-The field added to Content types UI that enables the user to select a default layout or create a new one (links to this UI).
-Revisions to the Add/edit content form to allows user to override the default layout, choose a different one, or create a new one (links to this UI).
-Revised dynamic regions list UI with a field that allows users to specify default blocks for each region wherever it appears (not to have this would be a regression)
-And most importantly (and also hardest) a page manager UI that allows users to create landing pages that do not get their URL from a node but may contain any number of nodes plus conditions, arguments, contexts etc. etc.
All of the above are in progress and I’ll be sharing them very soon.
Kris, Bojahn, Gabor, Angie and myself have reviewed this and they all had some great comments which I will be incorporating into the designs. Meantime I am looking for your insights on how we can make this better.
Thanks!
The prototype is here: http://invis.io/7M73WEBZ
Keep in mind it's all static images with image maps. There's no code. Hold the shift key to see the hot zones.
*You’ll always have the option
Comments
This is cool and very
This is cool and very exciting. The UI is clean and easy to grasp. I have a few questions, though.
In the prototype we're editing a layout: front page. Is that a layout called front page or a layout attached to a node called front page ?
It seems like we're assuming that a layout is not just about the placement of the regions by also about the blocks placement in those regions. In D7 we were used to define layouts in page.tpl.php templates. But the layout was just about the regions not the blocks within regions. Is this intended ?
What's the difference between "Add a region" and "Place a region" ? Does it mean I will be able to define new regions using the UI ? Will we have default regions (common to different layouts and different themes)?
What does locking a region do?
It seems like it will be possible to resize and reposition regions through the UI. What does this mean in terms of CSS ? Will we have some sort of Grid framework in place?
I guess some of this questions don't have an answer yet, but I feel it would be useful to understand the whole architecture while developing the UI.
@dodoramaThanks for the
@dodorama
Thanks for the feedback. Answers follow.
"Is that a layout called front page or a layout attached to a node called front page ?"
The layout is called fornt page, it can be re-used on any node or landing page.
"It seems like we're assuming that a layout is not just about the placement of the regions by also about the blocks placement in those regions. In D7 we were used to define layouts in page.tpl.php templates. But the layout was just about the regions not the blocks within regions. Is this intended ?"
Yes, a large part of this initiative is bringing some of this functionality (which already exists in panels) into core.
"What's the difference between "Add a region" and "Place a region" ? Does it mean I will be able to define new regions using the UI ? Will we have default regions (common to different layouts and different themes)?"
Yes, and yes. There will be a list of shared dynamic regions that can be re-used in any layout. In fact Gabor has already created this module.
"What does locking a region do?"
Still up in the air. In panels it locks the blocks but we may want to also lock position and visibility of the region itself (by role).
"It seems like it will be possible to resize and reposition regions through the UI. What does this mean in terms of CSS ? Will we have some sort of Grid framework in place?"
Hopefully. We are working on this along with Attiks and others with breakpoints, breakpoints UI, and gridbuilder modules and we'v made significant progress.
missed one
@dodorama
"What's the difference between "Add a region" and "Place a region" ? "
"add" creates a new region that did not exist before saves it to dynamic regions and places it in this layout. "place" puts an existing dynamic region into this layout.
Looks like a great start! Is
Looks like a great start!
Is it better to leave comments in invision or here?
Quick questions/observations:
great start!
@edward_or
"What is the thinking behind separating the screens for Blocks and Regions?"
The separation creates a simpler cleaner UI. This is a single page, though and the data for both blocks and region layout will be saved together. The tab structure is there only to simplify the users job. Presumably most users will spend their time in the blocks tab and set the layout tab once and forget it.
"On the blocks screen the site logo, site name & site slogan are all in the same region. How are these blocks arranged horizontally as opposed to vertically when on 'tablet' and 'desktop'?"
That's up to the user. I am assuming that the responsive layout functionality we've built in layout module can be made recursive down to the block level.
"Does it make sense to put Styles underneath Layout in the IA?"
Possibly. IA questions are still very much in flux.
great start!
@edward_or
"What is the thinking behind separating the screens for Blocks and Regions?"
The separation creates a simpler cleaner UI. This is a single page, though and the data for both blocks and region layout will be saved together. The tab structure is there only to simplify the users job. Presumably most users will spend their time in the blocks tab and set the layout tab once and forget it.
"On the blocks screen the site logo, site name & site slogan are all in the same region. How are these blocks arranged horizontally as opposed to vertically when on 'tablet' and 'desktop'?"
That's up to the user. I am assuming that the responsive layout functionality we've built in layout module can be made recursive down to the block level.
"Does it make sense to put Styles underneath Layout in the IA?"
Possibly. IA questions are still very much in flux.
The separation creates a
I can definitely see the advantages of splinting them up but it does make the relationship between them a little harder to grok straightaway.
Blocks should be the first tab don't you think? Blocks are definitely the 90% use case for most users as far as I can see.
Also I wonder if there should be some labelling of regions in the Blocks view? When I go to add a block I am presented with a list of regions to place it in but have no indication which region is which. (https://www.evernote.com/shard/s72/sh/5c5ecfac-0159-48fb-a08b-2c3c850100...)
Good point
" Also I wonder if there should be some labelling of regions in the Blocks view? "
I am trying to keep the UI clean and task oriented but you make a good point. Earlier designs had a toggle to show region names in the block tab. I am going to add that back, then at least users have the option.
Also you are not the first to comment on the tab order. That may change as well.
Thanks for the input.
Cool stuff
Really interesting demo.
A few thoughts:
I found myself flipping back and forth between Regions and Blocks quite a bit, as I was trying to understand the relationship between two. It would be good to at least have the region headings on the blocks page, although I wonder if one unified page would make sense. Maybe not.
From my experience with Drupal, I expect blocks added to regions to stack vertically, but it appears some stack horizontally. I assume the handle dragging on blocks has something to do with that.
In the upper right-hand corner, I see smartphone, tablet and standard listed. I have a few concerns with this:
A. I'm not keen on seeing desktops and laptops listed as "standard." By the time Drupal 8 is released, we will almost assuredly see smartphone overtake desktops and laptops in web usage in at least some locations.
B. By listing device types, this seems to encourage device-based media queries. I'm assuming this is for responsive design (I could be wrong about that). Best practices for responsive design are to add new media queries when a design gets awkward-- content-based media queries--rather than using common device sizes, particularly because device sizes can change frequently and can vary quite a bit within categories. I understand that this may be more complicated.
C. I'm also concerned about how regions and blocks can vary between layout types (whether they are content-based or device-based). Ideally, for responsive design, you want to have a logical source order for your content, and then shift the layout of that content as viewports change in width. Somebody on a smartphone should be able to see the same content as somebody on a desktop, just with an easier layout. It would not be great if the layout builder gave site builders the idea that they should be providing entirely different sets of blocks for different layout types.
What I'd really love to see is for a site builder to start with a source order building screen, where they can set the blocks for the site, within appropriate regions. Then those regions and blocks stay the same for the various layouts. What would be great is for the layout builder to be full screen, so that the site builder could change the size of the browser window and determine where to insert a new media query based on the current browser width. They could then shift the layout, alter the relationships of the regions to each other, or the relationships between the blocks in each region. Then continue to increase the size of their browser window until they're ready to insert another breakpoint and make additional shifts.
It's important to note that for responsive images, the breakpoints used for images may be different than those use for content blocks.
Really tricky to find a visual solution that works for this: exciting to see the progress!
Layout module
@mdrummond,
I think we cover (or at least plan to cover) all the comments you make here in layout module. Have a look at the video I made on our vision for that here: http://www.youtube.com/watch?feature=player_embedded&v=Ek2eyWZPI1c
As far as the media queries, you should follow progress on that in this issue http://drupal.org/node/1775302 where your exact question is already being discussed.
Thanks for the input!
That clarifies things
Thanks for sharing the video, Kevin. That definitely helps clarify how this works, and indeed addresses most of my comments.
This could be really, really useful!
That's great to hear, thanks!
Keep an eye on this spot between now and feature freeze. Once we start prototyping and testing I'd love to have people like you with an interest in responsive layout tools be the first to test it.
@tkoleary: last question
Thank you so much for the clarification. I guess the only thing that it's still not clear to me is if the blocks placement is attached to the layout, in terms of configuration. To put it in another way the question is: When I assign a layout to a page, am I assigning the blocks that will appear in that layout, as well?
Looking at the UI, I would say yes cause it seems like layout and blocks are strictly connected.
Not necessarily
"Strictly connected" suggests that the two are inseparable. I would say instead that creating a layout and placing blocks in it is one way of setting the context of blocks. Another way would be put a default block in a region (as D7 does now) while providing a layout the opportunity to selectively override each region's default blocks. What this gives us is both the freedom of a wide variety of layouts and the structure of sitewide regions where repeated elements such as logo, navigation, search form etc. can recur.
What about accessibility?
Hi,
I think this initiative could be a great one, but....
I am really, really, really concerned about its accessibility! In fact, I tested this prototype and, believe me, I was not able to do anything with a screen reader (I am a blind user)...
Is any accessibility-related work planned?
If needed, I can test various updates to give you some suggestions to make this UI more accessible. However, I am not a javascript/JQuery expert!
Not really a "prototype"
@falcon03 I probably should not be using the term "prototype" for this since it's clearly caused some confusion. What I posted is an invision mockup that strings together a bunch of full-screen jpegs with image maps so that (sighted) users can get an idea of how the UI will behave.
There's no actual code there yet so nothing is there for the screen reader to read from. You should know though that accessibility is considered essential in everything we do. When we code this we will make sure that every element and interaction is accessible.
Out of curiosity though, are you aware of, or could you point me to a framework for describing the layout of a two dimensional space to a blind user? It will not be difficult for us give blind users access to labels and fields for values etc. but I don't think that will bring the blind user all the way to internalizing the relationships between the shapes on the page. Any tips would be helpful.
Could this also be shared in
Could this also be shared in the Usability group? A lot more designers follow that group.
I am going to refrain from commenting on the prototype for now, wanna know what others think.
I took the liberty to add
I took the liberty to add this post to a couple more groups for better exposure.
Hey
Thanks Roy. I'd love to hear your opinions as well.
Looks really, really nice. My
Looks really, really nice. My sincere compliments, keep up the good work.
The html and css could be really easy on this to theme. Not in the least by giving the element the same name as in the admin.
For example looking at the youtube video you could have something like this:
<div id="body" class="tablet-layout section" role="main">
<h1>Drupal could be so cool to design in</h1>
<p>Lore ipsum</p>
</div>
<div id="sidebar-b" class="tablet-layout section" role="complementary">
<div id="block-1">
<h2>Block heading</h2>
<ul>
<li class="list-item first-leaf">
<li class="list-item active">
<li class="list-item">
<li class="list-item last-leaf">
</ul>
</div>
<div id="block-2">
<h2>Block heading</h2>
<p>I really like this new layout stuff.</p>
</div>
</div>
Where section could be a set value for the page type. So say for example a vocabulary, or a node-type. Where 'body', 'sidebar-b', 'tablet-layout', and 'section' are dynamic values.
It may need some fine tuning (in naming for example), and you may need some container div's at places. That is just about all you would need, instead of the current code cruft. It would make life so much easier, and cut down on a lot of the div soup and html bloat.
By the way you could also use
By the way you could also use dynamic variable naming in the style sheets. This by having a php file which writes the variable (names) to a style.css file. This way you don't have to worry about names changing. That would need some working out, but it should be possible, without getting in the way of writing custom css code. Of course if you can do everything visually, would there still be a need to do it manually?
Maybe do something like:
#main {
background: #fff;
color: #000; /* Custom Code */
}
or
#sidebar-b {
width: 100px;
height: 200px;
/* d-s */
background: #fff;
color: #000;
/* d-e */
And if it has 'custom code' tag (or shorthand for example) then the admin editor would not change the color, or give a message that that color has been set manually. More a feature for advanced users, while people that want a visual layout experience can still do that.
Or have a php file which has the custom.css. For me as a designer it doesn't matter if I'm writing values in a file with the .php extension or with a .css extension. It would be easiest for me, from a design point, if I could just write the css as I always do. The .css is also extremely handy to have for tools such as Firebug. But if I can just save the PHP file, and refresh the screen and have acces to the css file in the browser for example then it's all good (for example in build mode). It would be nice if the names of the elements would be changed automatically with the backend. It beats having to add shorthand tags everywhere in the file. What the backend editor could do is check to see if there is code in the custom.css, and not write those values to the style.css. This way you would save space, improving rendering speed. As everything is being written to .css files, the overhead would only be there when generating the css-files, which could be done with a 'generate css' button in the admin screen. Once the css design has been done, then it would just read from the flat css files.
Like I said it should be doable.
Great ideas
Work in the styles tab is something that I expect will be done mostly in contrib for D8 and it seems likeley that there will be several competing approaches to how that works. Your idea of setting variables via php is one. Others have suggested using CSS preprocessors like sass, susy or less. For me it does not really matter as long as the designer begins to have the ability to have more granular control over styling right in the CMS without being forced to write tpl.php files.
For me the important bit is
For me the important bit is this:
Should be able to manipulate the data coming out from the database, and at an (application) design level to easily work with the output, and style that relative easily.
If that is what you mean with granular control, then you have my vote.
Even some kind of token block where we could just add the elements (globally) around something, would be super. I end up doing this in views now. tpl.php files aren't that hard. It's the template.php way of working that is killing I find.
I can't work with template.php stuff, and theming as it is. I spend most of my time piling through arrays and div soup. Learning curve is one thing, but it is just time consuming.
If Drupal can spit out beatiful HTML layouts, wonderful, otherwise please don't. The stuff it prints now makes it so hard to design for.
HTML and CSS have code rules just like PHP. Theming right now is way to time consuming. Also I don't see this whole Twig thing at all. Why have to learn another template language just to use Twig? Why not have functions that do simple tasks for example? You could hook these into blocks, where you could put elements around them. Like views does. It would be nice to be able to use templates for that. This way you wouldn't have to redefine the html per block. It would align with what you stated about releaving designers having to write in the tpl.php. I can only speak for myself, but that would make my life easier.
I like how the system your proposing allows for sections. I'm finding that it can be pretty difficult to assign blocks to different parameters, without resorting to all sorts of coding. The proposed way could make it a lot easier.
I hope all this will lead to a pleasant design experience.
Because as it stands now, I'm interested to see how Drupal will develop in the future, but I'm having a really tough time figuring out where Drupal is headed, and how that will affect me making and using a website easy. I'm ready to ditch Drupal 7 at the moment, because it is just difficult to design in. Getting frustrated beyond belief, at how this system works. And that is a shame, because Drupal 7 in many ways is a beautiful product, and a huge improvement over 6. But to tell you the truth besides the admin, I miss a lot of things about 6. Designing in 6 seemed easier somehow.
Anyway, keep up the good work. :-)
Great stuff guys.
Looking forward to seeing more and helping somehow, some time.
Q.
Revised designs
Many long hours of discussion leading up to and at BAD camp led to the revised design here http://invis.io/ZV8H8BA4
Bojhan reviewed this at the last BAD camp sprint yesterday and summarized the comments of those there. Those comments and my replies are pasted below:
Overall flow
We looked into three usecases reviewing this flow, 1) Creating a content page (blog), 2) Create a single landing page, 3) Create a dynamic page (node/article/%). The first two are clearly represented in your design and we only encountered a few issues around that, the third one is however one we still need more thought behind.
When you land on content, it should probably go to the content listing. Right now you go to "Landing pages", we assumed this wasn't intentional just part of invision.
The current grouping of pages is focused around Content, Landing and System pages. We are not sure if "System" captures what our site-building audience needs, does this capture node/article/% or links like node/article/%/edit or admin/%. While the last two are administrative pages - the first isn't. We envisioned a better solution would be to capture all the pages with arguments under "Dynamic pages", this would be where all site builders go to make pages that map to a dynamic URL/condition - and administrative pages would simply go under a subtab on that page called System. This also allows sitebuilders to learn about existing patterns, around taxonomy, content, users and with that teaching them how to use it. This is reflected in attached designs; contentpages.png and dynamicpages.png.
You land on the "Master template" and that default seemed a bit odd to us. The "Master template" is the page on which you customize the layout and its regions for your default. This however is not a common thing to customize, this is something you do once and then rarely revisit. The most common usecase, is setting up a new layout + populating that layout - so in this case Templates listing should be the default tab.
You land on the "Master Layout", which is the current admin/blocks - in the sense that you configure the default blocks for everything (and probably not the content area). Although arguably less odd, it also doesn't seem like the 80% case because this is kind of a configure once and then rarely touch it again thing. This initiative is largely about promoting the behavior that you want to place a block on a specific page(s). While you obviously still will edit the master, its a far less common scenario than in previous Drupal versions.
The flow between pages, templates and layouts was often hard to follow for us in the discussion. So it will be important to clearly connect the dots here, as you move between two interfaces (something that was far closer together in previous concepts). But also likely caused by new terminology in each discussion, heh :)
Once you create a landing page you are now taken to the landing page listing. I wonder if that was intentional, because the most common usecase for landing pages doesn't seem to be just going with the template but instead going with a template, and then adding a number of blocks. Since the audience and intend of those using landing pages, is largely about creating a one-off with a few special block configurations.
Adding a layout, with blocks that require a context
See diagram page-creation-workflow.png
There is a missing piece, which is context configuration and this has an impact all over this UI. For example when you place a template which has blocks that require context configuration. There is currently no way, to handle that or inform about that. This is a separate thing from conditions. When you place a layout which is populated with blocks that require context configuration (PBRCC :D), you need to map that to where its coming from, 80% case is the URL.
This disconnect occurs in both placing landing pages and placing dynamic pages, in landing pages we can opt for just allowing you to set the context configuration (e.g. just saying the context is node/1).
We will need both workflows and widgets to accommodate this complexity, we discussed at length 80% site builder task that we need to support. The detailed design of this could be post feature-freeze material.
Interaction details
Distinction between "Master", "Layout", "Page Blocks"
The current way to distinguish between the different types of blocks is a little confusing. The colors are very prominent, and the important blocks kind of get lost in the sea of visual signals. E.g. on creating a layout, the "Master" blocks are not very important, and on editing "Article" blocks - the "Master" and "Layout" are not important.
The "Add block" interface is similar to what you previously had. Which most likely won't work, because it focuses on finding what you know. This most likely needs to be a modal dialog of some kind, that allows you to browse block and or add new ones.
Other discussion topics
In general, based on how far the current API fundamentals are this is still too ambitious (having spoken to a lot of people here). I would aim to really MVP MVP MVP this :) because that will help Gabor and Jesse to actually get going, on the UI's they need to make in the next 3 weeks and then we can further iterate on what we want before feature freeze.
Me;
This all makes sense. I will start revising the design right away and re post. Quick answers to your main points follow.
1 Dynamic pages.
This all makes sense and should be easy to work in (basically as you designed)
Jeff made the same comment suggesting that the master template and the master layout be in the same UI but just given another kind of affordance. I will implement this.
Good point. I will change the default save action on landing pages to "save and add blocks"
This seems like it should be a modal in the layouts UI under "add blocks". The flow would be: I add a block to my layout, the block requires a context, a modal appears that says "this block requires a context", a widget in the modal exposes the necessary controls to provide the context, the user chooses the context options, the user submits the modal and returns to the "add layout UI"
If possible I would like to add another layer of disclosure to this so that we don't throw up too many obstacles. That would involve two things 1) the "dynamic blocks creation" UI contains controls to add a default context to a dynamic block. and 2) The modal in the layouts UI is a two part form. The first part says "this block requires a context" and provides radios "Use default context" and "Add a new context". Clicking "Add a new context" expands the add context widget.
In order to get this designed I need information from the group on what features a "Dynamic block creation UI" might contain.
I will revise this UI to be clearer and more compact but there are a couple of things I should clarify about the design.
The new blocks design was done in response to issues that already surfaced with the older design where the distinction between regions and blocks was unclear. I think those issues are resolved in this design.
The Blocks should remain constant in appearance (size and color) form UI to UI (Master layout, Layout, Page layout) so that there is no confusion when the user is presented with the same information in a new UI.
The color palette has been carefully crafted to be completely accessible. It passes WCAG 2 level AA and differentiates well for all eight types of color blindness.
6. Add a block
Yes. I had already planned to include a modal. That's the behavior when the user clicks "show all blocks at the bottom of the dropdown. I will add it to the design.
MMVP design updated
Here http://invis.io/VG8S2HR8
Please comment here not in the prototype.
Thx
Quick review
A few questions,
Placing a block, there seems to be two actions. I don't fully understand the "Duplicate" option, although I understand the technical concept I was under the impression we do not show them this and instead just use "Place".
The "Master" template for non-admin pages, is visually very prominent when you are adding a landing page. Do we get away with decreasing this visually, to a gray? Especially once you go beyond just master templates, we need to promote the idea of not adjusting that template, because that will effect other pages.
I like a lot that you mapped it to our current IA, that helps Gabor implement it for now. I am a little worried about Layouts being in Content though, I imagine that is a "site builder" task and should be in "Structure", for now.
Could you expand on what you think should be in the content category on "adding a block"?
IA
Yeah, so looks like a key change is that nothing is under Appearance anymore and everything is under Content?! That will hopefully not stay as-is in the future.