[wp-trac] [WordPress Trac] #38426: Twenty Seventeen: Improve user and developer experience with the customizer integration

Sat Oct 22 20:17:50 UTC 2016

#38426: Twenty Seventeen: Improve user and developer experience with the customizer
integration
-------------------------------------------------+-------------------------
 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.

 Makes sense.

 > - Only show the `colorscheme_hue` control when there's a custom color
 scheme.

 Also makes sense.

 > - Update preview JS handling for revised front page section handling,
 see below.

 See below for my comments on this.

 > - Remove all references to "Theme Customizer" in code
 comments.[https://make.wordpress.org/core/2014/07/08/customizer-
 improvements-in-4-0/ It hasn't been called that since before 4.0].

 Thanks!

 > - Clarify the purpose of the JS files by updated the code comments in
 the file headers.

 Awesome.

 > - 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
 happening.

 > - 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
 Twenty Eleven).
 > - 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.

 Makes sense.

 > - Rename `page_options` setting/control to `page_layout` as that's more
 reflective of what that option does; and again, helps for potential
 extensions.

 Makes sense.

 > - 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
 description).

 Awesome!

 > - 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
 sanitize callbacks.

 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
 developers.

 Definitely. I'm all for collaboration, as nothing amazing ever gets done
 without it. Let’s both remain open to new ideas, perspectives, and
 experiences here.

 Thanks again!

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