Collapsible paragraphs in node edit form

I think this is a great idea! However, when a paragraph is collapsed I'll want to know what bundle type it is and have an indication of what content it contains. That last part might be a little tricky. For each bundle type, the site builder would need to specify a key field to be shown when the field is collapsed. Text fields could be displayed as is. Long text fields could be trimmed to a handful of words. For entity reference fields, you could display the title if the entity. For images, you could let users pick an image style to use for the preview. The biggest problem I see is just that there are a lot of field types that could potentially be selected here. There would need to be a default way of dealing with unknown, or otherwise not yet supported field types.

What about using a view mode for that?

Hmmm. View mode is an interesting idea, but my gut says that it would add more complexity than most site builders will want to deal with. If implemented that way then Paragraphs will need to automatically create its own view mode. Even then, I don't think things like trimmed text fields would be easily implemented, unless Paragraphs provided some custom formatters or something. Still worth considering though.

Adding a view mode is really no problem. And trimmed text field formatters already exist. I don't really see the problem there.

Only issue would be that the default view mode will get selected if site builders don't customize our view mode. And indeed the extra work for them. But this whole functionality could just be a settings in the instance settings.

+1
I'd love to have collapsible paragraphs, especially with fields containing paragraphs containing paragraphs...

And by the way, if you could add some more div or span containers with dedicated classes around the paragraphs labels this would make it really easier to theme and alter for integrators.

Keep the nice work.

We're having a code sprint for Paragraphs soon.
I think this will be functionality that we will be implementing in that sprint.
I'll let you guys know when I'm sure. Any ideas on the UX?

@regilero, you mean the backend styling? I could add a extra container/class to the paragraph label if that's something you would like.

The more I use Paragraphs, the more important this has become, so I'm glad to hear it's being implemented. As a preemptive note of caution, please consider the use of nested paragraphs when coding this. Anything that collapses/expands paragraphs should be restricted to acting on paragraphs on its same level. Expanding the display of a nested paragraphs field should never expand its parent paragraphs field, or any other paragraphs fields on the node.

As for UI, I'd put a disclosure triangle at the top of each paragraph item, next to the "Paragraph type: xxx" text. Then above the draggable table, where the "Show row weights" link is, I would add links to expand/collapse all paragraphs.

There should be an option in the field settings for each paragraphs field to set the default state when editing existing content, or to disable the feature all together on that field, but when a new item is added it should always default to the open state. It also could be interesting to have the option to keep only one paragraph open at a time, so opening one would automatically close the last one you were working on. However, I haven't really thought that through all the way, so I definitely wouldn't make that the default behavior and at best it is a nice-to-have.

A 'key' field (or key fields) could also solve the discussion in other issues about the administrative title.

Something like an 'administrative view mode'? (Ajaxified ofcourse :))

@jeroen.b, yes, in the administrative UI I think paragraphs lacks some div and markup separators between elements (and classes on theses things). This could be used to tweak the administrative UI in administrative themes.

Could we have a first version using just a simple collapsible area leaving the block type visible then start to build a complete solution with a view mode or whatever in a second time ?

Hi everybody,

I just found this project on Github - are you aware of it and does it solve the issue as required?

Cheers,
Daniel

Ok, I tried paragraphs_extra and it has a major issue. There's no key field to be defined so collapsed items only show up with their bundle name and you can't distinguish one from another

This issue is still on the roadmap, sadly I don't really have much time to work on this.
I'll work on this as soon as possible, but I rather fix the multilang/revision/migration issues first.

@regilero, I added some more containers.

@the others, I made a start on this, it might need some more features (open all, able to collapse after press on edit), but it's ready for testing.

I added a option to the "Default edit mode" in the widget: "Preview". It works the same as "Closed", but it will render the paragraph item in the view mode "Paragraphs Editor Preview" until you press the edit button.

@jeren.b, thanks, I'll test that soon, pretty busy as well :-)

I've been updating our site to use the latest beta, with this feature, and it already seems very helpful, but the UX definitely needs more refinement. Much of this you already know, but here's my take.

Mostly, it's very frustrating that you can't collapse a paragraph once you've opened it. Also, higher level expand all and collapse all links seem like they would be helpful.

At first I was thinking you should just include a disclosure triangle with each paragraph, associated with the bundle type label. However I noticed there's a lot of real estate being taken up by those buttons under each paragraph item. That led me to think a better approach might be to include a drop-button in the top-right corner of each paragraph item. If you're unfamiliar with drop-buttons, they are a newer entrant in the UI world, but gaining popularity. Notably you'll find them in the Views interface.

In this case, the default item in the drop-button would be either "edit," or "close." Clicking on the arrow would reveal a "delete" option. I think this might provide the best balance of functionality and usability.

Good idea! I'll do some testing with that soon.
About the closing of items after you opened them. It's kind of hard to decide what happens with the item at that point. Will the changes that somebody made in the paragraph item saved or will the paragraph item be restored to what it was?

Hmm. Good point.

Personally I think closing an item should retain any changes made to that item. That's what I would expect to happen, as a user. I should be able to open and close paragraphs items at will while editing a node, so I can just concentrate on one piece at a time. Of course the preview display would need to update to reflect those changes, which I suppose might be a little tricky. And I don't think the paragraphs entities themselves can be updated in the database until I actually save the node, especially when you consider workflows that include revisioning and content moderation. It should be possible though. I'm just thinking of Views, which lets you make all sorts of changes and preview the results, but doesn't update the actual view in the database until you click save.

That said, if you implement the drop-button interface, including "Reset item" as an option in the list might be a nice bonus feature. It would throw out any changes made to the item and revert it to its original state.

Collapsing is a great way for making both previewing and reordering more usable, this is as much powerful as the number of paragraphs grows.

How is this going? Is there any point people can contribute?

Is there any code for this? I don't see any patches here. I see some reference to github but I don't see any links for anything. Can somebody post more details for those of us who might be able to help with this?

FYI: Open Atrium 2 is going to use Paragraphs starting in the Jan 21st release, so this module is about to get a lot more use!

@mpotter, some support for collapsing paragraphs has already been committed to the module. I don't know if jeroen.b has had time to refine this at all, but I don't believe there are any further patches for this issue as of yet. I for one would love to see some more work on this though. It certainly makes the module way more usable.

There is a patch attached that adds a new button to collapse the paragraph item when its opened. This button appears only for 'preview' and 'closed' modes.

Screenshot:

Can you guys review it?

There is an updated patch adding a disclaimer after collapse a paragraph item.

That´s just perfect, works beautifully.

That single detail closes the view/edit flow in such way that means a huge enhancement to the module´s user experience.

Thanks @tregismoreira!

Thanks @regismoreira, committed

FYI: I also ported this to the D8 version.

Is this (paragraphs-collapse_paragraph_item-2273555-25.patch) already in the DEV-version from 7.x-1.0-beta6+26-dev (2015-Apr-13)?

I can´t see any previews when the paragraph is collapsed.
Pressing "edit" I get the content.

Maybe an accordion-like approach could improve the UX/UI when "Default edit mode" is "Open" so that the "content" could be collapsed for a better reordering.

Should I create a new feature request for this?

When I apply the patch to the mention version I get:

moriretina:paragraphs mori$ patch -p1 < paragraphs-collapse_paragraph_item-2273555-25.patch 
patching file paragraphs.ajax.inc
Hunk #1 succeeded at 90 (offset 42 lines).
patching file paragraphs.field_widget.inc
Hunk #1 succeeded at 292 with fuzz 1 (offset -154 lines).
Hunk #2 FAILED at 329.
Hunk #3 succeeded at 993 (offset 110 lines).
1 out of 3 hunks FAILED -- saving rejects to file paragraphs.field_widget.inc.rej
patching file paragraphs.module
Hunk #1 succeeded at 285 (offset 26 lines).

... and the installation is killed with a white screen.

paragraphs.field_widget.inc.rej:

***************
*** 311,316 ****
            '#type' => 'actions',
            '#weight' => 9999,
          );
          $element['actions']['edit_button'] = array(
            '#delta' => $delta,
            '#name' => implode('_', $parents) . '_edit_button',
--- 329,342 ----
            '#type' => 'actions',
            '#weight' => 9999,
          );
+ 
+         if (isset($field_state['entity'][$delta]->must_be_saved) && $field_state['entity'][$delta]->must_be_saved) {
+           $element['actions']['must_be_saved'] = array(
+             '#markup' => '<p><em>' . t('Warning: this content must be saved to reflect changes on this paragraph item.') . '</em></p>',
+             '#weight' => 998,
+           );
+         }
+ 
          $element['actions']['edit_button'] = array(
            '#delta' => $delta,
            '#name' => implode('_', $parents) . '_edit_button',

The patch is already in dev and released in beta6. Did you try to configure the preview view mode?

Updating status.

No - I did not try "preview view mode". But I will.
The last time I used it I had big troubles with the preview mode. Since the I avoided it.

BTW: an accordion approach could also be achieved with field-groups.
Maybe this is something to mention in the documentation?

I just created #2476253: Improve collapsible paragraphs to continue where this issues left off.

For the record :

To activate this feature, edit the field widget and set the "Edit mode" to 'preview' or 'closed'.

"Collapsed field" with edit/remove buttons will only be displayed after the main content is saved.