It seems like this module's purpose is very similar to both It would be helpful to potential users if you could clarify the difference, between Display Suite and these modules, probably on the project page. Thanks!


swentel’s picture

Well, it actually has no connection with context whatsoever. It didn't have any connection or similarity with panels in the beginning, but now some things seem to overlap, however, I have no real experience with panels, but I'll ask some more experienced users for a good explanation between both - if any :)

ManyNancy’s picture

I actually think there's almost complete overlap with panels in terms of its node display features.

But here's why I'm using display suite:

1. With panels you can create node regions in any configuration through the UI, display suite starts you off with 5 regions, good enough for me. With panels you need to create those 5 regions on your own if you want to be able to alter sizes... That's too much clicking. DS wins out with convention over configuration.
2. I find the CSS altering features in DS to be much easier to deal with through the UI than with Panels. Panels can also assign CSS, but it just takes too many clicks to get to.
3. Panels UI is sluggish.
4. The drag and drop features of the DS admin UI is much much preferable to the add one by one method panels uses to assign blocks. Adding 10 blocks for each page in panels is extremely annoying, and extremely easy in DS.
5. The HTML that panels render is extremely bloated.
6. DS has build modes, which can produce different versions of the display for different situations, ie, full node, teaser, search. Can panels do the same? I can't remember/I don't think so. If it can it's hidden somewhere unintuitively deep in the UI and I haven't noticed.

I don't actually think there's much feature difference between the two, but working with the DS UI doesn't test my patience like it does with panels.

I'm sorry if I missed anything important.

There's however one huge glaring weakness for DS. No fieldgroup/multigroup support. I really really hope that's coming soon. Please oh god.

swentel’s picture

Status: Active » Fixed

Sounds good enough for me, I'll let people add more in here if preferable and I'll make a nice diff later on the bookpage, thx for the add Many! As for fieldgroups, we're working on it, see #582618: Incompatible with fieldgroups

GlossyIbis’s picture

Status: Fixed » Active

I am relatively new to both, but as a designer as well as a coder I would surmise :-
(as of DS/ND 6.x-1.0, Panels 6.x-3.3, February 18th 2010)

  1. A huge difference, for me at least, is that DS/ND does not affect data-entry. For many sites, how good (aka professional) data-entry forms look is just as important as how the data is displayed. eCommerce websites are a particular case in point. Moreover, often it is more intuitive for users if the node display is the same as the node data-capture form - i.e. just a read-only version of it. Because DS/ND only focuses on display, web designers have two forms to think about and work on.
  2. Panels give a huge level of layout control and localised or globalised CSS styling.
  3. Panels offer a level of re-useability in the form of mini-panels - which can be embedded in any number of panels - this is useful also for branding.
  4. As ManyNancy pointed out, DS/ND does not support field-groups or multi-groups - a must for any serious website capturing data from users without wanting unwieldy long pages.
  5. Panels is heavier in terms of your effort required to achieve the required result. That is to say, there is a steeper and steepish learning curve, and more options means more decisions - aka mouse-clicks.
  6. Panels is heavier in terms of CSS (aka browser load) and server load (page rendering).
  7. DS/ND is quicker to implement a much smaller set of data display-only layouts.
  8. Panels is a superset of DS/ND.
  9. There is one big caveat: you may be lucky and find DS/ND does what you want, and quickly. On the other hand you may realise that you cannot achieve what you want to achieve, scrap all your work with it, and switch to Panels...

I hope this is a fair assessment.

ManyNancy’s picture

There is one big caveat: you may be lucky and find DS/ND does what you want, and quickly. On the other hand you may realise that you cannot achieve what you want to achieve, scrap all your work with it, and switch to Panels...

I would say this is ridiculous with one caveat... There's no reason you can't use panels and DS together. DS doesn't have a good handle on profiles, I use Panels. It doesn't do node edits, I use form manager. Big deal. It does Node displays better than panels, which is very meaningful for me.

Now for the caveat. Fieldgroups is obviously a huge problem and despite all the time i've already spent with ND I might have to dump it because of the lack of fieldgroup support.When I first started I honestly thought I could figure it out myself. But with absolutely no sense of timing for when fieldgroup support is coming working with DS might just be impossible.

GlossyIbis’s picture

Did I read that right? It seems a little inconsistent to say something is ridiculous, and then assert that you might do the very thing you ridiculed?!

It also seems strange to suggest that Panels is very complex and DS/NS is quick and easy, and later suggest you can use both together. I am not entirely sure if this is possible, but irrespective of the technical possibility - wouldn't this be making the task of form/page layout, and which tool/s to use - even more complex?

My own experience with Drupal is that mixing modules is fraught with difficulties, much wasted time, and more often than not, I end up backing things out. I suggest using as few modules as possible, and, unless one module has been specifically designed to work with another - don't mix.

For my own part, most of the time I use neither Panels nor DS/ND: I use blocks and native, unadulterated, nodes, and do standard CRUD operations on them.

As far as the ever elusive field-groups is concerned - where I want all the fields in the group to appear on the same line, bunched together with a little gap between them - I use CCK Multi-groups (6.x-3+). CCK Multi-groups (6.x-3+) is great but it doesn't seem to work with anonymous users. So it cannot be used for registration forms. For this usecase I use simple field-groups with CSS. It would be great to have the option in fieldgroups to have all the fields appear on the same line without dipping into CSS (like the multi-column option in multi-groups)...

swentel’s picture

Status: Active » Fixed

Ok guys, I created a book page here: where I created a summary of thoughs. If you have more additions, please take it there and add comments. I'll merge them in the page afterwards.

swentel’s picture

Status: Fixed » Closed (fixed)

marking as closed