[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):

 Replying to [comment:4 karmatosed]:
 > - Do we really want to refactor like this to something at this stage
 that is so large and hasn't been user tested? I'd suggest we shouldn't.
 Yes, and I'm willing to coordinate user testing here to evaluate the
 overall customization experience with the theme. The timing is a
 consequence of circumstances that can't be avoided, as discussed in Slack.
 We also don't have any public user testing at all here yet.
 > - Front page sections is used as title... are we in this theme now only
 limiting to front page? I thought the current setup allows us to have not
 just front page.
 As far as I can tell the theme has it for front-page only. The template
 part is being called from there, but if it's also somewhere else we can
 adjust that.
 > - I am very against yet another option for layout. That shouldn't be the
 case to have to add it in.
 The layout option is existing, it's moved to be easier to find now. The
 section is also more generic so that child themes and plugins can add
 additional options if they'd like to without fragmenting the experience
 with a separate section.
 > - The amount of top level options is overwhelming. I am starting to
 really feel we're heading towards a 'Paradox of choice' and again without
 user testing can't be sure. There are valid cases for having sub panels
 when you have so many top level items. Yes, you shouldn't hide everything,
 but there's a balance. Having so many things in one top level is
 overwhelming for most users.
 In most cases there will only be one custom top-level section here.
 Currently a static front page would have two, although I don't know if the
 layout option should apply on the front page; if we removed that there's
 only one or none on any given view in the preview. Please note that panels
 are explicitly not to be used for the sole purpose of adding hierarchy,
 which is why we have separate panel and section objects; reference the
 official documentation linked above. Excessive (and in this case
 unnecessary) hierarchy can cause equal or worse issues to having to many
 sections in the first place, but themes should be able to add one or two
 sections without overwhelming users. If that's an issue we need to look at
 improving that in core; there were a few ideas floating around when panels
 were introduced in 4.0 that could be revisited now.
 > I have strong issues with this approach outside of my comments above,
 however I would advise us to not change the UI or UX of the current
 experience now it is in. We can iterate outside in a feature plugin for
 multi-panel. #37974 shows that and that should continue as a plugin.
 The functionality isn't changed much, however the code is simplified to be
 more appropriate for a default theme. It's still four dropdown-pages
 controls, and there are some adjustments to the way they're previewed. As
 far as I can tell you're most concerned about simplifying the sections,
 but the core philosophies inform us to strive for simplicity. Looking at
 it objectively there is less UI with this approach and less unnecessary
 repetition.

 A significant part of the changes is to add the UX benefits of selective
 refresh (which will also bring visual edit icons, see #27403), and another
 part of it is to make it possible to preview these areas in the way
 they'll be displayed on the front end (removing the borders and
 contextually showing placeholders). This is one of the areas where we have
 options on the specifics and could do something in the middle if desired.

 Another general comment here - there was originally conern about
 consolidating the panel-registration code to loop through the four
 identical options because of the complexity it would add to the theme.
 However, digging thorugh the way this is implemented, there was actually
 much more complexity with the front page feature in the templates and the
 customizer implementation. [attachment:38426.diff] tries to find a middle
 ground there in terms of balancing developer and user experience, and
 supporting selective refresh is a great way to do both.

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