[Resolved] Post-relationship

[Author]

Posts

[tomH-11]

Feedback on the post relationship beta.

My client performs calibration tests of his customers' pressure meters. For each meter he tests, he records multiple test points. So, a test entry will contain fields for owner, test date, model number, serial number, person doing the test, etc., and then a number of test points. Each test point entry contains the pressure point, the initial value, and the final value.

I've set this up in the beta and here is some feedback.

On the post entry form, I still find it cumbersome that the user has to save the post (actually, they have to *Publish* the post) before they can add any of the repeating fields. Note in the screen shot - the message says "You need to save the post before you can use repeatable fields". I think that message should be changed - and possibly modifiable by the designer (me). The user entering these tests and test points doesn't know anything about "Posts" or what a post is or why this thing they are editing is called a Post. That's a WordPress term and shouldn't be carried through to custom "posts". In my case, this is a calibration test so I should be able to have this message say "You need to Publish the calibration entry before you can add test points...".

If I have to actually save the entry before being able to add repeating fields, I'd rather the button and message say "Save" instead of "Publish". They are not publishing these "posts", The user just wants to save them. Publishing is a term associated with blog posts and don't necessarily apply to custom "posts". I know that's more in the core WordPress area but it would be nice to be able to change that wording.

I then added a test point. In the second screen shot there is a number - presumably the index of the test point entry? I don't want that to display - it will confuse the end user. What I would like is an auto-increment field for the test points. So the first repeating field group would get a 1, the second would get 2, and so on. I need to be able to list (and sort by) these entry numbers when I display the test sheet. You can see that I currently have a Test Point field that serves this purpose. The user has to enter this number - 1,2,3, etc. for each entry they make. This is tedious and should be taken care of by the form/repeating field group.

There are also strange characters in the Gauge field title. Not sure where that is coming from as it is correct in the Field editor.

These test point fields are of type "Number" yet they have a giant box displayed for entry. There is no need for that size of an entry box. Can it be reduced? Ah, I see that if I change the display to horizontal, they are more manageable but...

I entered some data in the first test point and then realized that I could change the display from vertical to horizontal. When I did that, my entries disappeared. I had the records but the values in the fields were gone. I had not saved the entry post but rearranging the repeating fields seems to have dropped the values entered in them. If I Update/Save the post, then rearranging the repeating field display doesn't lose the values. We should not lose data when changing the display of the form.

The last screen shot shows what I need to be able to display for the entered test points. This shot is from the production system that is currently using the existing parent-child post relationship model. This is basically just a view of the custom post type with some CSS for styling.

I hope this helps you. I'm looking forward to using the new feature.

Tom

[Amir]

Thanks Tom. This helps a lot. I created several different tickets for Types and we're going to handle all the problems that you've noticed. They're all important things for us to fix.

[Christian Cox]

Hi Tom, again, we appreciate your input here. I'd like to loop in a developer here to further evaluate your needs and assess the possibilities. Please standby and a developer will take a look at this ticket and respond as soon as possible.

[Beda]

Hello, Tom.

Thank you for the feedback 🙂
It is very valuable, as Amir and Christian already mentioned.

I have made sure all the details you mention are filed already in our systems, and the Developers are aware of the issues.

If you like, you can provide us more feedback; we would also be interested in your vision of how things should be displayed, and created.
I refer to CRED and Views primarily; we will value your feedback about your ideas or general feedback you have on how you wish to use the Data created with Types, in CRED and Views.

I already know you plan to display the data in tables, as I see.
Eventually, you have feedback on how you would like to create this, or things that will be crucial for you?

[tomH-11]

Hi Beda,

I've used Views to display data on the front end but I have not used CRED at this point. Ideally, I would like to allow my users to enter data into the custom type (with repeating fields) in a more custom form - instead of using the somewhat generic Post form with small tweaks for custom fields as it is now - which has all the problems I listed initially in the ticket. My understanding is that CRED makes this possible - making a form on the front end - but doesn't support post-relationship or repeating field entry. Please correct me if I'm wrong on that.

On the Views side. I think I generally have the functionality I need but one thing that would be good would be the ability to generate a PDF of a View. Right now, my users are able to simply view the View page and then print to a PDF using their Operating System print dialog. I have some CSS that controls the print view but it would be really handy to be able to generate a PDF directly from a View.

The key driver is to make things useable for non computer/wordpress savvy people. As developers, we just assume that users can look past all the extra "stuff" on a post page and be able to focus on the custom fields that we want them to use. In reality, users are easily confused and distracted by all that extra stuff on the page and get scared that they are going to click something or "touch" something and break it. They get overwhelmed by all that information that we can easily filter out.

I don't know how much we (you) are able to "skin" a custom post type backend form but more options in this area would make life easier for my clients. Note that they have adjusted to the current method and form but it's awkward showing them this kind of functionality at first. It doesn't look polished and seems kind of kludged together because I have to explain all the things that they can just ignore. Their look is "Well if I just ignore it, why is it there in the first place?".

I hope this helps to understand what I'm going for.

[Beda]

My understanding is that CRED makes this possible - making a form on the front end - but doesn't support post-relationship or repeating field entry. Please correct me if I'm wrong on that.

At the current moment, with the Stable Toolset, you can create and edit Posts and Users from the front end.
All Fields, Taxonomies and other Post/User Data is editable and can be created.

The Types beta does not yet work with the rest of Toolset, hence, you are correct that this is not yet working.
But, it will as soon CRED follows the Many To Many implementations of Types.

By then it will support creating Many To Many relationships (currently it supports only adding new Child Posts).

And yes, with CRED you can fully customize your "admin" (by bringing it to the front end and customizing it in CRED).

I perfectly understand what you mean with your last statements.

Did you know that Toolset Access lets you control several such things?
For example, you can hide or show in "read_only" mode the Custom Fields on a Single Post edit Screen.
Since you mention that you have contents that the end user does not have to use, it could be hidden, right?
This is done in Toolset > Access Control > Types Fields.

Of course, this will not be applicable to an Admin. An Admin will always see all the options, but there is little we can do to avoid this.

What I can suggest here is as example (depends what you ship to your end userse) is our method to integrate Toolset In a Theme:
https://toolset.com/documentation/user-guides/how-to-build-toolset-based-themes/

I know these are all only half-satsifying solutions.

I have filed a internal memo to keep this issue in mind, that we produce a Software used by Developers like you - but where the end user needs to be considered when creating the GUI and Settings or Options.

The request to export Views in different Formats has been filed in Past, I added your voice there as well.

[tomH-11]

Thanks Beda,

I'll look more into CRED with an eye towards implementing the new repeating fields feature when it is available. Creating a front-end form that I can customize for this will be great.

Should I close this ticket now that you have created the dev tickets you need from it? You can let me know or close it yourself if you want.

[Beda]

We can close this here, otherwise, if you would like to submit more feedback we can also keep it open.

Once more I would like to thank you for providing your insights to us.
We hope to be able to tailor Toolset according to all these Feedbacks we received in a satisfying way!

[tomH-11]

Thanks!