Duplicate comment backlog items? Additional ideas on module comments

Treepl Backlog
1

Are these two items the same? Should they be merged?

Custom Client Notes For Custom Fields
Native Comments

Thinking about this further some improvements would be:

  • comments could be inserted just like a field under properties, but would not display field in the item edit view, and would just render some text or html.
    -have the option of selecting an existing field so that the comment could be displayed between the title and the field, or as a hidden comment
  • have the comment displayed in page or hidden behind a “?” as an option when creating the field (checkbox)
    -have the option of adding an introductory field to provide some explanation to users on how to edit add data to a module.
    -have the ability to add some html to an introductory comment field so that maybe we could even put in a tutorial video?

I would like to hear other peoples thought on this.

This would be a great feature and would really reduce the amount of detail needed for training.

In my fantasy world, I could even include a link to a module with tutorial information. Kind of like a module that would render on the back end. Instead of the user seeing the admin interface of the module, they would see the front end of the module. I know this idea has been floated before as Front-end Pages Loaded Into Admin Area (AKA Faux Admin Apps)

2

I think the Native Comments item refers to commenting on the item on the front-end (like Disqus or Facebook Comments) which was native to BC. Not admin-side comments/helper text.
Perhaps these need a little clarification @Peter-Schmidt?

Definately lots of cool things could be extended for custom properties. I’d love to see:

  • Default values
  • Comment/description regions (with display options like you mentioned)
  • Grouped properties (that relate to each other and could also be conditionally displayed if another property/field equals something)

In my fantasy world, I’d like to see a really good form builder used to even control how the fields are laid out and interact with each other.
This same form builder could be used for Forms as well.
(one example: https://www.formstack.com/online-forms)

2 Likes
3

Thanks for the clarification.

4

Love the idea of a drag and drop form builder.

My biggest wish for forms is that I could customize the layout and styling of a form and still retain a dynamic link to the form builder so that a client could update the field names/titles/options and those would propagate to the styled version of the form. I imagine something more like a module layout. I could insert the label names and fields into my layout with {{fieldLabel1}} or {{form.field.label.1}} and {{form.field}}.

5

Well, in a way you can:
https://docs.treepl.co/documentation_group/component-types/form

The problem is that each field is usually handled a little differently and too customised for a ‘Layout’ to handle overall.
I actually had something similar in BC (I think Scott Reynolds put out a admin app for this that gave me the idea), but I’m yet to port it to Treepl. Should have a lot more flexibility in Treepl too.