Pods: Enhancement: Remove ambiguity from *Edit Pod* Page

[garypaul]

There is some ambiguity in the Edit Pod page that I think could be resolved with a small amount of text changes and some simple CSS.

When I started using Pods, it caught me out a few times and I forgot to add a field before saving. A few simple changes would remove ambiguity and enhance the interface.

Here's the CSS I used.

/* Set a default transparent border */
.pods-manage-row th {
    border: 5px solid transparent;
    transition: border-color 300ms ease; /* ooh, fancy! */
}

/* Ensure initial (unchanged, pre-existing) fields have no colored border */
.pods-field-init th {
    border-left-color: transparent;
}
/* any changed field */
.pods-submittable-fields th {
    border-left-color: green;
}
/* applies to a new field just added. Should be defined last... or specificity need to increase */
.pods-field-new th {
    border-left-color: orange;
}

Example:

Potential To-Dos

• [x] Make Text Changes to buttons
• [ ] Possibly make one of the field buttons a class of button-secondary
• [ ] Add some CSS for colored status bars

[sc0ttkclark]

Whoa 💯 🥇

[garypaul]

The only thing that I noticed is that when you EDIT a field but hit Cancel ( no changes ) it doesn't restore the pods-field-init class to the tr... so the record looks like a dirty record... If the pods-field-init was added to the row when you cancel it would fix that. Otherwise, there may be a different workaround.

[sc0ttkclark]

We can update the JS to do whatever is most helpful for you.

[sc0ttkclark]

These are awesome improvements, they'll really help Pods 2.7 look even more spiffy :)

[garypaul]

Wow, thanks @sc0ttkclark That means a lot. The screen shot was made on release/2.7 as well…

The only glitch I found initially was the case where you open a clean field to update, but cancel the changes. I’m using the pods-field-init class to determine if a field was changed, but that’s removed when you edit and not added back when you cancel.

That class should be put back or a different class like pods-field-changed or pods-field-dirty needs to be added when you hit save field. The latter is probably preferable, because it’s more clear... and then this scenario would be a visual bug:

Re-adding pods-field-init might have this glitch:
Change a field (orange), close it (green), open it again (orange) and then cancel ( transparent, oops ) which isn't accurate as there are changes that were made.

[JoryHogeveen]

Awesome! Sounds good to me.
For the orange (in progress) types we can use pods-manage-row-expanded.
Plus, If you make the border green by default and only make .pods-field-init transparent the result is the same.

The only glitch I found initially was the case where you open a clean field to update, but cancel the changes. I’m using the pods-field-init class to determine if a field was changed, but that’s removed when you edit and not added back when you cancel.

A change was requested so the field was initialized as an edited field. I'd say there is no problem with leaving this as a green border even if there were no actual changes.

I think this would be great, also no JS changes needed or anything
_also made sure it only applies to the manage fields section_

/* Set a default transparent border */
#pods-manage-fields .pods-manage-row th {
    border-left: 5px solid green;
    padding-left: 5px; /* Fix for the sortable handle */
    transition: border-color 300ms ease; /* ooh, fancy! */
}
/* Any changed or new field */
#pods-manage-fields .pods-submittable-fields th {
    border-left-color: green;
}
/* Applies to a new field just added or existing field being modified. */
#pods-manage-fields .pods-manage-row-expanded th,
#pods-manage-fields .pods-field-new th {
    border-left-color: orange;
}
/* Ensure initial (unchanged, pre-existing) fields have no colored border */
#pods-manage-fields .pods-field-init th {
    border-left-color: transparent;
}

[JoryHogeveen]

On the other topics:
Buttons labels:
Personally I'm fine with the current labels. Add Field vs Add New Field doesn't make a lot of difference to me.
Same goed to Update Field vs Save Field.
Anyone else has thoughts on this?

About the Add button on the top. I always use that one, please leave it :-).

[jimtrue]

Someone else had mentioned this as being ambiguous as well, and I agree. Add field means you're adding a new field. Once you've started creating it, it should shift to Save Field or Update Field if you're editing an existing one. Maybe we should go for split the difference and make it very clear like WP does and go New Field Edit Field?

On the interface changes, absolutely amazing work! One thing, though, can we add anything for screen readers in the Aria settings to make this more accessible?

[sc0ttkclark]

We have the one on top when there are a LOT of fields. It's easier to work with. I think we have some sort of logic that doesn't show the button in some cases.

[sc0ttkclark]

We could try 'Save New Field' for when you haven't yet saved the new field, and 'Save Field' for when you haven't yet saved the changes to the field.

[quasel]

i don't really see the need save is save makes no difference if I save a new one or an modified field but WordPress uses Publish and Update for new posts - I would go simple with
Add Field
Save Field

what's the bigger issue on this screen ist that Save Pod gives no warning whatsoever if there are unsaved fields - either save all field changes and add a "cancel" button, or add a warning, or don't allow save pod until all fields are saved ...

[JoryHogeveen]

I like the idea of a warning when you have unsaved fields open!

[garypaul]

Yes, visually the green bar would tell you that there's an edit that's been made but not committed, but either a warning before leaving or even something simple like an alert box that says "You have unsaved changes"

As for the nomenclature of the button names... as long as they're not the same... as they're different parts of a workflow.

1. Open a form for data entry ( Add Field )
2. Commit the changes ( Save Field, Save, Close, Update )
3. Finalize the change to the database ( Save Pod, Save [posttype] )

It's also nice that an existing field says update

[garypaul]

@JoryHogeveen Nice work! One comment. If you add in a 5px transparent border top and bottom you'll get a separation between items. That's a stylistic choice, but otherwise editing multiple fields at the same time will give you one long green bar.

#pods-manage-fields .pods-manage-row th {
    border-top: 5px solid transparent; /* separates items from each other */ 
    border-bottom: 5px solid transparent; /* separates items from each other */ 
    border-left: 5px solid green;
    padding-left: 5px; /* Fix for the sortable handle */
    transition: border-color 300ms ease; /* ooh, fancy! */
}

[JoryHogeveen]

@garypaul Looks good!

[garypaul]

Also... initially, i just popped in green and orange just while in testing, but it's probably not a bad idea to use the Pods green.

I don't know if this is the 'Official' green, but I took a green from one of the buttons on pods.io : #95BF3B
An orange or other complementary color is trickier, but something like: the orange #E35036 here: https://color.adobe.com/based-on-pods-color-theme-9557382/

Of course, if there's an "official Pods Green" that would be a better base.

[pglewis]

@jimtrue has developed a design palette with some official colors. Loving the attention to detail here.

[jimtrue]

I don't know if this is the 'Official' green, but I took a green from one of the buttons on pods.io : #95BF3B
An orange or other complementary color is trickier, but something like: the orange #E35036 here: https://color.adobe.com/based-on-pods-color-theme-9557382/

95BF3B is the official Pods Green, but yeah trying to pull compliment off in the 'orange' makes it look too salmon. I'd suggest a 'caution' color, like 'yellow or a yellow-orange' that basically means: 'warning, you've made a change and you haven't saved it yet. But I agree, nothing wrong with making any 'green' highlight actually be the Pods Green.

This is the Color Scheme for Pods:

[jimtrue]

I also really like how the orange/green indicators let you know what you've done and what you've changed. Wondering if we could add that to the sections on the other tabs (and possibly an indicator ON the tab?), since nothing is actually 'saved' until you hit 'Save Pod'.

[JoryHogeveen]

@garypaul
Looks good here! If you want to create the PR yourself, the honor is all yours! Let me know.

Current code I have here (pods-admin.css line 283):

/* Set a default transparent border */
#pods-manage-fields .pods-manage-row th {
    border-top: 5px solid transparent; /* separates items from each other */
    border-bottom: 5px solid transparent; /* separates items from each other */
    border-left: 5px solid #95BF3B;
    transition: border-color 300ms ease; /* ooh, fancy! */
}

/* Any changed or new field */
#pods-manage-fields .pods-submittable-fields th {
    border-left-color: #95BF3B;
}
/* Applies to a new field just added or existing field being modified. */
#pods-manage-fields .pods-manage-row-expanded th,
#pods-manage-fields .pods-field-new th {
    border-left-color: #E35036;
}
/* Ensure initial (unchanged, pre-existing) fields have no colored border */
#pods-manage-fields .pods-field-init th {
    border-left-color: transparent;
}

[JoryHogeveen]

@jimtrue
Not sure if indicators on tabs would actually increase UX other that make the screen a bit colorfull :).
The difference with fields and other options is that field changes do not get saved untill you actually save the field first. You can save the Pod with an "open" field and that data won't get saved. This does not happen with other Pod options, only fields.

It is still very much possible but we'll have to modify a lot more to do that (add classes with JS etc.).

[pglewis]

You can save the Pod with an "open" field and that data won't get saved. This does not happen with other Pod options, only fields.

This is one of my least favorite behaviors in our UI. It catches me out frequently after all these years and I'm sure there's an issue and 3 duplicates about it buried in here somewhere. I think field groupings coming in 2.8 might be when we can really overhaul the field editor since we're going to be hammering in there to support groups.

[garypaul]

I tweaked the code a bit here. Applied a different less Salmon orange and used classes. I didn't see any precedent for styling with IDs in the CSS file so I used what was above it. I don't know if this will affect anywhere else in the UI but I think it should be fine.

tbody.pods-manage-list tr.pods-manage-row th {
    border: 0px solid transparent; // apply default border size
    padding-left: 3px; /* fix for sortable handle */
    transition: border-color 300ms ease, border-width 300ms ease; /* ooh, fancy! */
}

tbody.pods-manage-list tr.pods-submittable-fields th {
    border-width: 3px 0 3px 3px;
    border-color: transparent transparent transparent #95BF3B; /* pods green */ 
}
tbody.pods-manage-list tr.pods-manage-row-expanded th,
tbody.pods-manage-list tr.pods-field-new th {
    border-width: 3px 0 3px 3px;
    border-color: transparent transparent transparent #D8A32D; /* new unsaved fields are orange */
}
tbody.pods-manage-list tr.pods-field-init th {
    border-width: 0;
    border-color: transparent; /* Ensure initial (unchanged) are not highlighted */
}

[JoryHogeveen]

.pods-manage-list is not only related to fields so we can't use that one. I believe the id is the only option were it's sure it only gets applies for this case only.

[JoryHogeveen]

To continue on that and the comment from @jimtrue
A more general approach is fine as well but that will need to checked and tested thoroughly.

[garypaul]

Thanks. Sorry for the delay before. I had made the original suggestion from Chrome Inspector and had to clone and pull the repo into Fresh install of WordPress to test on my end so I couldn't get to it on the weekend.

As this would be my first contribution to pods I just wanted to respect the style I saw in the file... but being this close to a 2.7 release... probably better to err on the side of caution and use the ID.

[pglewis]

Come up with the ideal solution to target what you need and we should implement that. We should support the UI's needs, not have the UI work around what classes are there. If it's something too thorny and time-consuming we'd have to punt, but I think we just need some well targeted classes added?

[garypaul]

Ideally... I think a generic approach is better and more consistent with the rest of the CSS. There are 31 instances where .pods-manage-list in the admin css, but I will totally defer to Jory on this one.

The use case that is required is... when you hit "edit" .pods-field-init is removed. However, if you don't make any changes ( just wanted to look at the field ) and hit cancel, there's no way to tell. Either .pods-field-init needs to be restored ( if no changes made ), or .pods-field-init should only be removed when you update the field. The latter is probably easier to implement in code and would require just a minor mod in the css, otherwise you'd have to keep the dirty/clean state of updated records somewhere.

Let me know if that's not clear. I'll do a video of what happens now.

[JoryHogeveen]

Okidoki, then we do it proper right from the start. The JS part should be updated as well in that case to add some classes we can use.

• [x] Add a class for the updated status: pods-field-updated
• [x] The pods-manage-row-expanded class can simply be used for the orange color. Any field that is expanded is currently being edited
• [x] JS should trigger an alert/warning when hitting save while there are unsaved fields
  
  
  
  • [x] Error message text?
  
  
• More?

[JoryHogeveen]

Almost done, ideas for the warning message?

CSS I currently use (notice the use of the new pods-field-updated class:

/* Set a default transparent border */
tbody.pods-manage-list .pods-manage-row th.check-field {
    border-top: 5px solid transparent; /* separates items from each other */
    border-bottom: 5px solid transparent; /* separates items from each other */
    border-left: 5px solid transparent;
    transition: border-color 300ms ease; /* ooh, fancy! */
    padding: 3px 5px;
}
/* Any changed or new field */
tbody.pods-manage-list .pods-field-updated th.check-field {
    border-left-color: #95BF3B;
}
/* Applies to a new field just added or existing field being modified. */
tbody.pods-manage-list .pods-manage-row-expanded th.check-field,
tbody.pods-manage-list .pods-field-new th.check-field {
    border-left-color: #E35036;
}

[garypaul]

Looks great to me. You're modifying the margins on 180 as well, to fix the sort-handle img?

I had the following:

tbody.pods-manage-list tr.pods-manage-row th.pods-manage-sort img {
    vertical-align: top;
    margin-top: 1px;
    margin-left: -8px;
}

I just did a pull request to change the button text. Hope I did that right. First time working on an open source repo.

[JoryHogeveen]

@garypaul
Oh that is fine as well. If I remove the padding changes it looks best to me with a margin-top of 2px and a margin-left of -10px.

Alse, see my PR for the JS updates.

[pglewis]

@garypaul, @JoryHogeveen Great job here. I'm good to merge this if no one else has any reason to hold.

[jimtrue]

@garypaul @JoryHogeveen Really nice work guys!

[sc0ttkclark]

Love your work here @garypaul, please do not hesitate to provide other improvements like these -- you are awesome!