#23120 closed enhancement (fixed)
There should be indication that widget settings have been saved
Reported by: | jacopo.vip | Owned by: | westonruter |
---|---|---|---|
Milestone: | 4.9 | Priority: | normal |
Severity: | normal | Version: | 3.5 |
Component: | Widgets | Keywords: | has-patch needs-testing dev-feedback |
Focuses: | ui | Cc: |
Description
There's currently no confirmation that adding a widget or changes to a widget have been saved. In some cases(fast hosting and a solid internet connection) the changes are saved so quickly the spinner is barely on the screen at all. I think a best course of action would be to have the word "Saved" appear briefly after the spinner goes away. Or perhaps a check mark as that doesn't need to be translated.
Related post on make.wordpress.org: http://make.wordpress.org/ui/2013/01/02/this-morning-i-ran-2-users-through-some/
Attachments (24)
Change History (78)
#4
follow-up:
↓ 6
@
12 years ago
i have attached a patch that i believe addresses this issue
i added a class to wp-admin.css to show the yes.png checkmark bundled in /wp-admin/images
i changed the hide() action in widgets.js when the save is complete, instead i add the new class and initiate a 1 second delay() with a half second fade at the end bringing opacity to 0. finally, a callback resets the opacity to 1 and completes the hide() in the original code.
note! you can't just call delay(1500).hide() or the element gets hidden immediately (hide is not added to jquery's fx queue). the callback is required to have the hide actually happen after the delay. although the fade is not required i kinda think it looks nice.
also, i changed the spinner for dragging and resorting the widgets - it now also shows the checkmark briefly.
tested on mac chrome and firefox
#6
in reply to:
↑ 4
@
12 years ago
Replying to adamsilverstein:
i have attached a patch that i believe addresses this issue
i added a class to wp-admin.css to show the yes.png checkmark bundled in /wp-admin/images
i changed the hide() action in widgets.js when the save is complete, instead i add the new class and initiate a 1 second delay() with a half second fade at the end bringing opacity to 0. finally, a callback resets the opacity to 1 and completes the hide() in the original code.
note! you can't just call delay(1500).hide() or the element gets hidden immediately (hide is not added to jquery's fx queue). the callback is required to have the hide actually happen after the delay. although the fade is not required i kinda think it looks nice.
also, i changed the spinner for dragging and resorting the widgets - it now also shows the checkmark briefly.
tested on mac chrome and firefox
I think that's a perfect solution. Good work :)
#7
@
12 years ago
great, glad you like what i came up with! i'm new to contributing patches here, so thanks...
seems like there might be other places it could be used in the interface, but i haven't hunted. running locally sure makes the issue easy to spot :)
#8
@
12 years ago
- Cc mdhansen@… added
Tested and works as described. I think it is a good solution, no text or translation needed.
#9
follow-up:
↓ 11
@
12 years ago
- Removes the class after hiding the element, otherwise the spinner image no longer appears on next click.
- When saving the order after dragging widgets, only displays the spinner in sidebar header (as it is now), not in each widget.
- Adds the widget object as a context to the selector, in order to only animate the spinner in the current widget.
#11
in reply to:
↑ 9
@
12 years ago
Replying to SergeyBiryukov:
- Removes the class after hiding the element, otherwise the spinner image no longer appears on next click.
- When saving the order after dragging widgets, only displays the spinner in sidebar header (as it is now), not in each widget.
- Adds the widget object as a context to the selector, in order to only animate the spinner in the current widget.
looks good. i had added the class removal on my end, but you beat me to it. plus your patch adds the widget context to the selection which makes sense, thanks.
#13
follow-up:
↓ 14
@
12 years ago
- Cc catalin.dogaru@… added
- Keywords needs-testing added
attachment:23120.diff adds two new classes, .success
and .error
, to use with spinners. Their use is to indicate if the request was completed succesfully or not. Personally I don't think the use .delay()
is really necessary. Fading out slowly the success/error icons should be sufficient. Added also support for the HDPI versions of yes.png
and no.png
images.
Would be nice to merge with ticket:22839 for a better standardization of spinners.
#14
in reply to:
↑ 13
@
12 years ago
Replying to cdog:
attachment:23120.diff adds two new classes,
.success
and.error
, to use with spinners. Their use is to indicate if the request was completed succesfully or not. Personally I don't think the use.delay()
is really necessary. Fading out slowly the success/error icons should be sufficient. Added also support for the HDPI versions ofyes.png
andno.png
images.
Would be nice to merge with ticket:22839 for a better standardization of spinners.
great improvements. needs merge with #22839 and i think similar success/error code across all spinners.
#16
follow-up:
↓ 17
@
12 years ago
NB: Not actually testing the patch just yet.
Those yes/no icons are ugly, don't match the admin, and make me super sad. We've got way better ones in the wp-includes/images/uploader-icons*.png
sprite, although you can't go guessing at where those are located so we'd need to copy them (or put a version of them) into wp-admin/images
. If the coloring doesn't seem right, JerrySarcastic should be able to help us there, as he created those icons, or anybody handy with the source, which is located in the design repo: http://design.svn.wordpress.org/production/wp-includes/images/
#17
in reply to:
↑ 16
@
12 years ago
thanks for the review. my original patch referenced the existing yes.png and no.png files in wp-includes/images. the new images from @cdog are the retina versions and upon review look very similar to the original versions.
the sprite images you referenced are b&w, is that preferable to the color icons we are using now? it seems like green check and red x include color to help make the action clearer, but if they don't match the rest of the interface b&w might make more sense.
if the images are already in wp-includes/images it seems like we can reference them directly? or is there a reason to copy them over to wp-admin instead of in wp-includes? i can rework the css to use the appropriate images, just let me know what you think is best!
#18
follow-up:
↓ 19
@
12 years ago
We can't guess at where wp-includes is located from a CSS file in wp-admin. I don't know if B&W is preferable to color in this instance, but those yes/no icons are ugly, period, and are only used in one place - insert from URL in the old media Thickbox that doesn't even appear by default anymore. If a different color is appropriate (or size), then like I said, I'm sure Jerry or another person handy with Photoshop can help out with that.
#19
in reply to:
↑ 18
;
follow-up:
↓ 20
@
12 years ago
Replying to helen:
We can't guess at where wp-includes is located from a CSS file in wp-admin. I don't know if B&W is preferable to color in this instance, but those yes/no icons are ugly, period, and are only used in one place - insert from URL in the old media Thickbox that doesn't even appear by default anymore. If a different color is appropriate (or size), then like I said, I'm sure Jerry or another person handy with Photoshop can help out with that.
i knew there was a reason, thanks for explaining :)
the attached 23120.3.diff uses the suggested uploader-icons files, to get it working just copy the images from wp-includes/images to wp-admin/images. after reviewing i like the b&w fine, no need for color really - the shape says it all. i did not get a chance to test this on a HiDPI display, but it should work according to my calculations.
#20
in reply to:
↑ 19
@
12 years ago
Replying to helen:
I don't know if B&W is preferable to color in this instance, but those yes/no icons are ugly, period.
Agreed. They were used as placeholders while writing the patch.
Replying to adamsilverstein:
the attached 23120.3.diff uses the suggested uploader-icons files, to get it working just copy the images from wp-includes/images to wp-admin/images.
Thanks for keeping the patch up to date. :)
Please check: attachment:23120.4.diff. After applying the patch, the spinner-icons
(grayscale) or spinner-icons-alt
(color) must be placed in wp-admin/images
. The icons are based on uploader-icons.psd. If the shapes and/or colors need correction, I can provide the PSD files. Personally, I prefer the grayscale version. It fits better with the existing UI, even if the color version is more suggestive.
#21
@
12 years ago
23120.5.diff updates 23120.4.diff against current
#23
@
11 years ago
23120.7.diff: patch against trunk & a bit of cleanup/optimization
NOTE: to use this patch, you must copy uploader-icons.png and uploader-icons-2x.png from wp-includes/images to wp-admin/images.
#25
follow-ups:
↓ 26
↓ 28
@
11 years ago
Added 23120.8.diff which is a Dashicon'd version.
That said I don't like how it fades out. The JS is a little beyond me right now, but wouldn't it be nicer if it just left that green checkbox up for a while.
(Colors are crap, I pulled 'em from what we use for the revisions, but they're too pale.)
#26
in reply to:
↑ 25
@
11 years ago
Replying to Ipstenu:
Added 23120.8.diff which is a Dashicon'd version.
That said I don't like how it fades out. The JS is a little beyond me right now, but wouldn't it be nicer if it just left that green checkbox up for a while.
(Colors are crap, I pulled 'em from what we use for the revisions, but they're too pale.)
thanks! I will update the js and try a brief pause and quicker fade.
#27
@
11 years ago
23120.9.diff - add a brief delay before fading checkmark, fade more quickly. changed color to a dark green, I'm sure there is a better color, please adjust! also removed background from success/error otherwise spinner still shows.
#28
in reply to:
↑ 25
@
11 years ago
Replying to Ipstenu:
Added 23120.8.diff which is a Dashicon'd version.
That said I don't like how it fades out. The JS is a little beyond me right now, but wouldn't it be nicer if it just left that green checkbox up for a while.
(Colors are crap, I pulled 'em from what we use for the revisions, but they're too pale.)
thanks for finding those icons, that would have taken me all day :) quick note on your patch - please generate the patch from trunk (or src) for easier application, yours had the full file paths which i had to edit before applying; also your css additions had spaces not tabs.
#29
follow-up:
↓ 30
@
11 years ago
As an FYI, Shaun Andrews has been playing around with a fun "saved" indication for widgets: https://cloudup.com/ckJmakw7HDg
#30
in reply to:
↑ 29
;
follow-ups:
↓ 31
↓ 32
@
11 years ago
Replying to melchoyce:
As an FYI, Shaun Andrews has been playing around with a fun "saved" indication for widgets: https://cloudup.com/ckJmakw7HDg
Very nice! I like that very much, is there a red X for failures? if we can get the patch here I would vote for that implementation over what we have here.
#31
in reply to:
↑ 30
@
11 years ago
- Cc mel@… added
Unsure — will ping Shaun about it.
Replying to adamsilverstein:
Very nice! I like that very much, is there a red X for failures? if we can get the patch here I would vote for that implementation over what we have here.
#32
in reply to:
↑ 30
;
follow-up:
↓ 33
@
11 years ago
Replying to adamsilverstein:
Replying to melchoyce:
As an FYI, Shaun Andrews has been playing around with a fun "saved" indication for widgets: https://cloudup.com/ckJmakw7HDg
Very nice! I like that very much, is there a red X for failures? if we can get the patch here I would vote for that implementation over what we have here.
I don't have a red x for failures yet — would love some help adding that. Right now its just a simple js timer that adds and removed a class:
// Clicking save will close the widget inside $( '#widgets-right .widgets-sortables' ).on( 'click', '.widget-control-save', function() { var widget = $(this).closest( '.widget' ); var close_check = setInterval( function() { if ( widget.find( '.spinner' ).is( ':hidden' ) ) { widget.find( '.widget-title' ).click(); setTimeout( function() { widget.addClass( 'saved' ); setTimeout( function() { widget.removeClass( 'saved' ); }, 3500 ); }, 100 ); clearInterval(close_check); } }, 100 ); } );
The CSS adds a :before element with the dashicon, which is then transitioned in/out based on the classed added by the JS:
.widget { position: relative; border-left: 0 solid transparent; transition: border-left 0.2s ease-in-out; } .widget:before { opacity: 0; display: block; content: "\f147"; transition: opacity 0.2s ease-in-out; -webkit-font-smoothing: antialiased; font: normal 32px/1 'dashicons'; position: absolute; top: 2px; left: -40px; line-height: 43px; color: #fff; } .widget.saved { border-left: 48px solid #84d24c; } .widget.saved:before { opacity: 1; }
This code comes from the Better Widgets plugin: http://wordpress.org/plugins/better-widgets
#33
in reply to:
↑ 32
;
follow-up:
↓ 35
@
11 years ago
Thanks, I would be happy to work this up in a patch and add the failure X - is this code already part of the Widget Refresh you are working on? Should I add patch against that instead of core (I haven't tried the plugin yet, will soon)?
(Replying to shaunandrews)
#35
in reply to:
↑ 33
;
follow-ups:
↓ 36
↓ 37
@
11 years ago
Replying to adamsilverstein:
Thanks, I would be happy to work this up in a patch and add the failure X - is this code already part of the Widget Refresh you are working on? Should I add patch against that instead of core (I haven't tried the plugin yet, will soon)?
(Replying to shaunandrews)
I think we can just patch it against core.
#36
in reply to:
↑ 35
@
11 years ago
Replying to shaunandrews:
Replying to adamsilverstein:
Thanks, I would be happy to work this up in a patch and add the failure X - is this code already part of the Widget Refresh you are working on? Should I add patch against that instead of core (I haven't tried the plugin yet, will soon)?
(Replying to shaunandrews)
I think we can just patch it against core.
Roger that, will do.
#37
in reply to:
↑ 35
@
11 years ago
Replying to shaunandrews:
I think we can just patch it against core.
23120.10.diff combines @shaunandrews for success notification and a red X replacing the spinner for failures from previous patches. Looks like this -
success - http://cl.ly/000B1X3b3j1C
failure - http://cl.ly/3K2T0s1N1l2d
#38
follow-ups:
↓ 39
↓ 40
@
11 years ago
When/why would saving a widget fail? Displaying just an X feels a little obscure — is there any way we can provide the user with more feedback so they can try to fix whatever went wrong?
#39
in reply to:
↑ 38
@
11 years ago
Replying to melchoyce:
When/why would saving a widget fail? Displaying just an X feels a little obscure — is there any way we can provide the user with more feedback so they can try to fix whatever went wrong?
Saving would fail if you were offline or the server was unresponsive when you clicked the save button. The goal is to provide user feedback so they are aware the save failed. Completely agree the red X is weak, what about a white X on red background matching the green success indicator?
Thinking widget shouldn't collapse when save fails, because user is going to want to try clicking save again.
#40
in reply to:
↑ 38
;
follow-up:
↓ 41
@
11 years ago
Replying to melchoyce:
When/why would saving a widget fail? Displaying just an X feels a little obscure — is there any way we can provide the user with more feedback so they can try to fix whatever went wrong?
More context would be good, but we don't really know what went wrong. What about adding the phrase 'Save failed, please try again' next to the X?
Here is what I have so far: screencast
#41
in reply to:
↑ 40
;
follow-up:
↓ 42
@
11 years ago
Replying to adamsilverstein:
More context would be good, but we don't really know what went wrong. What about adding the phrase 'Save failed, please try again' next to the X?
Here is what I have so far: screencast
The "save failed, try again" prompt sounds like a good compromise if we're unable to know why saving failed. That plus the white x in a red box seems like it would be a clear combination. The x looks a little off-center, but that might just be the screencast.
FYI — looks like the patch needs a small refresh since colors.css is gone.
#42
in reply to:
↑ 41
@
11 years ago
Replying to melchoyce:
Replying to adamsilverstein:
More context would be good, but we don't really know what went wrong. What about adding the phrase 'Save failed, please try again' next to the X?
Here is what I have so far: screencast
The "save failed, try again" prompt sounds like a good compromise if we're unable to know why saving failed. That plus the white x in a red box seems like it would be a clear combination. The x looks a little off-center, but that might just be the screencast.
FYI — looks like the patch needs a small refresh since colors.css is gone.
Thank you for the feedback. I will add the text, check the X centering and refresh against trunk.
#43
@
10 years ago
- Keywords dev-feedback added
- refresh against trunk
- adds wording for save failures 'Save failed, try again'
Success: https://cloudup.com/ce7eqboCFFB
Failure: https://cloudup.com/c99te--mXAq
#45
@
9 years ago
- Keywords needs-refresh removed
Refreshed the patch and refactored the code a bit. attachment:23120.14.diff applies against the current revision.
#46
@
8 years ago
I just came across this issue when integrating [JS Widgets](https://github.com/xwp/wp-js-widgets) into the widgets admin screen. The direction I took was analogous to what is done in the customizer (surprise), where if the widget is not saved yet then the button says “Save” as it does currently, but once the widget has been updated (and the widget-updated
event triggers) then the button becomes disabled
and the text changes to “Saved”. Upon making another change to the widget, then the button becomes enabled again and the text returns to “Save”. In the case of an HTTP error, then the enabled Save button just will never turn to Saved. If the WP_JS_Widget
failed a validation constraint, then the button would remain “Save” but a validation notification would appear in the control.
See saved-button-state.png and corresponding plugin commit: https://github.com/xwp/wp-js-widgets/commit/878b422e4c911bf80ce067ddd2a77cf110a7338b
#48
@
7 years ago
- Milestone changed from Future Release to 4.9
A patch has been added on #41610 which implements a saved indicator by simply disabling the Save button. When a widget is first added or an existing widget is opened, the Save button is initially disabled. Upon making change to field, the button is then enabled until the button is clicked and the Ajax request returns successfully. See https://core.trac.wordpress.org/ticket/41610#comment:8
#49
@
7 years ago
- Owner set to westonruter
- Resolution set to fixed
- Status changed from new to closed
In 41352:
A check mark seems better to me.
In ru_RU, there's no place for the string: 23120.search-widget-settings-ru_RU.png, so it would have the same problem as in #21890.