[wp-trac] [WordPress Trac] #37974: Add multi-panel feature to pages through add_theme_support

[WordPress Trac]

#37974: Add multi-panel feature to pages through add_theme_support
-----------------------------------------+------------------
 Reporter:  karmatosed                   |       Owner:
     Type:  task (blessed)               |      Status:  new
 Priority:  normal                       |   Milestone:  4.7
Component:  Themes                       |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  has-ux-feedback needs-patch  |     Focuses:  ui
-----------------------------------------+------------------

Comment (by NateWr):

 I think that many of the concerns Helen raises regarding the relationship
 between a Page and it's Sections (page slugs, indicating the relationship
 in the admin list of pages, how menu links work, how page slug changes
 effect how menus work, etc) are much easier to resolve if we stick to
 using child pages of the Front Page as sections. I'm still not sure why
 this was rejected before. It reduces much of the confusion about how a
 Page Section should exist beyond the Page it's on, and the Pages admin
 list table already displays the relationship.

 On a separate note, some thinking still needs to happen about how this
 feature is encountered on a fresh install. Each mockup and demo so far has
 assumed that there already exist multiple pages in the system. But an
 initial install only adds the Sample Page. Once this is set to the Front
 Page, there are no more pages which can be located and added. This means
 that many people's first encounter with this feature will be to click the
 Add Sections button, open the search panel and be presented with 0
 results. I think there needs to be something here which helps users
 understand what they're looking at.

 This is another reason to consider keeping the "Page" label in the list of
 sections to add. Without this, we're introducing brand new terminology
 ("Frontpage Sections") without giving the user any indication of what they
 are, where they exist or how the user can go and edit them.

 And I really feel that this may just scratch the surface of the UX
 problems of this control. For one thing, building this into what is
 already probably one of the worst NUX experiences (the Static Front Page
 setup, see #16379) could be something we regret.

 I'd like to suggest that for 4.7 this feature be bundled with
 TwentySeventeen rather than rolled into core, with the goal being to
 refactor this into a more generic Post Collection customizer control that
 can go into 4.8. The benefits of this approach are:

 1. We don't prematurely commit to code with a very limited use-case and
 almost no user testing.
 2. TwentySeventeen can still ship on time with it's awesome design and a
 good prototype for controlling the homepage.
 3. We get a solid few months of user testing in the wild, with everyone
 from experienced developers to brand new users, to help identify pain
 points in the current implementation.
 4. We have enough time to leverage interest in TwentySeventeen and this
 ticket to deliver meaningful, long-term improvements to the customizer
 API: re-usable code for managing slide-out panels and a generalizable
 control for selecting and adding collections of posts.

 Once we have these improvements in core, TwentySeventeen can be refactored
 to take advantage of them and the remaining bits (`add_theme_options`, URL
 redirection, etc) can be added to core as a small layer on top of the more
 generalized functionality.

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