WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#35176 closed enhancement (maybelater)

Appearance of update button should change when a post is edited.

Reported by: EmpireOfLight Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.4
Component: Editor Keywords:
Focuses: ui, administration Cc:
PR Number:

Description

If I haven't made any changes to a page or post, I shouldn't be able to click on the update button. And it would be neat if as soon as you type in the title or content fields, the update button becomes active.

Change History (16)

#1 @khag7
4 years ago

Maybe something along the lines of this...

Add the "disabled" attribute to the Publish/Save button by default.

Then make some javascript like:

    $('form#post').change( function(){
        $('#publish').removeAttr('disabled');
    });

Doesn't appear that editing the post content triggers a change event. Need to get into the tinymce iframe somehow.

#2 follow-up: @TimothyBlynJacobs
4 years ago

  • Keywords close added

That wouldn't really work. A post is more than the main content editor. You have all of the custom meta boxes as well. A user might want to change a metabox field. How would you handle that? Each metabox works differently.

Just because a user hasn't updated the main post content, does not mean they want to save their changes made elsewhere.

#3 in reply to: ↑ 2 @khag7
4 years ago

Replying to TimothyBlynJacobs:

That wouldn't really work. A post is more than the main content editor. You have all of the custom meta boxes as well. A user might want to change a metabox field. How would you handle that? Each metabox works differently.

Just because a user hasn't updated the main post content, does not mean they want to save their changes made elsewhere.

Yes, a post is more than the main content editor. But all those other fields fall inside the form element with id of post, so the jQuery selector form#post should encompass all those fields.

Navigate to the edit screen for a post. Then Open your javascript console and paste this:
jQuery('form#post, #content').change( function(){ console.log( 'change detected' ); });
Then start changing stuff. Almost anything triggers a change. What doesn't work is the post content editor. It would take some figuring out but it should be fairly simple.

What isn't simple: figuring out if this is a good idea or not. What's the benefit to disabling the save button?

#4 @EmpireOfLight
4 years ago

The benefit is that users won't be confused about whether or not they've made a change to the post. E.g., in OSX, if I edit a file, a black dot appears in the red "close" button in the top left of the window; I'm thinking along those lines, something that tells you the post has been changed in a way that can be saved.

To @TimothyBlynJacobs point...I guess it could be confusing if you checked and then unchecked a category; would the button go back to being disabled?

I still think it would be an improvement. I can't tell you how many times I've needlessly hit that button because I wasn't sure if I'd done anything (and observed users doing this).

Version 0, edited 4 years ago by EmpireOfLight (next)

#5 follow-up: @TimothyBlynJacobs
4 years ago

The thing, though. Is that accidentally updating a post is a relatively low cost problem.

However, to disable the update button unless a change has been detected means that we have to be 100% certain that any and every change is detected. Otherwise, the user is left stranded.

#6 in reply to: ↑ 5 @EmpireOfLight
4 years ago

Replying to TimothyBlynJacobs:

The thing, though. Is that accidentally updating a post is a relatively low cost problem.

However, to disable the update button unless a change has been detected means that we have to be 100% certain that any and every change is detected. Otherwise, the user is left stranded.

Maybe you don't disable the button, but you do change its style when anything has been touched; it could get darker, or a dot on it or something to let people know a change has happened.

This would also reduce the number of times the "Confirm Navigation" alert appears. Users would be more aware that there were changes to be saved before exiting the view.

Last edited 4 years ago by EmpireOfLight (previous) (diff)

#7 @SergeyBiryukov
4 years ago

  • Component changed from General to Editor
  • Focuses ui administration added

#8 @khag7
4 years ago

Currently the post editor shows the publish/update button with the class "button-primary".

What if we set the class to "button-secondary" and then updated the class to "button-primary" if a change is made. This way we never disable the button, but we do avoid drawing attention to the button until a change is made.

Keep in mind, we do already offer an alert box if the user tries to close the window without saving changes.

Try pasting this JS into your browser's js console after the page loads:

	wp.updatePublishButton = function(){

		alphasort = function(a,b){return((a.name<b.name)?-1:((a.name>b.name)?1:0));}
		currentformvalues = jQuery.param(wp.postfields.serializeArray().sort(alphasort));
		
		if ( typeof wp.initialformvalues === 'undefined' ) {
			wp.initialformvalues = currentformvalues;
		}
	
		if ( wp.initialformvalues === currentformvalues ) {
			jQuery('#publish').removeClass('button-primary').addClass('button-secondary');
		} else {
			jQuery('#publish').removeClass('button-secondary').addClass('button-primary');
		}
	}

	wp.postfields = jQuery('#post :input').not('[type="hidden"]');
	wp.updatePublishButton();
	wp.postfields.on( 'change keyup', wp.updatePublishButton );

It's not perfect but its a start. Detects changes to form fields, compares to initial values, sets button class accordingly.

It doesn't detect changes in the visual TinyMCE editor (except maybe when the autosave happens?) but it works for the text editor. It will take some tweaking to make it work with TinyMCE.

I kind of like the behavior actually, seeing the button change from blue to gray lets me know that the form data is different than when I started.

#9 follow-up: @azaozz
4 years ago

Thinking this may be a "not-so-great" UI change. Two reasons:

  • The whole Edit Post screen still has the feel of a form, and the submit/save buttons on most forms are not disabled when the forms are "empty".
  • We can (probably) detect changes in all metaboxes (they are saved together with the post, see comment 2), but may miss changes to elements added by plugins, especially when done with JS. For example:
    jQuery( '#post' ).submit( function() {
      if ( [some condition] ) {
        jQuery( '.my-field', this ).val( 'My Value' );
      }
    });
    

#10 in reply to: ↑ 9 ; follow-up: @EmpireOfLight
4 years ago

Replying to azaozz:

Thinking this may be a "not-so-great" UI change. Two reasons:

  • The whole Edit Post screen still has the feel of a form, and the submit/save buttons on most forms are not disabled when the forms are "empty".

Yeah, disabling it would be bad. But what about just changing the appearance when something's changed on the page? @khag7 's JS does a nice job of this; I tried it and it felt right on.

It does feel like a form, and that's a bad thing. It should feel like an app, and apps do intuitive stuff like help you remember if you changed something on the interface.

  • We can (probably) detect changes in all metaboxes (they are saved together with the post, see comment 2), but may miss changes to elements added by plugins, especially when done with JS. For example:
    jQuery( '#post' ).submit( function() {
      if ( [some condition] ) {
        jQuery( '.my-field', this ).val( 'My Value' );
      }
    });
    

No sure I understand the issue here...so if a plugin does something when the update button is pressed, it won't happen because of the new functionality?

#11 in reply to: ↑ 10 @azaozz
4 years ago

Replying to EmpireOfLight:

Yeah, disabling it would be bad. But what about just changing the appearance when something's changed on the page?

Okay, but why?

  • Movement or animations somewhere on the side are really annoying while trying to concentrate on writing.
  • A button that changes color but still works the same way may be confusing for some users (what does the change mean?).

No sure I understand the issue here...so if a plugin does something when the update button is pressed, it won't happen because of the new functionality?

Right, plugins trying to do something on submitting the form will not work until some field is changed (so the form can be submitted). Disregard that, only applies if the button is disabled.

#12 @khag7
4 years ago

I'm 100% opposed to disabling the button as was originally suggested. It must always function. But changing the color or adding some other indication of "unsaved changes" isn't an awful idea.

On the other hand, I tend to agree with @azaozz that it has potential to be distracting and unclear. Unclear UI changes are usually only worth implementing if they offer a good new feature. This proposed enhancement is neither intuitive or so great that's its worth a user having to take the time to to understand why the button is changing appearance.

That's my $.02 on the matter. The js I shared is about as close as I can think of making it intuitive without interrupting functionality. But I'm just not sure it's obvious enough to be worth implementing. Maybe we should be add some text that says "unsaved changes".

#13 follow-up: @EmpireOfLight
4 years ago

  • Summary changed from Update button should be disabled if there haven't been any changes. to Appearance of update button should change when a post is edited.

#14 in reply to: ↑ 13 @EmpireOfLight
4 years ago

Replying to EmpireOfLight:
Changed the summary–the whole "disabling" thing is taking this off track. I do think we have a serious usability issue with that button's current behavior, but if the general consensus seems to be "if it ain't broke, don't fix it" we can close this.

Last edited 4 years ago by EmpireOfLight (previous) (diff)

#15 @EmpireOfLight
4 years ago

  • Resolution set to maybelater
  • Status changed from new to closed

#16 @swissspidy
4 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.