Make WordPress Core

Opened 8 years ago

Last modified 3 years ago

#35186 new enhancement

Put the Customizer "back" button next to the "Close" button

Reported by: dragonflyeye's profile DragonFlyEye Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.4
Component: Customize Keywords: needs-patch needs-design
Focuses: ui, accessibility, javascript Cc:

Description

Seems like a pretty small thing. The "Back" button that takes you to the top of the Customizer menu scrolls out of view but the "Close" button does not. If we put the Back button next to the Close button, it would be slightly less confusing.

Attachments (8)

customizer-back-redesign-thin-i1.png (33.8 KB) - added by folletto 8 years ago.
Customizer Back Redesign - 'Thin' i1
customizer-back-redesign-xswap-i1.png (35.9 KB) - added by folletto 8 years ago.
Customizer Back Redesign - 'X-Swap' i1
Customizer-sticky-close-button.png (903.7 KB) - added by paaljoachim 6 years ago.
Customizer sticky shows close button.
Customizer-sticky-back-button.jpg (170.8 KB) - added by paaljoachim 6 years ago.
Customizer sticky show back button.
1.png (121.9 KB) - added by Travel_girl 6 years ago.
2.png (114.2 KB) - added by Travel_girl 6 years ago.
customizer-navigation-rethink.png (26.9 KB) - added by jipmoors 6 years ago.
re-evaluate control placements
customizer-buttom-bar.png (847.6 KB) - added by jipmoors 6 years ago.
alternative placement of desktop/tablet/mobile-preview controls

Change History (57)

#1 @SergeyBiryukov
8 years ago

  • Keywords needs-screenshots added

#2 @DragonFlyEye
8 years ago

Notice how, when I scroll down a bit, the back button scrolls past the top of the screen. As the Customizer gets more heavily used, it is inevitable that this will be a more common problem.

http://holisticnetworking.net/allsorts/customize-back-button.png
http://holisticnetworking.net/allsorts/customize-back-button-gone.png

#3 @DrewAPicture
8 years ago

  • Keywords has-screenshots added; needs-screenshots removed

#4 @westonruter
8 years ago

  • Focuses javascript added
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.5

I agree. When inside of a panel or section, the back button could slide out from under the Close button to reveal itself. This button would change the current expanded section, or it there is no expanded section, it should collapse the current expanded panel. For example, the logic that clicking the button invokes could include:

var wasCollapsed = false;
api.section.each( function( section ) {
    if ( section.expanded() ) {
        wasCollapsed = true;
        section.collapse();
    }
} );
if ( ! wasCollapsed ) {
    api.panel.each( function( panel ) {
        if ( panel.expanded() ) {
            panel.collapse();
        }
    } );
}

#5 @celloexpressions
8 years ago

We should of course also keep in mind that the back button was originally on top of the close button, but was moved to the unified section/panel headers for clarity. We should probably keep that one if we add a conditional back button, but need to be careful about taking up too much space in the top bar with translations if we add another back button next to the close button.

#6 @DragonFlyEye
8 years ago

Space is important. But put me down for basic usability as a primary motivator. Could the icons and buttons maybe be made smaller? And eliminate the text, so that translation is taken off the table (I think?) as a mitigating factor?

#7 @bluestan
8 years ago

Could we just stick the panel/section header area on top when scrolling down? So we can click the back button without scrolling up, and also know which section/panel we are editing.

https://i.gyazo.com/06ee3adb1450a6133b8902da0a321a84.png

Last edited 8 years ago by bluestan (previous) (diff)

#8 @celloexpressions
8 years ago

I like the idea of sticking the header a bit better than adding another close button. But vertical space is a concern - there would need to be a min-height at least. @folletto may have thoughts too, since he did a lot of the UX work for the headers/sliding panels navigation.

#9 @folletto
8 years ago

Thanks for pinging me. I think that both the issue of the ticket and the concern about a too-high header are valid. The current design was formed when this wasn't a constraint, but it's totally correct that in the future it will be more and more relevant.

We might revert to one of the original ideas, which now gains favor I think, which is to have the × convert to ← when the user is down one level. I'm concerned about the user getting out of the customizer just by repeadetly tapping back, but might me marginal. If possible, we can give it a try and see how it behaves.

@folletto
8 years ago

Customizer Back Redesign - 'Thin' i1

@folletto
8 years ago

Customizer Back Redesign - 'X-Swap' i1

#10 @folletto
8 years ago

I made two quick concepts:

  • 'Thin' will mean sticking the bar at the top, making that just slimmer. A very basic approach.
  • 'X-Swap' breaks a bit the separation of concerns in terms of hierarchy, but I feel could work really well.

#11 @melchoyce
8 years ago

customizer-back-redesign-xswap-i1.png feels like a good approach — I think we should test it out and see how it works in practice.

#12 @chriscct7
8 years ago

  • Milestone changed from 4.5 to Future Release

Punting to next release per discussion with @westonruter

#13 @westonruter
8 years ago

See related #22237 (Add keyboard shortcuts for collapse/expand, panel-back, and close to the Customizer)

#14 @celloexpressions
8 years ago

Noting that the x-swap UI was used previously, but we moved away from it for a reason that I don't remember. #31336 should have that discussion somewhere.

#15 @folletto
8 years ago

I can't find the previous mention, but if I recall correctly we preferred the current choice because:

  1. It was a smaller change from the UI we had at the time, there were already lots of changes happening
  2. Users might click a few times on "back" and end up triggering the close by error.

I think we already show a popup message to "navigate away" if one tries to close the customizer when there are unsaved changes. That is already enough to avoid the frustration, it's just a bit annoying since it's a popup, but we can then improve that with a custom UI later.

#16 @lgedeon
8 years ago

I concur that the popup message is sufficient to prevent hitting back one-time-too-many.

Removing the "You are customizing" / "customizing" text is a nice to have and will likely be the route used in Customize Posts plugin, but for core it is probably fine to just change x to < and let the rest scroll away.

#17 @westonruter
8 years ago

Perhaps duplicated by #34343.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


8 years ago

This ticket was mentioned in Slack in #design by celloexpressions. View the logs.


8 years ago

#20 @paaljoachim
8 years ago

I really like the wireframes from @folletto.
A back button and a preview button next to it looks real nice.

One would easily toggle between edit and preview mode.

This ticket was mentioned in Slack in #core-customize by folletto. View the logs.


7 years ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 years ago

This ticket was mentioned in Slack in #core-customize by folletto. View the logs.


7 years ago

This ticket was mentioned in Slack in #core-customize by delawski. View the logs.


7 years ago

#25 in reply to: ↑ description @ctienshi
7 years ago

Can i know whether a patch is available for this ticket?

#26 @westonruter
7 years ago

In 38853:

Customize: Add sticky headers for panels and sections.

Includes autoprefixing of CSS.

Props delawski, celloexpressions.
See #35186.
Fixes #34343.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


6 years ago

#28 @celloexpressions
6 years ago

  • Keywords close added

Now that panel headers are sticky, there is a reasonably-accessible back button in most cases that likely negates the benefits of putting a back button back over the close button. I suggest closing this ticket unless anyone still feels that adding another button would be helpful.

#29 follow-up: @folletto
6 years ago

Now that panel headers are sticky, there is a reasonably-accessible back button in most cases that likely negates the benefits of putting a back button back over the close button. I suggest closing this ticket unless anyone still feels that adding another button would be helpful.

I don't think it negates the benefits. As I mentioned above, the "sticky" option (ideally, paired with a slimmed header, not the full height header) was meant to be a simple one to address the issue at hand, but the "x-swap" design seems a more effective solution if it works as it would reduce complexity as well as some of the confusion.

From the discussion above it also seem that 4 people agreed in going for the "x-swap" approach.

Would be possible to test a patch with the "x-swap" design and see how it performs?

@paaljoachim
6 years ago

Customizer sticky shows close button.

@paaljoachim
6 years ago

Customizer sticky show back button.

#30 @paaljoachim
6 years ago

I just added a Featured Section that shows the sticky close button.

https://core.trac.wordpress.org/raw-attachment/ticket/35186/Customizer-sticky-close-button.png

As the user scrolls the back arrow is hidden and the close button and saved button row becomes a sticky. It is very easy for a user to click the close button when they are finished with specific panels. It would be good to swap the close button to a back button on sticky (when the back button becomes hidden.)

Here is an example with a back button and the description.
https://core.trac.wordpress.org/raw-attachment/ticket/35186/Customizer-sticky-back-button.jpg

#31 @westonruter
6 years ago

  • Keywords close removed

#32 in reply to: ↑ 29 @melchoyce
6 years ago

Replying to folletto:

...the "x-swap" design seems a more effective solution if it works as it would reduce complexity as well as some of the confusion.

From the discussion above it also seem that 4 people agreed in going for the "x-swap" approach.

Would be possible to test a patch with the "x-swap" design and see how it performs?

I'm a little skeptical (mostly because we tried this in an experiment .com and I ended up exiting the Customizer a lot by accident) but I'm always up for us testing a patch and seeing how it works, if someone has the time 👍

#33 @folletto
6 years ago

I think it's skepticism well placed. I'm not 100% sure, but I think the issue happened because before we didn't have a warning when one tried to leave. Now we have it, that's why I'm hopeful that it should work this time. :)

#34 @Travel_girl
6 years ago

Personally I'm not convinced with the solution to swap X and < depends on the level, because that could be confusing for users and there have to be more aware in which level there are.

It also needs more steps to get out of the customizers and some themes have many levels in the customizer, so you may need 4 clicks to get out.

I like the solution from @bluestan and would add the idea to remove the "You are customizing" and just show the level you are in (like Colors) and make this part sticky. In this way the area is thinner and don't take too much space, but the important information and function is still there. (Screenshot 1).

An other option I think about is, to arrange the back and close button next to each other. I personally would prefer to have the back button at the left corner, because this button is not so "dangerous", so I think this could reduce accidently clicking the close button. The close button could be on the right site of it. (Screenshot 2)

@Travel_girl
6 years ago

@Travel_girl
6 years ago

#35 @westonruter
6 years ago

  • Keywords ux-feedback added

#36 @grapplerulrich
6 years ago

I was chatting with @Travel_girl and mentioned that I have closed the customizer a number of times because the back button has disappeared when I have scrolled down for further settings.

I agree with @Travel_girl that we should not use the "x-swap" design as it is difficult to remember the level you are on when switching the panels. I don't agree that the back button should be on the inside. I feel that I can remember that close is on the outside like it is on many different blocks. For example the window on a computer.

#37 follow-up: @folletto
6 years ago

I like the solution from @bluestan and would add the idea to remove the "You are customizing" and just show the level you are in (like Colors) and make this part sticky. In this way the area is thinner and don't take too much space, but the important information and function is still there. (Screenshot 1).

Yep, this matches the "Thin" concept (see here for mockup). It's definitely a good option.

as it is difficult to remember the level you are on when switching the panels.

I'm sorry, I'm not sure I understand why this is a problem in practice.
Why would it matter knowing the level you are on? Wouldn't people click until they see they screen they want to be?

#38 in reply to: ↑ 37 @Travel_girl
6 years ago

I'm sorry, I'm not sure I understand why this is a problem in practice.
Why would it matter knowing the level you are on? Wouldn't people click until they see they screen they want to be?

I have noticed, that users who are used to a specific interface, they don't read or check before their click a button. Also with pop ups and stuff like that, that we see more often.

If now the interface change depends on specific factors (like level status and so on) , users have to keep more attention and that could create a bit frustration and false clicking (for example that happens to me all the time with "Save" and Publish" button for posts).

In this specific case it would not be a wrong button, but I could imagine that users who click the "<" button, but original meant the "x" button could be confused for a sec, why the customizer isnt closed. Than their would release, there have just changed the level and keep clicking. Of course this is just a tiny irritation, but I thought still worth to mentioned.

#39 @folletto
6 years ago

Thank you :)

@jipmoors
6 years ago

re-evaluate control placements

#40 @jipmoors
6 years ago

I tried to let go of the current implementation a bit and re-evaluate what controls are actually there and how they are implemented in other places.

I realize this is a radical change, and I mostly like to widen the discussion to the entire sidebar.

Reasons for placement
Every dialog or modal has the [ X ] button placed on the top-right.
This prevents accidental closing and is still in the first-context scan (on left-to-right languages).

The back-navigation is generally placed on the top left (look at the browser you are using, or any i-device).
When a user is looking for a specific setting to adjust, they might need to visit different sub-option-pages to actually find it, so quick navigation is desired.

After finding the setting and adjusting it, the last step is to save it, so placing the "Save" button at the bottom is following the flow the user is in.
Having to go back up is a reversal of direction, thus costing more energy/focus to do.

The desktop/tablet/mobile-preview buttons are in a strange location
I struggle with the placement of the buttons, as they are a different order than any other controls in this sidebar.

@jipmoors
6 years ago

alternative placement of desktop/tablet/mobile-preview controls

#41 @jipmoors
6 years ago

More food for thought on the controls.
As I mentioned the controls for the desktop/tablet/mobile-preview were feeling out of place in my concept.

I understand and agree with anybody noting that reducing more screen-estate is a bad idea, this concept is to show that having the controls of the preview closer to the element that will actually change reduces the cognitive load a user needs to be able to use it.

Whenever the bottom bar would remain visible after clicking the "hide controls", keeping the "save" button while previewing could also reduce the amount of clicks/work a user has to do after changing settings and verifying that it looks as expected.

#42 @afercia
6 years ago

  • Focuses accessibility added; administration removed

From an accessibility perspective, I've mentioned several times on other tickets the main issue is about the initial focus and placement of the UI controls. The initial focus is on the "back" button, thus everything that comes before ("X" close and Publish) is basically "skipped".

For keyboard and screen reader users (and also on mobile), navigation through content is a linearized experience. Skipping content doesn't help. as some users won't have a clue there's some content before the point where their navigation experience starts. This actually hides content for some users.

One more main concern often mentioned is about the Publish button on the top. While I understand that it's visually very prominent, it's not ideal in a linearized navigation experience. Just use your keyboard, land on a panel, do your edits, and now... oh no, now you have to tab backwards to the top to press the Publish button (assuming you've previously discovered it's placed there at the top).

These main issues were never addressed properly and maybe it's time to think to some more radical change to improve the interface for everyone.

I'd suggest everyone to completely forget for a while the visuals and think at the document structure in a linearized experience. What users really need in such a scenario?

  • I land in a panel, as first thing I need to know where I am: "Panel xx dedicated to bla bla"
  • then I should have the ability to go back (if not interested in this panel), close, or continue
  • following a WordPress pattern, then I should find the Help and Settings
  • then all the controls to edit stuff
  • when I'm done, then I should find the Publish button
  • after Publishing, then I'd be at a dead end: I'm at the bottom of the sidebar and to go back or close I should tab backwards through all the sidebar... not ideal. Maybe Back and Close should be moved (or duplicated) at the bottom

This way, a typical workflow would be something like:

You're in panel xx and here you can do bla bla > Go back > Close > Help > Settings > all the controls here > Publish > Go back > Close

Re: the "x-swap" design I'm afraid it could be potentially confusing for users. I'd recommend to keep things simple. Avoid fancy things and just use one control for on action. Simplicity is the best guarantee to build a user interface that can be used by everyone.

#43 @grapplerulrich
6 years ago

I like the new ideas. It would be interesting to do some user testing to see how they fair for new users. Existing users may not initially like as we are moving the buttons.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


5 years ago

#45 @JoshuaWold
5 years ago

We just discussed this issue today in the #design team's triage sync. Our consensus:

  1. It'd be awesome if we could see some interactive prototypes proposed. It's hard to gauge the best option based on a static image (although that is of course really helpful).
  2. Having user testing on this could also provide some wonderful insight.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


4 years ago

#47 @karmatosed
4 years ago

  • Keywords ux-feedback removed

As this has feedback, going to remove ux-feedback keyword for now.

#48 @dlh
4 years ago

#49578 was marked as a duplicate.

#49 @celloexpressions
3 years ago

  • Keywords needs-design added; has-screenshots removed

This needs a new design that prioritizes accessibility as outlined in 42. Accessibility is the most important consideration, and may be the only compelling reason to make a change here.

The solution here may involve only showing a close button (and also publish?) on the top level. It likely also includes a way to navigate back (and publish) at the end of each section and panel to improve linear navigation flows.

The "X-swap" concept discussed above was previously a part of core. It was removed because of the hierarchy concerns noted above. Even with precautions in place now to avoid closing without saving changes, this seems like a jarring experience. The "thin" concept above could be used as inspiration for the visual design, but needs to address accessibility.

Note: See TracTickets for help on using tickets.