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

[WordPress Trac]

#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 celloexpressions):

 Thanks for going through each change with comments! See my responses
 below.

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

 I understand these points and they are issues, but they're actually much
 broader than this theme. The first thing to note is that in most cases
 this change will still leave only one top-level element added by the theme
 (and in many views there will be no top-level elements). I'd also propose
 not applying the layout option to the front page since it's a bit
 confusing in addition to the custom sections, which would mean there's
 only ever one at a time.

 In terms of separating theme-specific options from theme-agnostic options,
 the customizer traditionally intermixes these. Custom logo, header,
 background, and often color options are all theme-specific but not nested
 in anything indicating that they're theme-specific. All of the past core
 user testing for the customizer tends to be done with themes following the
 de-facto standard - sections labeled by their purpose (colors, layout,
 featured content, etc.). Because all of the core options follow this
 approach, grouping by purpose as opposed to source, the default theme
 should do the same.

 There is potential to re-think how it works in core, potentially even
 moving to a strategy where ''everything'' is grouped into panels, and all
 theme options need to be in the same place (including things that use
 `add_theme_support`). It's worth going back through the history here -
 #27406, #27591, #28979, #29172 (for order), #29173, #29197, #31336. Panels
 were originally a subclass of the section object, but later became
 distinct object (all in 4.0). I'll note as part of that that sections and
 panels had completely different "opening" actions at the time panels were
 introduced, and because the objects are entirely separate objects, there
 is potential to revisit distinct UIs for these when the customizer UI is
 reimagined in the future. The previous UI reinforced the notion that
 panels are distinct contexts whereas sections are UI containers for
 organizing controls; the current UI causes that to become more confused.
 As it is, custom sections and panels can use different UIs anyway, with
 the themes panel and sections being a good example in core. Bottom line,
 the current best practice and core behavior is to use sections describing
 their contents specifically; Twenty Seventeen should respond accordingly,
 but know that core will likely restruture things in the future.

 As a brief aside to that point, there's a pretty good chance that the
 entire thing that we currently know as the "customizer" will be completely
 re-imagined in terms of UI and UX as a front-end-native live-preview
 framework that facilitates managing a majority of a site (including
 content), in the next year or so. It would likely continue to use the
 customize API and inherit all of the theme and plugin integrations there,
 but it's especially important that themes avoid making decisions related
 to the specific way the different core customize UI objects are displayed
 since they're subject to significantly change over time.

 > > - 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.
 Fortunately, this is a one-line change with no impact if the core change
 doesn't happen. However, I'm pretty confident the core change is ready to
 go.

 > > - 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.
 Another idea I got as I was iterating on the approach was to only show the
 borders when the front page section is open, similarly to how the
 placeholders are only shown with the front page section (as part of the
 placeholder). What about adding that back in, then iterating on the
 colors/style (per @karmatosed) on #38399? The current approach still reads
 like a design element to me, not something that's only shown when you're
 customizing it. But only showing it when you're working on the UI might be
 a nice intermediate approach. My biggest issue with the borders, and the
 reason they're removed in the initial pass, is that the implementation in
 `:before` prevents users from interacting with the contents of the panel
 within the preview; in a default theme that's concerning as it may cause
 new users to think they can't interact with the preview and navigate their
 site within the customizer.

 Also, I don't think the borders were showing before something was selected
 in a given section, but that may have been a bug. Either way, we should
 continue iterating on the placeholders. Some changes (especially with the
 JS) are coupled directly with the other changes here but I'd expect
 further iterations on the other ticket. Another idea I had was to add a
 link to add front page sections within the static front page section, but
 I left it out for now for simplicity.

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