[wp-trac] [WordPress Trac] #37661: A New Experience for Discovering, Installing, and Previewing Themes in the Customizer

[WordPress Trac]

#37661: A New Experience for Discovering, Installing, and Previewing Themes in the
Customizer
-------------------------------------+-------------------------------------
 Reporter:  celloexpressions         |       Owner:  westonruter
     Type:  feature request          |      Status:  reopened
 Priority:  high                     |   Milestone:  Future Release
Component:  Customize                |     Version:  4.2
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-           |     Focuses:  ui, accessibility,
  screenshots needs-testing has-     |  javascript
  user-testing has-ux-feedback       |
-------------------------------------+-------------------------------------

Comment (by celloexpressions):

 Replying to [comment:129 helen]:
 > Replying to [comment:125 westonruter]:
 > > @helen Can the revert be reverted if patches for the outstanding
 issues get included?
 > ...
 > And beyond the issue of what exactly the problems are or aren't, there
 is the matter of what project and release priorities are. My priority for
 this release is and always has been the site set up process '''starting
 after the point where a theme has been chosen'''.

 If all of core development is restricted solely to the priorities of the
 release lead, we're going to significantly limit the potential to make
 improvements in the short or long term. The role of component maintainers
 offers a way to coordinate short and long-term priorities of a particular
 part of core with the goals for a particular release. This project has
 been on the roadmap for nearly two years and 4.7 was our best window for
 addressing it. Punting means that for the customize component, we need to
 find new owners for this project that have availability in a future
 release as well as dedicating resources to continuing to carry the burden
 of a massive pending patch that takes a lot of effort to keep refreshed
 with trunk and hold off other projects until it's in trunk, rather than
 being able to iterate on the base functionality in core. It also delays
 the ability to start work on other initiatives and delays the broader
 roadmap for the customize component because of resource limitations.

 > Finding a theme is and remains a large problem that goes beyond figuring
 out where to go in the admin to install new ones, and if we have to punt
 this feature from this particular release, I think that's what makes sense
 for this project.

 The notion that this is something that could or should be considered as a
 single project within the scope of a single release, or exclusively within
 core is flawed. As is done elsewhere, an iterative approach will be
 necessary to ensure that users see improvements as they're ready and to
 avoid tying technical constraints and user experience work too closely
 together.

 To minimize the technical limitations, my recommendation is to revert
 [39140] as soon as 4.7 is branched (ie, before the holiday lull). That
 would make iterations on the UX much more feasible within the 4.8 timeline
 and minimize the broader impacts throughout the component, although I will
 note that this approach still wastes a significant amount of time and
 hurts users over shipping an initial version with 4.7. This would also
 facilitate allowing for broader feedback.

 > We need to be able to disagree about process and decisions without
 losing productivity in other areas, which is happening here. I do not want
 to put more time into this for 4.7 because it does not make sense given
 the whole view, which is another part of why I did not artificially delay
 the revert.

 Disagreeing on process is one thing, feeling disrespect is another.
 Breaking from established processes and favoring certain projects over
 others for individual personal reasons has the potential to significantly
 demotivate contributors. When dealing with volunteers, expecting this to
 have no correlation to willingness to contribute is not realistic.

 Perhaps because you were not fully aware of the integration of this
 feature with several other things happening with the customizer in 4.7,
 reverting has resulted in what will likely be more work overall to clean
 things up for release than if we shipped a usable if not perfect
 experience with the bugs fixed. Again, leveraging the role of component
 maintainers to assess the status of individual projects would have allowed
 the impacts of a revert - not just a punt but a revert and punt - to be
 fully considered before recklessly dictating a decision. Abruptly
 reverting the change after only one beta also starves this project of
 much-needed feedback - especially considering the persistent lack of
 specifics around the usability challenges that are being indicated as the
 reason for reverting it.

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