A better indication of action happening on buttons.

[xavortm]

It's from UX point of view - every single action button that when clicked the page is being refreshed or loads another has no clear way of showing this. A quick example can be the site setup process.

When you click submit for example, a simple blue shadow appears that show that something is happening, but this blue shadow is not very obvious (on a blue button) and is very similar to "focus" outline as default behaviour for buttons. I personally suggest one of two options:

One - gray out the button but still keep it clickable, that will show that the click has triggered something, but will also allow the user to click a second time which will deal with the case of having connection problems in the middle of request, where you can resend the settings once more without refreshing the whole page.

Two - same as before, but instead of making the button gray (or do) add small rotate dashicon to visually represent action.

The main reason i report this is because many times when i setup the site or work on the dashboard, clicking a button doesn't really show anything and i think for some reason i haven't clicked it or nothing is happening. Its purely for UX and to me it's not a small thing

[xavortm]

Here is example of how i imagine it, though i even without the animated icon would be enogh

[karmatosed]

@xavortm interesting idea and thanks for sharing it.

I am keen on anything that adds feedback. It would be good to know how long the waits are in these areas, if they are a while then that adds more weight to adding such feedback. I think it does have a place, but we need to have a consistent UI and apply to all areas where a weight can happen - if we do.

Looking at your mockup, have you considered removing the button and just showing a loader? As it is 'loading' the button itself can't be clicked, so disabling this makes sense.

[xavortm]

Hey @karmatosed ,

The wait time can variate between 1 second and more than 5 depending on how much requests and how slow the server might be, so it is obvious and will make the user question if something is happening. Similar buttons are also in creating new posts, comments area and other parts of WordPress that take time, but do not really represent that.

About the second part, just showing a loader is probably a problem, since the buttons should be clickable all the time for the reason of the not fully sent requests. I have a little hard time explaining this, probably someone with more experience and knowledge can give some feedback here?

If its about consistency see the "update" post or "publish" post button - they act totally different from what i pointed - they have the gray out (in this case darker blue) color, no outline/shadow and have the loader left of them.

[karmatosed]

@xavortm thanks for your responses. Unfortunately, I'm not convinced that the buttons should be clickable if they are loading. That isn't a great experience as well they are already working. If they aren't... well they'd not show loaders. I think having a loading style that reflects a loading state is a great addition.

Would you be interested in exploring this loading UI look? Or are you looking for someone to add UI mockups to your suggestion? We can add a tag and get that done if you are.

Whatever we do, we should absolutely look to apply consistently where it is suitable.

[xavortm]

I will prepare a few examples of possible solutions, including your suggestions for non-clickable buttons, since i too find them more fitting as in UX point of view.

[xavortm]

Here is some quick example of a few possible updates, where #3 is probably requiring the most changes, but i do see it as a good example, since its the way youtube approaches the page loading. In general anything longer than 1 second should have indication, its how people perceive time.

My main concern is the fact, that there are multiple areas where a better representation of action taking place, which are not friendly for additional elements, like the loader icon next to the Save/Update buttons in the post edit page.

Generally the reason i created this topic was the shadow being added behind the button, that looks way too similar to the outline css property, which indicates "focus", not "action". It is the first thing i tried to eliminate in the update proposals.

Click for larger resolution.

[karmatosed]

#2 for me is the best out of them for the loader. I would like to see it not look like a button though. What about exploring by removing the button styling?

[xavortm]

I think that removing the button would make the dashboard less uniform, since there are buttons that do not require refreshing the page, or refresh that does not really repaint the whole screen, where after the action is completed, the button will return to its initial form, which would make it "flash" instead of keeping its form and shape throughout the whole process.

This is my opinion on why not to do that. I like what you proposed for the reason of changing the button look even more when action is taking place and for the fact that it really becomes unclickable that way in a more obvious way.

Those are my two opinions for and against that, but i would really like to hear some point of view on that matter or even another better solution :)

[karmatosed]

I'd still be keen to see it explored - perhaps as a codepen.

As you've asked for other opinions too, lets get some more eyes on this rather than just my opinions. @michaelarestad and @melchoyce what do you both think about this?

[celloexpressions]

Perhaps related, with the theme switcher in the Customizer we decided to fade in a full screen overlay with a loading spinner as soon as a preview button (actually a link) was pressed, since a full pageload was required. The concept is that once the action is triggered and the page is loading, the user can't (and shouldn't try to) do anything else on the current view, so we can give a nice transition that makes it seem faster and smoother rather than waiting for the browser to load the next page. That's probably a bit excessive to use whenever buttons trigger a page load, but it is an existing UX pattern in core that we should consider, and possibly update along with a solution here.

[melchoyce]

Proposal 1 seems most consistent with what we currently use in the dashboard. Since you brought up the concern, have you identified specific places where there isn't room to have a loading icon next to a button?

Also want to ping @hugobaeta on this since he's been working on button styles and has also been talking about loading icon standardization in core.

[xavortm]

The "Apply" button. The screenshot is after clicking it and waiting to apply the changes. There is action, the page is reloading and the indication is the same as in the login button, but here is no space for loader like #1 on the concepts.

If the indication have to be unified across the dashboard (which i believe is the case), then having two different types of loader is not really the option i guess.

[Ixium]

The proposed ui update nr 2 looks best to me, because the button already has the focus of the user.

[xavortm]

A quick codepen demo about Number 2 - ​http://codepen.io/xavortm/pen/pbROmR @karmatosed

[melchoyce]

Revisiting this ticket in design triage today. Really like that codepen prototype, @xavortm!

What if we updated the label in addition to adding a spinner, similar to how plugin and theme updates are done inline? ("Shiny Updates"). Attaching a gif to show what I mean.

[johnbillion]

Buttons that change size when they're active isn't very desirable. It can cause other UI elements to move around (this is why the spinner class in core uses visibility:hidden instead of display:none in its inactive state).

Could we do something to append or prepend the spinner without affecting the button size?

[xavortm]

I can see how that would work with :before / :after pseudo elements, but I am not sure how will this affect a11y. This was the reason why I also suggested the loader on the top of the screen, just how YouTube does it when changing pages. I am only unsure if that's doable with the dashboard (I am not too technical myself). The benefits are that this should work equally well for all actions across the whole dashboard without the need to change the UI and thinking of changes to the width/height of elements.

The problem with the loader, in my opinion, is that the text label of the button disappears. Compared to the shadow added on buttons for both "focus" and "pressed, something is happening" being the same is a better choice.

Also for the GIF from @melchoyce , how would that work for non-button links?

^{looks like that when you focus it with tabs or click+drag or when you click and wait to open the Appearance page.}

[joyously]

We discussed this ticket in design triage today. We question whether buttons should rely on animation for state. Animation should enhance a situation, however, text should likely be the primary indicator on a button. (But as stated previously, changing the text of the button incurs reflow issues.) Maybe primary action buttons can use one same pattern to be consistent across the admin pages.

[calebj7]

I'm going to quickly recap what I've read to make sure I understand correctly. You are looking for a resolution that allows the user to know something is happening (page loading, changes being applied, etc.) once the button is pressed, and to show how long they may have to wait with a status bar?
I understand that changing the text of the button to a spinning wheel can cause reflow issues as stated.
Changing the size of the button to allow for an added status element can cause UI issues as well by forcing elements on a page to adjust to the new format.

So based on this, I propose we integrate a loading status bar along the bottom of the button. It would remain within its constraints so as not to cause changes to other UI on the page and the original button text would remain. This is something I've seen sites like Vimeo, iMessage, and Gmail implement effectively.

I created a quick illustration above of what I mean.

[calebj7]

For the example above for "Logging In", you could even have the arrow wheel start spinning in addition to the status bar.
I'd be happy to animate a quick example of what I mean if that would be helpful!

[garusky]

As discussed in a triage a few days ago, I pointed out that this problem has already been solved in Gutenberg by adopting a hybrid solution with text and animation.
What I suggest is to remain consistent when we want to express a primary button's loading status.
This solution prevents the problems discussed above from @johnbillion.

I created a pen of the current core primary button merged with the animation state used in Gutenberg:

​https://codepen.io/garusky/pen/pZejYW

[joyously]

If we are talking about buttons only, I like the look of a progress bar at the bottom of the button, but it should be more visible (maybe the entire button?). The problem is that the progress will have to repeat or have a long animation time. The codepen example of diagonal stripes is good in that it doesn't have a beginning and end, but it also doesn't really indicate anything. It also looks backwards, since I'm so used to left to right meaning forward.

Regardless, it only solves buttons, not text links. As I typed this, I notice the spinner that appears as Trac updates the preview. It doesn't cause reflow, and it tells me there is action happening.