Thanks very much for developing this module. I've been looking for something like this for a while. One thing I have run into since using it is that once there are a few paragraphs added to a node, they take up a lot of vertical screen space, and often aren't all visible at once, which makes the drag-and-drop reordering interface tricky. While showing the row weights addresses this to some extent, it would be even nicer if there was a more compact view of the paragraphs for reordering them. A possible solution for this would be to add show/hide toggles for the paragraph contents.

Comments

droppinshucks’s picture

Issue summary: View changes
jstoller’s picture

Title: more easily reorder paragraphs in node edit form » 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.

jeroen.b’s picture

What about using a view mode for that?

jstoller’s picture

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.

jeroen.b’s picture

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.

droppinshucks’s picture

Thanks all for thinking about this. View modes sounds like it could work fine. Having some amount of functionality for non-default view modes available in the instance settings seems like a good idea. Regarding that, having an option for the initial content display to be either collapsed or open would be nice. On the edit form, having both individual toggles and a "collapse all/open all" toggle would also be nice.

Regarding how much info to display for collapsed items, while some amount of info is certainly useful, as long as it's easy to toggle between collapsed and non-collapsed states, people can quickly see the contents of bundles. Are there some things that will necessarily be totally hidden in a collapsed bundle, such as nested bundles? Perhaps, unless info about them (maybe a count of them if they exist, in the case of nested bundles) can be put into the view mode.

regilero’s picture

+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.

jeroen.b’s picture

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.

jstoller’s picture

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.

Frans’s picture

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 :))

regilero’s picture

@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.

DuaelFr’s picture

Version: 7.x-1.0-beta4 » 7.x-1.x-dev

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 ?

Daniel Wentsch’s picture

Hi everybody,

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

Cheers,
Daniel

Daniel Wentsch’s picture

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

jeroen.b’s picture

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.

jeroen.b’s picture

@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.

regilero’s picture

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

jstoller’s picture

FileSize
51.06 KB

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.

Views drop-buttons

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.

jeroen.b’s picture

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?

jstoller’s picture

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.

ginorodrigues’s picture

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?

mpotter’s picture

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!

jstoller’s picture

@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.

tregismoreira’s picture

Status: Active » Needs review
FileSize
6.54 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
131.3 KB

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:
Parabraph Collapse button

Can you guys review it?

tregismoreira’s picture

FileSize
66.08 KB
7.27 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

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

Disclaimer

ginorodrigues’s picture

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!

jeroen.b’s picture

Thanks @regismoreira, committed

jeroen.b’s picture

FYI: I also ported this to the D8 version.

mori’s picture

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?

mori’s picture

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.

mori’s picture

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',

jeroen.b’s picture

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

ciss’s picture

Status: Needs review » Fixed

Updating status.

mori’s picture

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?

click to full view

jstoller’s picture

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

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

O&#039;Briat’s picture

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.