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

 Replying to [comment:124 celloexpressions]:
 > Abruptly deciding to pull something without allowing any opportunity to
 improve things or even bring it up in a weekly dev chat is ridiculous.
 From what I've seen this wasn't an abrupt decision. Looking at 4.7,
 there's a tight ship date, one fewer beta release, and lots of moving
 pieces. Making a decision to pull a highly visible feature is hard, but,
 as you know, it's ultimately one that the release lead should make as it's
 ''their release'' and they have the best overall view.

 > If something is broken on mobile why was that never reported before?
 As you know, feedback comes when it comes. We don't always get to choose
 the timeline of feedback from volunteers, part-time, or even full-time
 contributors.

 > A significant amount of time was spent designing and implementing a
 mobile experience and [https://make.wordpress.org/flow/2016/10/01
 /customizer-browse-install-preview-themes-on-mobile/ the flow was even
 documented on make/flow]. This feature is in much better shape than many
 other new features currently in trunk and has been requesting feedback for
 much longer, receiving very little until the past 24 hours.
 The amount of time spent working on the mobile experience is commendable,
 but if it's not complete, it's not complete. Additionally, "mobile" isn't
 the only issue with the feature right now. (See below.)

 While, subjectively, you can say this feature is much better shape than
 others, that's not necessarily true (again, see below) and it's something
 the release lead will have the best view of. Additionally, as you've seen
 contributing over the years, features advance at differing speeds and some
 are much easier to get release-ready than others. Personally, I agree that
 theme-install-in-the-customizer needs considerably more time to be
 release-ready.

 > The goal of this project has never been to fix the broader problems with
 finding a theme. It's been to fill a functionality hole that prevents
 users from discovering that you can even install themes besides the
 defaults. The experience in 4.7 beta 1 is significantly better than what
 was in 4.6, despite its quirks, and user testing has been published on
 make/design to support that. Issues with finding a theme here apply
 equally to the other theme installer in the admin, and most of the
 comments above are issues that have no direct correlation to filling the
 functionality hole in the customizer.

 The goal of any new front-end feature should be improve the user
 experience of WordPress in that given area. We shouldn't be doing features
 to "fill a functionality hole" without ''also'' working hard to improve
 the experience around that given area. In the case of installing new
 themes, improving discovery is very closely related. Could the two things
 be separated? Perhaps. But a new user experience will inherently want to
 drift toward improving both aspects. Put more simply: a new design opens
 up new possibilities for discovery that are worth exploring.

 > If there are issues with a feature during beta, report them and work
 through them, '''then''' if they can't be resolved consider a revert.
 Don't skip straight to that step without providing any chance to make
 improvements, especially when the primary concerns are easily fixable bugs
 and other concerns go beyond the scope and intent of the changes.

 I don't agree with your final statement here. As the commit message
 mentioned, there are fundamental issues with the UX of this feature. It
 doesn't ''feel'' right. Those fundamental issues take time to work out and
 explain; they need exploration and discovery to suss out and fix. Where we
 are in the cycle (beta), there isn't really time to address a fundamental
 issue; there's only time to fix minor bugs.

 Further, I don't think any of the other concerns mentioned are beyond the
 scope of the changes here. The work here should be to improve the UX
 around installing themes. When approaching a topic that large, everything
 should be on the table in the interest of making life better for users.

 > The way that this has been handled is frankly disrespectful and
 insulting to me, to the point that I am unlikely to contribute further
 until whenever a version of this is back in trunk.

 I'm sorry that this feature didn't make it for 4.7. Really, I was looking
 forward to a better user experience for theme installation and discovery.
 But the work we do, as contributors, should be to the betterment of
 WordPress overall. If you're not interested in working on getting this
 feature release-ready, I hope someone else is.

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