[wp-trac] [WordPress Trac] #37974: Add multi-panel feature to pages through add_theme_support
noreply at wordpress.org
Thu Oct 13 08:50:28 UTC 2016
#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
Ticket URL: <https://core.trac.wordpress.org/ticket/37974#comment:134>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac