[wp-trac] [WordPress Trac] #38426: Twenty Seventeen: Improve user and developer experience with the customizer integration
noreply at wordpress.org
Sat Oct 22 20:17:50 UTC 2016
#38426: Twenty Seventeen: Improve user and developer experience with the customizer
Reporter: celloexpressions | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: 4.7
Component: Bundled Theme | Version: trunk
Severity: normal | Resolution:
Keywords: has-patch dev-feedback needs- | Focuses: ui
testing ui-feedback ux-feedback |
Comment (by davidakennedy):
Replying to [comment:1 celloexpressions]:
Thanks for all the ideas and work here! Twenty Seventeen wouldn't be the
same without your contributions!
> [attachment:38426.diff] is a first pass based on my initial review. See
the screenshot above for the visual changes. Here's a technical summary
(roughly in the sequence of the patch, top-to-bottom):
> - Rename customizer JS files to `customize-preview.js` and `customize-
controls.js` to align with the core file naming and make it clearer where
each file runs.
> - Only show the `colorscheme_hue` control when there's a custom color
Also makes sense.
> - Update preview JS handling for revised front page section handling,
See below for my comments on this.
> - Remove all references to "Theme Customizer" in code
improvements-in-4-0/ It hasn't been called that since before 4.0].
> - Clarify the purpose of the JS files by updated the code comments in
the file headers.
> - DRY for the front page section JS.
> - DRY for registering front page sections. Unify and simplify the
corresponding loops used for front page section output.
The DRY approach is great, as are the comments explaining what's
> - Make the arbitrary number of front page sections filterable, for UI
registration and output.
I really like this addition, and it should help child themes.
> - Add selective refresh for widgets.
This has already been committed, so the next patch can remove this.
> - Rename the page layout section to "Layout", so that child themes and
plugins can add additional options that are relevantly grouped (see also
> - Rename `twentyseventeen_sanitize_layout` to
`twentyseventeen_sanitize_page_layout` to be clearer about what it
sanitizes in case child themes or plugins consider reusing it.
> - Rename `page_options` setting/control to `page_layout` as that's more
reflective of what that option does; and again, helps for potential
> - Make the page layout option contextual to pages and the sidebar being
inactive, as the option only applies when there is no sidebar (per its
> - Remove the generic "Theme Options" panel. Per the official
documentation (within a `strong`), themes should avoid adding panels.
There is no need to group multiple sections into a context here, because:
> - Condense front page panel controls into a single section. Per the
documentation, sections should generally contain multiple controls. The
purpose of sections is to group multiple, related controls together. These
controls all serve the same purpose, so they should be shown within a
single section. This also makes it clearer within the controls pane how
the different sections relate to each other.
> - Place the "Front Page Sections" section directly after the static
front page section, since they're related.
This part seems problematic – the change in location of the layout
control and front page sections. It's what I've meant by not waiting to
make huge UI changes. I agree with you that the sections themselves should
not be separate panels – especially since the Customizer documentation
advises against it.
However, moving everything to the top level creates problems in my mind.
1. The options have a potential to become muddled if more Core options are
added in the future.
2. A user has no way of knowing they're specific to the theme. I don't
think Twenty Eleven is a good example here because, if I remember
correctly, its Customizer options were added after the fact and tried to
mimic its options page. Grouping the options under Theme Options makes
sense and bundling the sections with page layout, combined with the active
callbacks should make sure only the relevant options show.
> - Integrate with the ability to create pages from a dropdown-pages
control in #38164.
This makes sense to do only if that ticket gets in. Otherwise, let's wait.
> - Add selective refresh for front page sections. This allows them to be
previewed much more quickly and without losing context. This also brings
"shift-click to edit" functionality, and soon visible edit icons via
#27403. This required some minor restructuring on the output side but
visitors should still see the same results. There is now a template tag
for displaying a front page section.
Makes sense – and something that should definitely be added.
> - Locate `active_callback` functions within `customizer.php` so that
they're easier to find when editing customizer registrations, similarly to
I like this. Makes total sense.
> - Remove the fancy borders styling for front page sections in the
preview. This prevents users from previewing an accurate representation of
the design within the customizer, and seems like something that's intended
to be on the frontend as a design element. Visual edit icons should
provide a nice alternative.
> - Adjust the styling for placeholders for panels that aren't active.
Show the placeholders when the front page section is expanded. This shows
the placeholder title (which feels more native to the theme design) and an
edit icon when appropriate, but hides the placeholders when not explicitly
working on the front page sections. This also allows us to simplify the
CSS and improve readability there.
I don't mind iterating on the design of the placeholders. However, this
change goes too far in the other direction for me. It looks exactly like
content to me. Content that might be displayed on the front end. Part of
the reason of the bold border colors was to provide an idea of "this is
temporary" to users. We could probably remove the borders after a page is
selected and base it on a timer – so users see it, but then know it won't
show up on the front end. Can we split out these changes to another
ticket? That way, it doesn't hold up any improvements here.
> I imagine we'll need a bit of back and forth to finalize the various
points here, but looking at the changes collectively, the resulting
experience is more inline with core recommendations for both users and
Definitely. I'm all for collaboration, as nothing amazing ever gets done
without it. Let’s both remain open to new ideas, perspectives, and
Ticket URL: <https://core.trac.wordpress.org/ticket/38426#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac