[wp-trac] [WordPress Trac] #34923: Introduce basic content authorship in the Customizer

[WordPress Trac]

#34923: Introduce basic content authorship in the Customizer
-------------------------------------+-------------------------------------
 Reporter:  westonruter              |       Owner:  westonruter
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  4.6
Component:  Customize                |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch has-patch    |     Focuses:  ui, accessibility,
  ux-feedback ui-feedback needs-     |  javascript
  testing                            |
-------------------------------------+-------------------------------------

Comment (by celloexpressions):

 Note following up on the discussion in #design,
 [attachment:34923.ui.1.diff] can and should be tested for the UI (without
 needing the plugin), but don't hit save & publish as the menu items aren't
 real. Delete them before saving.

 @westonruter I don't think a post type parameter would be appropriate here
 because it's basically an extention of `show_in_nav_menus`, with a
 specific part of that UI. Generically showing it in the customizer in the
 context of customize-posts would mean something different and shouldn't
 necessarily be tied to the menus interface as well (in addition to not
 being appropriate for core yet; this would presumably be more related to
 being able to edit content in the customizer I think, and should be saved
 for that future use). So I think the best behavior would be for it to be
 on by default, but able to be disabled with a filter so that core types
 could also be disabled if desired.

 @mapk (and everyone who participated in the design chat): the placement
 when adding to the list of menu items will be tricky. However, if it's
 added to the bottom of the list it will ''always'' trigger an infinite
 scroll, for each item added, and as a result the new items wouldn't be
 next to each other. The best option is probably to insert them at the top
 so that they're all together. Since this would cause the list to jump down
 anyway, it should probably auto-scroll to the top when this happens (but
 that would only happen once if multiple consecutive items are added).
 Since this is designed to be most useful during the site setup context,
 this decision won't ultimately matter too much since these would be the
 first items in the list.

 Regarding a separate step to add to menu, I think that would be excessive,
 similar to [comment:13]. Since the primary flow here is to create items so
 that they can be added to the menu, auto-adding to both places is probably
 the most appropriate action. If it were a two-step process this flow would
 become fairly cumbersome, especially for keyboard-only users, but also
 with touch, especially when adding multiple items at a time. Since we're
 targeting the site-setup flow primarily, auto-add to the menu is probably
 the best approach, and there is an existing workflow to remove (and bulk-
 remove) items from there if a user changes their mind. I would also guess
 that new users would have trouble understanding the additional step of
 adding to a menu, based on previous user testing with the old and new
 menus interfaces (we should user-test that).

 @afercia My thought in terms of accessibility would be to move it to the
 top of the list in tab order but keep it at the bottom visually. Infinite
 scroll is definitely an accessibility challenge here; pretty much the only
 way to sanely navigate the available menu items panel is to tab back up to
 collapse the section before moving to the next one, and putting the input
 at the top in terms of the html structure would make that easier from
 there. Perhaps a bit disorienting to jump like that, but probably better
 than the alternative.

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