I'm in the middle of trying to figure out the right experience for installing and using Acquia's hosted search platform. In doing so, I had to think about how to build pages that were Solr enabled. In parallel, I've been thinking about a better way work with blocks. The two topics were fairly connected, so I started working on some concepts.
In D6, to configure the display of pages, you have to configure blocks (sitebuilding > blocks > configure > Show block on specific pages). This feels backwards. To solve this, I'm allowing users to configure block templates - which can then be assigned to pages. For now, in the screencast, I'm sticking with the nomenclature of "blocks" so that I can better contain my solution, but eventually I think we'd want to call this "Layout Templates". That said, you'd first create a layout template, then when creating a page, you would then assign a layout template.
Thoughts?
http://www.jeffnoyes.com/content/drupal-7-usability-improvements-part-ii...
Comments
I like
Couple of things I noticed.
We'd probably want to keep something like the current path-based mapping of templates - so
default template
'template a' shows on node/*
'template b' shows on search*
'template f' shows on node/1, node/10 and node/40 (and has a higher weight than 'template a' so it overrides)
Could still allow php overrides - so you can do templates by node type or user role, and leave role and php visibility for individual blocks too.
Doing it that way would let us put that blocks fieldset on the node creation form from the mockup still, but it'd be a specific way of affecting these settings.
If we know in advance which regions and blocks are going to be loaded on any one page view, then we could probably get a fair bit of optimisation out of it too.
Nice work!
edit: this would also answer this feature request - http://drupal.org/node/334608
Stunning
What a wonderful set of comps. I am sold. I honestly do not think that we would need to allow 'template a' to show on node/* ... I think that selecting the default block template on a per-content type basis is the better way to go. Each block would still have the configuration options to allow visibility based on path (or php code), but I dont think that we would need that fine-grained control over selection of a block template.
On a more upbeat note: yes, yes yes. This is awesome.
I do worry about how the structure of that page would be built. We might have to add a requirement for themes to somehow build that page.
This post should probably be added to the Usability Group: http://groups.drupal.org/usability- moved--
-- matt tucker
pingVision
--
-- matt tucker
This sounds, ultimately,
This sounds, ultimately, like something I've been targeting with Panels for a long time. You've got the layout engine and placement right there, and that part is reasonably abstracted out. Even moreso in the upcoming stuff I'm churning through.
I've got a rough draft of a panels design too.
I'll post it within 2 weeks.
context_ui
You can already make a different block settings per page (or any other context) with the context_ui module.
we need a better solution for core though
Drupal's ease of use shouldn't be dependent on modules.
Well said
For Drupal to get to the next big step, these 2 main issues need to be solved, acessibility and ease of use. (or they are same issue?)
Adding modules to give such basic requirements is a pain and not the apprpriate goal.
Although it would make good sense having that through Panels 3, one concern that Michele raised here http://groups.drupal.org/node/15854#comment-56998 still stands.
Dealing with Callbacks in Context
You might be interested in http://drupal4hu.com/node/173 and http://dc2009.drupalcon.org/session/future-callbacks
Matt Farina
www.innovatingtomorrow.net
www.geeksandgod.com
www.superaveragepodcast.com
www.mattfarina.com
Merging Blocks and Mini Panels
Would it be possible to
1) have every Panel "item" be a Mini Panel (and thus re-useable and placeable in more than one instance at a time)
2) replace the Drupal Blocks system with these Mini Panels, which could then be used within the Panels environment as now but also be available to be used in the old Blocks way (they would be much more configurable than Blocks are currently), or we just eliminate Blocks and work exclusively and entirely with Panels and Mini Panels. The term for these could be "Mini Panels" or "Panel Items" or "Blocks." I think I vote for "Panel Items." "Blocks" is shortest to type and makes sense but might confuse some people at first since the old "Blocks" would still be out there in use for some time.
3) Eliminate some of the redundancies in specifying how and how many view items get displayed: currently options can be selected in both the View UI and in the Panels UI. The objects that Views UI generates could be Mini Panels. Or some of the functionality of Views UI could be pulled out and put into/found only in Mini Panels UI. I think we would only want to do this if we were going to have Mini Panels (and Panels) not only in core but as the one and only way of displaying Views.
Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org
CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.
Drag'n Drop Blocks
Hello,
I'm currently working for a company who wants to improve block's administration page. The goals is to makes blocks draggable and allow user to have a preview of the final page. They tested panels but it didn't respond to their needs. Currently, I work on a prototype that using jquery UI
I would like to know if it's a common asked feature and if a project exists?
check with Gabor Hojtsy
check with Gabor Hojtsy
for simplicity and ease of understanding
If we take it apart all the way to the core and just redo the idea of what is a site using common nomenclature.
Site consists of Pages with varying Layouts.
A Layout is the pattern of Regions: header(s), sidebar(s), footer(s), column(s), menu(s), etc.
A Regions can contain Content of different types (stories, blocks, rss feeds, blogs, code, etc.).
so
Site > Page > Region > Content
Those are all simple words that most everyone understands.
You create Content and assign it to a Region on a Page.
If Drupal could understand that, I could upload to Drupal ANY CSS and xhtml Layout, it would recognize the Regions much as firefox/firebug do, and allow me to assign the created Content to the Region on the Page. Perhaps even with drag and drop simplicity.
Templates and themes become a breeze. Sky is the limit.