[META] Nicer UI / Icons for "Paragraph type" + "Add another Paragraph"

Great idea! I would like to place the paragrah select box in a sidebar. Something like this.

What do you think?

I'll look into this, It won't be too hard to add this icon to the entity properties.
Only thing that's annoying is the file storage, we can't save the file id, as that will make this feature break when exporting through features.

@mori, any idea how this icon select would look like in your mind?
@Fulgrim, good idea, but sadly there is not really much room for a sidebar. And when you have the paragraphs field in a field group (like us), it's even worse.

I already experimented with a chosen implementation for that purpose, that could look something like that:

Instead of providing a File-Field, a textfield for providing the uri for the file might be feasible, as this could be easily exported and files stored into a feature or theme could be used for that.

Looks cool! What about adding a description?
Textfield for the uri sounds like a good, and if people use https://drupal.org/project/system_stream_wrapper it's even more flexible.

@mori, sure, I'll just change the status.

We have some content types with complex paragraphs (and also some nested paragraphs). After looking at the UI for us it seems to be the most clean to have a list of all the added paragraph types with some edit/delete buttons. The edit option will open the form in a ctools modal frame or something.

I will try to find the budget to create a widget for this. Please let me know if anyone else thinks this could be a good UI solution.

It would also be helpfull to mention some obvious road blocks I might be missing, or some pointer on how to implement this the fastest way.

After looking further into it, having modal frames are a bit problematic since you want to open modal frames for some fields as well. Would be a bit messy to have multiple modal frames.
The EdenSpiekermann approach looks nice!

Hey.

I was working on a similar solution for another module (that works practically the same). I used icons to select the conent element.
If you are interested in this featuer, I could try to write a patch? You can alos check out the master branch of my module: http://cgit.drupalcode.org/chunks/tree/ to see my implementation (it's not a fully functionally module yet)

@killerpoke: Yeah! Patch Patch! Patch!
:)

@killerpoke, that looks very cool!
It makes more sense to put it outside of the draggable table though.

Also, if you make a patch, please make this functionality in a separate widget!

@killerpoke: +1 for patch

Very cool idea! +1 for patch
I have been studying as some modules Wordpress, I think there are very good examples that inspire. To see what you think this example?
http://codecanyon.net/item/visual-composer-page-builder-for-wordpress/24...

The way I see this happening is by adding the icon path when creating or editing a paragraph type, this icon path field would be a regular text field. That gets added to each option in the select list via data-imagesrc attribute. Using some jquery we can render this as an html list showing the images next to the paragraph title. I got the idea from: http://designwithpc.com/Plugins/ddSlick

This is on our roadmap for 8.x :-) and we are working on proposals.

For Quickedit based "Add" it's is a must.
Adding icons in paragraph type management is a key piece.
For the Backend, we need to think about what we enforce end where users will have options.

I'll update you with our proposal soon.

This is going into the direction that is discussed here:
Related Contrib https://www.drupal.org/project/paragraphs_browser

Updating with a presentation slide from Drupal User Group meeting on 2.11.2016.

Then, we should add a new way of adding Paragraphs where we offer a Modal form where to select the Enabled paragraphs displaying the icon. Also, we should add the "Add" button between every paragraph. We need extensive test coverage for this.

I think that is a really good idea to add icons to paragraphs, which would help to identify them while creation and editing (thinking of the collapsed and preview modes).

For the Add-New-paragraph dialog/dropdown I am thinking it would be good to have two options:

• A simple solution that is more a popover menu-list with icons to replace the current dropbutton, because in projects with NOT so many paragraphs a dialog with many grouped options, tabs and previews would actually worsen the UX. You should always be able to able to perform your task fast...
• A more complex solution that offers what is shown in the above designs or in paragraphs_browser that caters for the more complex use-cases where you really have many paragraphs and even the need to group them into categories.

And I would rather have the new paragraph selection interface in a popover if it is small or in a sidebar tray (settings tray - outside-in) because that pattern works better on mobile and is not so much a switch in context as a modal.

Outside-in is currently limited to frontend editing. We have other issues of adopting this pattern postponed in diff #2808623: Use outside-in for diff / revision navigation because of the limitations. So it's not an option. Also IMHO, Outside-In is interesting for secondary perspectives, but not for the primary action such as adding an element.
I have only seen this pattern nicely applied with a sidebar showing all the items and using drag&drop to place them in the content area. But i this is IMHO way too far from standard patterns in Drupal. http://innovastudio.com/content-builder.aspx

Agree about the popover. While i don't want to add too many options, i'm not yet sure how this "add" element will fit all cases. We could degrade it to the current button if there are only very few paragraph types. We can only make it the default behavior if it is really nice and doesn't add extra clicks and UI complexity.

Much early patch, we still need to add settings for it. But the add button is not displayed unless we hover over the paragraph.

These concepts are similar to https://www.modmore.com/contentblocks/ in modx. If interested, you can try a demo at http://demo.modmore.com/manager/?a=resource/update&id=1.

https://www.drupal.org/project/paragraphs_browser looks like it will be nice solution.

Pointing to general discussion about UX improvements - #2692051: [META] Alternative UI like divibuilder

This is really cool stuff.
I am just thinking about the hover state for these button. Hover states are not good to handle on mobile devices. Why not always displaying it?

Hi @chr.fritsch that sounds cool, but what we try to do is to avoid cluttering the UI. Not really sure if we instead could make the hover area bigger?

Hm, i'am not a big fan of these hover state, because its not useable on tablets for example. I would prefer to show it every time.

What do you think about this?

Yes, but AFAIK it's recommended to have just one primary button per form. If we displayed all time we might break core patterns. Not really sure, for me it works, but I would like to get more feedback from @Berdir or @miro_dietiker.

We can always display the "+" button, but we will need to display them standard grey. That's not a primary action.
We could switch it to blue on hover.

Regarding accessibility, we should possibly make the label "Add" and ship the "+" as icon. Need to think more about it.
The "+" alone is though one step more far from core patterns with buttons than the proposed "+ Add".

I think i would make the button one pt smaller. There are some smaller buttons in Core too.

Many frontend UX content editing tools are hiding these buttons completely if far from focus and it helps to make the UI feel simple. But we can discuss this step separately from the switch.

I'm not sure how to move forward, this issue is huge combined with the popover selection. Should we convert it to a meta and create children for the whole implementation cycle with follow-ups and details? I think we should.

The issue for adding images to the paragraphs types is different, this issue should be just for the new adding mode.

Just wanted to show some progress before changing the IS.
Second "+" button is hovered.

Hm, i'am not a big fan of these hover state, because its not useable on tablets for example. I would prefer to show it every time.

The contextual links already follow the "hide until relevant" pattern and work on touch. I suggest this follows the same approach.

Looking good, btw!

@yongt9412 Yeah we have the issue to add the icons. But the add widget then is much more than just listing what can be added.
For instance, the UI displays tabs, thus we need grouping of the paragraph types.

We already have 37 comments here and are not beyond the button itself. I really vote for METAizing this here for the general goal and work in specific issues to introduce the add widget step by step. Still the first issue will be a tiny monster.

Adding steps to implement both new icons and Add option.

This issue is in fact highly related to the challenging feature to support drag&drop accross fields and hierarchy:
#2658694: Move a nested Paragraph across fields and nesting

The reason is, for both implementations, we should have a data attribute on the paragraph field that indicates what paragraph types are allowed. This field can be used to filter the paragraph types in the modal and/or to limit drag&drop to the allowed fields.
I thought about adding a separate issue to introduce the data attribute, but it doesn't really add value on its own.

Rather than [+] between Paragraphs, an option like collapse all paragraphs would be a neat upgrade. Then you could re-order paragraphs easier.

@Artnetik For reordering, we have a separate proposal, see #2825575: Introduce a Drag & Drop Mode
If you separate the drag and drop problem from the other UX, it's way easier to find solutions for better UX.

We splitted the UI in #2841309: Add settings summary to the behavior plugins
So this applies to the new widget only.

Here is design for in-place adding of paragraphs with popover instead of dialog.

Very nice design in #44 and original issue. I think this can make a big difference for Drupal UX and Paragraphs popularity!

#44 has a nice design. It would be interesting to also support paragraph groups (e.g.: simple, advanced, layout) with 1 of those groups (e.g. simple) default expanded (accordions-style maybe?)
This grouping could be optional, but is necessary on platforms having many paragraph types.

Grouping effort going on in #2831762: Add grouping for Paragraph types in "Modal" add mode

Hi, This looks really nice and is just what I would like to see.

I have one remark. Next to the dragging on the left, there should be a - not so prominent - icons/actions to move a section up or down. When dragging while scrolling takes too much effort en is not fail proof.
nice work!

-

--

This is a marge patch for:

No. 6 patch from #2828110: Sorting of paragraphs 03 - create a NEW paragraph "in place" between existing ones
and
No. 206 patch from #2461695: Support asymmetric translations

To work with the latest 8.x-1.x-dev

projects[paragraphs[type] = module
projects[paragraphs][download][url] = https://git.drupal.org/project/paragraphs.git
projects[paragraphs][download][revision] = c14d496c312373fde8029a1ad72c3d4cc2363ae6
projects[paragraphs][download][branch] = 8.x-1.x
;; Issue #2236905: Nicer UI / Icons for Paragraph type + Add another Paragraph
projects[paragraphs][patch][] = https://www.drupal.org/files/issues/2236905-50.patch

This issue is supposed to be and stay a super META issue to discuss ux improvements. No patches please, it destroys our overview and breaks conversation flows.

My bad! Sorry about that. I will submit patch to the correct thread in a different issue.

@mtodor i found Drop.js:
http://github.hubspot.com/drop/docs/welcome/

We consider adding tether.io to support sticky elements such as the perspective tabs, so Drop.js seems this would be the natural choice for the add element.

About drop.js: We need to check if this can be the default. Some cases with many paragraph types need a more interactive widget (groups with drill down, bigger icons, scrolling) where an overlay could be better than drop.js. But we first should experiment with it.

So the decision if drop.js or overlay might be a setting finally.

@miro_dietiker: Sadly the paragraphs project is bloated with endless discussions like this one. It looks like the project is not getting done anything since a long time.

But do not get me wrong: I appreciate your work and the paragraphs module is one of the "diamonds" inside the contributed Drupal 8 modules.

For me the "add button between existing paragraphs" feature is the ultimate missing feature in content editing with the paragraphs module. Dragging paragraphs all the time is just annoying.

Since there is no progress in all the related issues, why aren't you just backporting this feature from the thunder distribution? Check https://www.drupal.org/project/thunder/issues/2828110.

What can we (the community) do, to bring this feature on track?

@Peter The reason why there is so slow progress are discussions like this.

We had 22 commits within last 10 weeks and there is great progress. At the same time there is solid activity (16 commits in 7 weeks) in Paragraph Collection to make the Paragraph Library ready to move over into Paragraphs. And BTW about 80% of the proposed UI improvements and features from my presentation above from January 2017 (Drupal Mountain Camp) have been implemented. The remaining 20% are harder problems and need another iteration to refine them and an update is needed anyway. I try to find time soon...

Maintainers need more support and funding and there is almost none. The time i invested to find funding resulted in long discussions spending weeks of work without almost no relevant results related to the amount of work that needs to be done. The funds provided would by far not even cover the time spent for the discussions. There are rare exceptions though and we will focus on these and also showcase them.

The reason why this was not committed yet is that we were still extending the widget and refactoring it and concerns of maintainability in Paragraphs and Thunder. The approaches proposed interfere with these as limiting extensibility, adding high maintenance complexity, and thus would speed down many other active or prioritised tasks ahead. And at the same time zero prioritization in the projects that support our Paragraphs work.
(Yes, the Thunder patch has quite some complexity with its 35kB and a lot of JS...)

And back to the most relevant point so you won't get me wrong:
We still have zero test coverage and that's inacceptable for any functionality to commit in Paragraphs.
BTW even if the implementation is redone, most parts of such tests could be reused.

If things annoy you, contribute to solve them or fund people to do so. I hope we can now focus on getting things done.

If things annoy you, contribute to solve them or fund people to do so.

+1

@Peter: we provide a patch for the experimental module in https://www.drupal.org/project/paragraphs/issues/2877927#comment-12245820
- its 10k btw, not 35 :)

@pivica and @miro: We really want to contribute to solve the problem, but we need some kind of decision (of you) on how to procede, it would be very helpfull, if you would continue the discussion we started in that same Ticket. Mladen described the Pros and Cons in the last comment.

So, how can we prodeed here? You said, tests are needed, we can do that. What kind of tests do you need, how many do you need to feel secure to proceed with this feature request?

@miro: Thanks for your detailed answer.

daniel.bosen is right. How should the implementation look like? There needs to be specification. Right now we have just brainstorming. I won't develop anything without a clear specification. Such a dev approach is not efficient. I can deliver tests in JS and kernel Base Tests and Unit Tests.

We have defined how to proceed with "Add between" or say "Add before" and synced with the Thunder team. They will look into starting the implementation next week.

Next step for "Add in between" - I have added sub-task for adding of the hidden field for "Modal" mode #2944372: Introduce hidden field for addition position of paragraph.

To simplify the workflow for editors, please consider to not just add the "+ Add" button in between the rows, but show buttons for the first x paragraph types.
Example:

But only for desktop devices I would say. Otherwise the UI seems polluted.

@stBorchert We defined that we will not add any such new visible button. Yes, i don't want to add clutter. I'm more in the mood to remove UI noise.

Instead we have added functionality and a hidden field to the Paragraphs widget:
#2944372: Introduce hidden field for addition position of paragraph

Paragraphs itself will ship an "Add Paragraph above" or "Add before" action that is hidden inside the "..." button.
The implementation works, we need tests and make it configurable by the new widget features.
#2946514: Add paragraph before button
^ This issue needs help and love... :-)

This will allow you to either disable that standard feature and attach some own derivative JS with custom placement and functionality.
Maybe we can split off some of the JS for better reuse in alternative implementations.

Promoting specific Paragraph types would be another dimension of settings where flavors vary like people prefer different admin UI through own themes looks for different workflows.

There is a new module with add in between buttons (https://www.drupal.org/project/paragraphs_features).
It requires Drupal >= 8.5 and also new field provided in #2944372: Introduce hidden field for addition position of paragraph.

All feature options will be available as 3rd party settings for experimental paragraphs field widget. So it will be possible to configure using add in between only for content entity paragraphs field, but keep default modal (or another add mode) in nested paragraphs.

As next feature, we are planning to port existing paragraph text split feature from Thunder. It's partially what we want for #2932562: Support to split paragraphs into multiple.

#44 looks like a really elegant way to go. Are there any efforts to make this really happen?

@jive01 All efforts taken are into the direction of that idea and also make the amount of work to do #44 easier if you want it for your custom project.

For Paragraphs itself, it is unlikely as it would mean adding another library. That's why we have chosen in Pararaphs to open a modal - where we are much more flexible with dealing with larger amounts of Paragraph types (scrolling or adding filters via templates).

The current status of the project is very pluggable (see paragraphs_features) and it would be a perfect candidate for a small helper module... maybe a good fit for Thunders paragraphs_features itself?

Given this is the meta issue, wanted to bring up this idea here first. Dave Reid just wrote a nice addition to the Embed module to store the icons as base64 encoded in the config. Is this something that Paragraphs could do too?

For further explanation on why this is a really good thing to have, (mostly portability between projects/environments) see the original issue here #3039598: Store button icons as encoded strings in config

> Given this is the meta issue, wanted to bring up this idea here first. Dave Reid just wrote a nice addition to the Embed module to store the icons as base64 encoded in the config. Is this something that Paragraphs could do too?

You mean something like #2832021: Support paragraph type icon config deployment ? ;)

:facepalm: yes.

Patches here are *very* old and this is a meta issue, so setting back to active.