UPDATE: Really good discussion http://drupal.org/node/948066

Posting this here whilst I get my head round stuff. I'm just going to write all thoughts down in one place. If we go with this I might try and see if we can take over this abandoned project. Here I'm trying to summarise my current research on the whole Drupal community's approach to draggble blocks.

What we're after

We want to be able to give an end-user the ability to nicely move blocks around the page and add to it. The end user has lots of events which will be a node content type. The events will have loads of different information attached to it. Speakers, Programmes, Promotional videos, images, terms and conditions, etc. These will probably all be displayed via views.

What I would like is for the end-user to be able to click "Edit layout of page" or something and move the blocks around. These blocks would only move around for that one event page and they would go into a default location for the first time when the event is created.

We'd also give them the ability to add custom blocks. They'd drag them into some area and an overlay would pop up allowing them to edit this empty block. These custom blocks really should be using Fields and so different types of custom blocks could be created (Images, videos, etc) all with the nice UI stuff that fields brings (like Media).

When clicking "Edit Layout of the page" we only want the end-user to see the blocks that are relevant to that particular page, depending on their role.

Where in Drupal is this already done?

Panels - Panels has an awesome "in-place panels editor" that allows people to click "Customise this page" and then drag and drop stuff. However the "add content" dialogue box was brilliant for when it was built but its D7 stuff isn't quite there. The dialogue box itself causes javascript issues with wysiwyg. For end users it starts getting complicated knowing the difference between panes, custom panes, reusable custom panes, custom blocks, mini-panels etc. Finally I don't know how easy it is to edit the "Add content" dialogue block to make it context sensitive such that you only see the relevant stuff.

OpenAtrium - Context, Spaces, Boxes - The Spaces Dashboard on Open Atrium is really nice. There is a brilliant screencast here.. The only issue is this is very much Drupal 6 and complicated. Do we learn this paradigm and work on porting it to Drupal 7? For example whilst boxes are better then boxes really they should be fielded and probably should be entities. There is work to do this kind of stuff so there might be mileage here and anyway, its likely that some things we need will require contexts or spaces (such as blocks only being shown depending on which page you're editing)

SubHub - www.subhub.com - These guys have a UI aimed completely at end-users. They have wrapped the core drupal 7 blocks module and built their own java script draggable UI thingy. You drag an "App" from a "select apps thingy". The "select apps thingy" also allows you to filter by your own apps you've created. An app includes for example custom text.

What is the ideal solution? - WSSCCI

I think for Drupal as a whole the ideal solution is simply the Web Services and Context Core Iniative's Phase 4. These guys will overhaul blocks and everything from the ground up and then eventually allow people to do layouts well. They are a core iniative so obviously have huge community traction, they are planning to back-port some stuff to Drupal 7 through modules and they have people like the panels team joining in the discussion.

However these guys will take 2 years, and it may be 3 years before contrib catches up with Drupal 8. So we can't use this stuff now.

Why create a whole new module for this? Why not work with others?

Well the draggable bit is probably not going to be complicated. I've been told that we can use jquery to do this quite easily as long as there is a method of defining draggable regions which shouldn't be too complicated.

Also we could work with those other modules such as panels or contexts. But they are large beasts that are also working towards the holy grail of WSSCI. So its not likely that panels will be super-user friendly for end users in 2 months time even if we got involved. Besides in doing "Draggable blocks" the problem is not the draggable but its the Blocks.

What is it we plan on dragging?

The main thing we need to decide is what we want to drag. It can't be purely core drupal blocks as they are not flexible enough to for example, appear in different regions of different pages. They also don't use fields. Here are the alternatives and the first question I want to answer is what we plan on dragging.

http://drupal.org/project/panels - They have Panes, Custom Panes, Reusable Custom Panes
http://drupal.org/project/boxes - Fits in with the Contexts, Spaces ecosystem. Worked well in D6
http://drupal.org/project/block - Block 2.0, last modified May 2011. Has no Code. Issues compare it to other solutions
http://drupal.org/project/block_api - Has the best namespace. Work started on Drupal6 though so I don't know how much of drupal 7 it takes advantage of.
http://drupal.org/sandbox/fabsor/1158058 - Entity Block. Yet another implentation of blocks! This has merged with Beans
http://drupal.org/project/bean - Beans are block entities and therefore fieldable. Has has the most amount of development work on it and sponsered by some agencies. Has a name that makes it look like a block alternative rather then replacement.
http://drupal.org/project/brick - Another group of people doing blocks. These integrate with Context and Panels better but are still in development.

Things I'd like:

- A Block replacement. Therefore it should do literally everything you'd expect a block to do and more. Drupal should barely see this as any differently to a block and therefore any modules that use blocks should use this. For example contextual links should "just work". (This I think rules out panes as only panels can use panes).
- Not a block alternative - Similar to the first point, but once we have these blocks we should never need to use core drupal blocks at all.
- Should be entities - This means we can use fields and all modules that work with fields. I think this rules out boxes as they currently stand.
- Upgrade path - I should be able to move all my core drupal blocks into this module
- Fitting in with the overall community - This is only temporary. Whatever direction this block stuff goes should eventually fit in with WSSCI

Will start writing up which one of these alternatives to pick.

Comments

yautja_cetanu’s picture

yautja_cetanu commented
Issue summary: View changes

Added Entity Blocks

rupertj’s picture

rupertj commented

Our system at SubHub works like this:

We have a module that provides all the blocks our users can place, which they do so by dragging them to where they want them. There's no access to the normal blocks admin page. Our module has hooks for other modules to register block types, in a similar way to bean/block_api and can store an array of settings per block. What I've been hoping to do for a while is replace our module with one of these other modules. (They didn't exist back when we started developing our platform, and by now should be better than ours, I'd imagine.) Then, reimplement the JS for draggability on top of whatever we choose. So, my proposal would be:

1) Make a choice on which base block replacement module we prefer.
2) Make another module that builds on that for drag functionality. (I can provide some of our code as a starting point for this.)
3) Hook it all together :)

rupertj’s picture

rupertj commented
Issue summary: View changes

Added a discussion

yautja_cetanu’s picture

yautja_cetanu commented

Long conversation with the guy who made beans.

Important Summary:

- Beans take an object approach
- Block_api takes a procedure approach
- Beans can appear at different places on different pages with a different ctype.
- Beans are not context sensitive (like panes in panels). May need Panels everywhere.

[02:30.06] * fmitchell (~fmitchell@c-67-175-29-236.hsd1.il.comcast.net) has joined channel #drupal-beans
[02:30.22] <Yautja_cetanu> Just wondering if you know of somewhere where I can read about the differences between beans and boxes?
[02:30.44] <indytechcook> Yautja_cetanu: they are very similar.  beans are entity based
[02:30.47] <Yautja_cetanu> I'm just reading through your issues now
[02:31.12] <Yautja_cetanu> ok cool, I noticed that Entity boxes has no code yet... I'm guessing that when entity boxes exist they will be really similar?
[02:31.14] <indytechcook> plus they are separated out a little more
[02:31.27] <indytechcook> i don't know anything about entity boxes
[02:31.55] <indytechcook> block_api and bean are similar
[02:32.00] <indytechcook> bean takes there objects approach
[02:32.05] <indytechcook> block_api takes the procedure
[02:32.20] <indytechcook> every bean type is an instance of a ctools plugin
[02:32.21] <Yautja_cetanu> ok interesting
[02:32.51] <indytechcook> http://drupal.org/sandbox/fabsor/1158058 is no longer used
[02:32.56] <indytechcook> fabsor joined me in beans
[02:33.06] <Yautja_cetanu> Do you know if anyone has tried to make an end-user draggable system for beans?
[02:33.08] <Yautja_cetanu> yeah I saw that
[02:33.13] <indytechcook> not yet
[02:33.23] <indytechcook> beans just create the blocks
[02:33.27] <Yautja_cetanu> Cool, do you mind me copying this IRC conversation into my issue?
[02:33.31] <indytechcook> np
[02:33.49] <indytechcook> we didn't try to solve the problem of block placement
[02:34.13] <Yautja_cetanu> ok, is there reasoning behind that?
[02:34.18] <indytechcook> for energy.gov we used the block_reference behind it
[02:34.25] <Yautja_cetanu> or is it just time?
[02:34.27] <indytechcook> they are very different issues
[02:34.34] <indytechcook> we needed instances of block types
[02:34.40] <indytechcook> to replace views blocks
[02:34.52] <indytechcook> make them configurable by end users, not site builders
[02:35.10] <indytechcook> for block placement on landing pages, we used different ctypes
[02:35.18] <indytechcook> 1 column, 2 column, 3 column
[02:35.36] <indytechcook> and used the block reference module with a custom autocomplete callback to filter the results per user
[02:35.42] <indytechcook> with integration with OG
[02:36.21] <Yautja_cetanu> ok, so by using different ctyle the same bean can appear in different places on different places is that right?
[02:36.31] <Yautja_cetanu> *ctype not ctyle
[02:36.37] <indytechcook> correct
[02:37.03] <indytechcook> the users don't' tend to reuse the beans
[02:37.07] <indytechcook> they tend to make new ones
[02:37.32] <Yautja_cetanu> Also I read some issues about making beans a "drop in replacement" of blocks does that work? have you got it to a palce where you don't really need blocks anymore?
[02:37.57] <indytechcook> not blocks but the custom blocks
[02:38.02] <Yautja_cetanu> ok
[02:38.05] <indytechcook> and we pretty much are now
[02:38.12] <indytechcook> just need to do the alters of the menus
[02:38.27] <indytechcook> i've been working with sun on how we are going to get block entities into core
[02:38.32] <indytechcook> to replace custom blocks
and i've made good progress
[02:38.46] <indytechcook> http://treehouseagency.com/blog/neil-hastings/2011/09/21/building-custom-block-entities-beans
[02:38.48] <Yautja_cetanu> also your "view" beans. Are they context sensitive? so they can recieve arguments from other places on the page like they are when I use views in panels?
[02:38.50] <indytechcook> that is our primary use case
[02:39.19] <indytechcook> not right now
[02:39.29] <indytechcook> we have talked about it but there is no good way of doing it
[02:39.37] <indytechcook> hook_block_view doesn't give me any contextual information
[02:39.41] <indytechcook> but hook_block_view_alter does
[02:40.12] <indytechcook> i actually started working on rendering the bean in hook_block_view_alter instead but we came to the conclusion that's out of scope of what bean does
[02:40.16] <Yautja_cetanu> hmmm ok, but you've made beans integrate with panels right (I saw block entitiy did). So I could use panels to manage the layout. Beans for the custom stuff and view_panes for stuff thatneeds contextual information?
[02:40.17] <indytechcook> bean is just block creation
[02:40.19] <indytechcook> not placement
[02:40.56] <indytechcook> you could use panels, we didn't\
[02:40.58] <indytechcook> it's a block
[02:41.14] <indytechcook> http://drupal.org/project/brick is new
[02:41.25] <indytechcook> and is more tightly integrated with panels
[02:41.49] <Yautja_cetanu> ah lol, there are so many block replacements, hadn't seen that one
[02:41.53] <indytechcook> yeah, tha'ts new
[02:42.11] <indytechcook> he is trying to solve to many problems with that module IMO
[02:42.35] <indytechcook> page manager is not something our normal end user would be able to use
[02:42.40] <Yautja_cetanu> Its difficult cause I think that this problem will be fully sovled with Drupal 8 and the WSSC Iniative...
[02:42.42] <Yautja_cetanu> yeah I agree
[02:42.48] <indytechcook> if even then
[02:42.53] <Yautja_cetanu> yeah
[02:43.22] <indytechcook> integrating with ctools context isn't a bad idea
[02:43.33] <indytechcook> not sure now to implement it though
[02:44.04] <Yautja_cetanu> You said you talked about having context sensitive beans, is there an issue for that conversation?
[02:44.31] <indytechcook> no, it was something a team mate and i were working on
[02:44.41] <indytechcook> it got really harry
[02:47.06] <Yautja_cetanu> cooll thanks for your help!
[02:47.09] <indytechcook> np
[02:47.23] <indytechcook> i'm really open to new ideas
[02:47.39] <indytechcook> and excited to see a better placement :)
yautja_cetanu’s picture

yautja_cetanu commented
Issue summary: View changes

Added bricks

hatuhay’s picture

hatuhay commented
Status: Active » Closed (won't fix)