[wp-trac] [WordPress Trac] #40432: Customizer: Should we stop contextually hiding features?

[WordPress Trac]

#40432: Customizer: Should we stop contextually hiding features?
-------------------------+------------------------------
 Reporter:  melchoyce    |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Customize    |     Version:  4.0
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  ui
-------------------------+------------------------------
Changes (by celloexpressions):

 * focuses:   => ui
 * version:   => 4.0


Comment:

 I think this ticket is asking the wrong question and approaching the issue
 in what may not be the most effective way. When there are too many
 options, users are overwhelmed. When users can't find options, they are
 overwhelmed. Contextually hiding options solves one problem but makes the
 other worse, and removing the current functionality does the opposite. The
 experience still isn't great either way.

 To actually fix both problems, we need to look beyond the current
 assumptions. It was mentioned above that users don't think/know to click
 around to preview different aspects of their site. That's the point of the
 customizer, and something that we should work to encourage more actively.
 If user's aren't actually using the preview, there is of course no reason
 for them to be using the customizer. And they would of course be annoyed
 that it only takes up a small part of the screen because they aren't using
 the preview that takes up most of their screen. If we show options that
 aren't shown in the preview, we work against the whole purpose of the
 customization/live preview experience.

 We've already started placing more emphasis on the preview. Visual edit
 shortcuts are the first step there, and inline editing should follow soon.
 If we turn the approach to the experience the other way around -
 encouraging interaction primarily within the preview/on the site and
 treating the customize pane as secondary, the question of whether controls
 should be contextual within the pane is much less important. If control
 navigation is more fundamentally rooted in the preview, pane-based
 navigation could potentially be greatly simplified to only focus on global
 elements that aren't contextual to specific parts of a site. Pane-based
 navigation for widget areas doesn't really make sense because it's very
 disconnected from where those areas actually are on the site.

 I think it would be more productive to rethink this issue by focusing on
 the preview first, and then circle back to reworking how global
 contextuality should work.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40432#comment:36>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform