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

WordPress Trac noreply at wordpress.org
Mon May 22 22:26:52 UTC 2017


#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
-------------------------+------------------------------

Comment (by westonruter):

 Replying to [comment:36 celloexpressions]:
 > 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.

 It's good that you raised the issue of local vs global content. This is
 something that @melchoyce and I have been talking about being a key
 challenge that we'll need to tackle in the interface. For example, how can
 a user be clued in that a given element is only shown on a particular page
 (e.g. featured image) versus an element that is shown on every page (e.g.
 header image). How can they be clued in that a widget area is used on
 every page template versus a widget area that is only shown on the search
 results template?

 The local vs global distinction then brings us to scalability concerns for
 controls: changing the page template would have a local scope vs global
 scope, but we wouldn't be showing in one customizer section listing out
 controls for the the page templates for every single page that you may
 have on a site. Discoverability seems to be the central problem here.
 Users may not feel it is intuitive to navigate around the preview to
 discover controls related to different areas of the site, while at the
 same time listing out all possible controls for every single setting on a
 site regardless of the context will hurt discoverability due to users
 being overwhelmed with a huge number of options (e.g. theme options admin
 pages).

 So it seems like there is some third way in between these two. I don't
 know what it looks like. I recall talk of being able to “zoom in” and
 “zoom out” as a metaphor to work on local vs global settings, which would
 then possibly be a way to seamlessly access the post editor during
 customization, but this is an area that needs a lot of design work.

 /cc @melchoyce

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


More information about the wp-trac mailing list