Add Tab support to Particles, and better Description

[DamirPecnik]

If particle have a lot of settings say 50 or more we would really need tabs in the particle so we can adjust the layout better.

Also description filed could be done better as some setting have a 2 or 3 sentences of explaining what to enter in it or we can add a http://fortawesome.github.io/Font-Awesome/icon/info-circle/ next to the field and when users click on it it will explain it in popup, the tooltip that is used now is a little short on the info ....

[JoomFX]

+1 for both suggestions.

I have some particles with quite some options. There should really be a way to group them.

[nicutor]

+1

Tabs are a great idea and these tabs should also be a part of particle items child described on #924

[w00fz]

The description is not an issue anymore, I refractored the tooltips to be JS based, you can now have multilines as well as HTML code (make sure it's encoded though).

More details in my commit message: 87e0837

[mahagr]

@w00fz What about the tabs support? We already have tabs, but I'm not sure if they are generic enough to be used inside particles as fields.. If JS is generic enough, it shouldn't really be a problem to create a field from it.

[w00fz]

I really dislike the idea of tabs within fields, it will just make for a huge mess and finding settings will become extremely difficult.

[nicutor]

Hi @w00fz,

I have a particle where a item child have 90 fields.. only few of them are normal fields and about 80 are settings.

Of course, this is also because there is no nested loop in particle collection.list as described here: #924 , but, probably a tab on each particle or particle child item where you can see only the fields marked as "setting" on .yaml file (something like: setting: yes/no) will be good option. If somebody need to change some settings they can go there without to scroll a lot to find it or even to click on Apply button.

Another idea is to have a small setting icon near to each item "label" and when click on that to open a new window with settings. If each field will be able to have his own side of settings will be great.
For example, I have a field "title" and another 2 setting fields for it "titlealign" and "titlecolor". These 2 setting fields should be somehow on a separated window.

Writing a robust particle is very limited at this point and from my experience with particle creating there are 2 big lacks:

1. Nested loop in particle collection.list Nested loop in particle collection.list #924
2. A way to hold settings fields separated to "normal" fields.

If you can consider these, will be great.

Thank you.

[w00fz]

Could you share a YAML example with that many fields? Even as just a mocking replica is totally fine, I am having a hard time visualizing it.

[nicutor]

I've sent you this on private chat.

[w00fz]

👍

[nicutor]

Hi @w00fz,

Here is my idea about how this should be done.

1. Adding a icon button on each field which have settings attached to it. If there are none, the button should not be displayed.
2. Attach a setting item for the field on particle.yaml file:

    text:
      type: input.text
      label: Text
      description: Set the Text

    textalign:
      type: select.selectize
      label: Text Align
*      parent: text
      description: Choose Text Align
      placeholder: 'Select...'
      default: left
      options:
        left: left
        center: center
        right: Right

"parent: text" means that textalign is a setting/child of "text" item.

When the setting button will be pressed, a new window with the child/setting fields will be showed as normal like items from collection.list

Of course this need to work on collection.list items too and on nested ones when that will be there.

[nicutor]

After I've used the new collection.list to split the items, I think now that will be smarter to have a TAB with settings instead of the button I've described above.

The reason is that, a TAB will be already loaded. The button will need to open a new page with settings and will take more time.

[mahagr]

The issue having everything already loaded is that settings page in many of our themes is already so huge that it will take a long time it to load.

[nicutor]

Hi @w00fz,

Any update of adding tabs? 😇

[w00fz]

Sorry @nicutor, we haven't yet discussed this as we want to focus on the inheritance first. I am still thinking about it in the back of my head, to figure out a way that satisfies you guys and does look good to me too.
Your approaches are good ideas, we just need to figure out a good way of implementing it.

[nicutor]

@w00fz I understand you perfectly and thank you for thinking on how to implement this.

I just dream of this feature with TABs and just checked :)

Have a great day there!

[JoomFX]

@w00fz I'm also very keen on having tabs in the particles so we can better organize and group the different fields. It will be a huge UX improvement.

Guys, I know that your original idea with the particles have been to use it for simple tasks, basically to replace the need of the "Custom HTML" modules, where the user has to copy/paste/modify long blocks of code. But believe me (you already know it), the Particle System in G5 is evolving so damn quickly and very soon you will start seeing incredibly complex particles, with 10s of fields, so we really need to do something about it.

[mahagr]

I also ended up thinking "I wish we have tabs" when I was implementing Article support with @JoomFX . Even it has too many fields for my liking. Another thing to add is to be able to display and hide fields depending on a toggle/select field. Both of them will really be needed in the future particles that our team is already designing.

I have a good idea how to do the tabs; I just want to add a new tab in the top where we already have Particle and Block. I also have an idea how display/hide would be implemented, but on that I would need some JS help.

[nicutor]

Display and hide fields is something I wanted to ask for, but I've let it for future. I don;t have courage to ask too many things on the same time 😃

There is also needed a way to limit the collection list items. For example, to be able to add only 2 or 3 collection list items instead of unlimited. I will add those issues when you guys will have some more time for these, because are not so important like TABs are at this moment.

[JoomFX]

@mahagr

Another thing to add is to be able to display and hide fields depending on a toggle/select field.

If I understand you correctly, this (or something similar) was a feature that I needed (and still need) badly. But back then, @w00fz had some valid reasons not to implement it.
I'm talking about a parent/child dependency for fields. For example, if the parent field is:

1. Not empty
2. Gets a particular value (toggle/select)

Then, and only then, the child fields will appear.
Here is an example of what I'm talking about - this is how all the sections in our templates look:

http://i.imgur.com/dVr1xRT.png

It would be really great if we can make the Background Repeat, Background Size and Background Attach. fields to appear only when the Background Image field is true (not empty).

It would be really great if we can define this parent/child dependency in the YAML for both "Styles" and Particles ;)

[JoomFX]

@mahagr @w00fz guys, I was thinking about the "Tabs" support in particles and I just want to write it down here. I know you have much more important things to work on at the moment, but sooner or later you will have time to look at this as well ;)

The main thing I would use the Tabs in particles is to separate the options/fields for the platform content from the rest. Here's how one of my particles looks at the moment (you might need to zoom in the image a bit):

http://i.imgur.com/VxnzKNi.png

I would love to move all the options/fields that are inside the red box into a new Tab. That's how everything will be much more organized and clearer and will offer a much better UX.

I imaging the YAML implementation to be something like this:

    article.filter.featured:
      type: select.select
      tab: Article Options
      label: Featured Articles
      description: Select how Featured articles should be filtered.
      default: ''
      options:
        include: Include Featured
        exclude: Exclude Featured
        only: Only Featured

Notice the tab: line in the YAML (it can be called tab, container or whatever).
The fields that do not have the tab line will be shown in the "default view" (the default tab).
And for backward compatibility with older G5 versions, the tab line will just be disregarded and everything will be shown in the default view/tab as it currently is.

And of course, Djamil will have to implement the JS stuff for the backend so the tabs can actually work ;)

P.S. And for better UX, it will be nice to have something at the bottom of the default view/tab that will inform the user that there are more tabs/options, because "Tabs in particles" will be something new to them and they will not (yet) have the habit to look for additional tabs.

[w00fz]

So I've been working on this implementation and it's pretty much all done and super simple.

YAML Format

The field for tabs is a container, as opposed to what @JoomFX suggested, i prefer the tabs to be a wrapper of the whole set and that each tab defines what's going to go into it.

Example of YAML

name: My Awesome Particle
description: Just makes everything look awesome
type: particle
icon: fa-table

form:
  fields:
    enabled:
      type: input.checkbox
      label: Enabled
      description: Globally enable this particle
      default: true

    tabs:
      type: container.tabs
      fields:
        tab0:
          label: Tab 1
          fields:
            inside:
              type: input.text
              label: Inside Tab 1
              description: This field is inside Tab 1

        tab1:
          label: Tab 2
          fields:
            ...

        tab2:
          label: Tab 3
          fields:
            ...

    outside:
      type: input.text
      label: Outside After
      description: This field is outside and after the tabs

How it renders

Because it's a container, it can be placed anywhere in the YAML, this means you can have fields before and after. Of course this tabs in between other fields is going to look off, although I've tried and it didn't look quite as bad.

Live example

---

What do you guys think? I'm overall quite happy with the implementation, I think UI wise it's also very obvious that there are more settings hidden and that can be set.
It is quite evident after all this time that certain Particles just require so many fields and that our UI is weak in presenting them. I think this tabs implementation will help with that, my only hope is for this to not get abused. I still stand by my opinion that visible settings are easier to see for the user.
So please, do me a favor and when/if you are going to use tabs, remember to ask yourself if it is absolutely needed 😄

[mahagr]

Moved the issue into 5.3.2 milestone, I want this yesterday!

[ghost]

Cool Djamil, it look awesome :D, that's perfectly fine, as you said, as long as we don't abuse :).

[nicutor]

@w00fz thank you for explanation :) this is just perfect!

[mahagr]

Just a note, container.set is actually being used by inheritance. If you go to Layout Manager and edit a particle, block tab uses set to inherit only a part of the inputs.

[nicutor]

@w00fz I've tested this and works fine on particle and collection.lists from main level. However is not working on nested collection.list items. Can you please check or guide me how to do it? Thanks

[w00fz]

Can you PM me what you got in Gitter?

[nicutor]

Hi @w00fz,

I actually don't get any error. The value of field is not got from database to html.twig file. Its just empty.

Let me know if I can help with anything.

[w00fz]

@nicutor Can you send me the particle to get a nested setup like yours?

[nicutor]

@w00fz sent on your PM. I wish you luck in testing this :-S

[RyanMPierson]

Documented: http://docs.gantry.org/gantry5/advanced/particle-yaml-field-types#particle-settings-tabs

Thanks @w00fz for much of the documentation source material.

[w00fz]

Thank you @nicutor for the testing particle you put together. Helped me finding out an ugly bug with nested fields. They weren't fully working. I could see in your sample particle there were 404s and infinite loops with the collection lists, nasty nasty business. 😺

It should be all fixed now and your sample particle works as expected! Please give it a try.

Cheers!

[nicutor]

Thank you @w00fz . I will try it today and let you know.

This issue was somehow related: #1333

Somebody should check it that still works fine too.

[nicutor]

Hi @w00fz , I've tested this and yes, 404 and infinite loop was fixed.

However, the value of fields from nested collection.list items are still not shown.

I've PM to you all details and test particles.

[nicutor]

@w00fz this seems to finally work as expected :)

I think is safe now to close this issue. If I will find other bugs I will let you know.

Thanks

[w00fz]

Thanks!

[nicutor]

Hi @w00fz,

There seems to be one more issue.

The fields values are written ok on database and the .html.twig filer are getting them from database and shown on the page right.

However, if you will close and the try to modify the particle content again, you will see that the nested collection.lists are not got from database.

They are simple empty and need to be added again and again. It seems that particle .yaml file is not populating the fields value using existing values from database.

[w00fz]

Fixed 😄