10 Comments

  1. Nick Halsey

    Thanks for highlighting this, Jeff. There has been very little visibility for this feature in general, and additional ideas for moving the project forward are valuable. The real reasons for reverting are somewhat ambiguous but tied more to the overall user experience as opposed to the four bullet points you list (which are all minor and easily fixable).

    In terms of process I think the discussion on the ticket highlights the problems with inconsistencies in the development process. When decisions are seen as sudden or authoritative, contributors have the potential to be demotivated. And that’s something we should work to avoid as a project, by being transparent when establishing processes and making decisions.

    Part of the bigger picture here is that this feature has been on the roadmap for almost two years, but no one has been able to work on it previously. I finally sat down and made a concerted effort to put together something functional, and spent two months requesting feedback, testing, and iterating. I ran, recorded, and published (on make.wordpress.org/design) eight user tests, as well as publishing a record of the mobile flow for review. Even though these are written requirements for feature projects to be merged, this was the only feature to take these steps in 4.7. In all, I volunteered hundreds of hours to this project over the past four months. I followed written processes as much as possible and the feature was approved for merge (and merged), before the recent revert. Knowing that my personal availability (particularly during traditional work hours) will be limited after 4.7, I am unlikely to be able to push this feature forward significantly in the future, so hopefully newer contributors are interested in taking the lead here moving forward.

    Report

  2. David Decker

    With all necessary respect for both “sides” here, in my opinion the reverting of this feature was the right decision.

    Also, stuffing the Customizer with even more features in this tiny little area is a thing that should be debated more in general.

    When the theme search isn’t working any good on WordPress.org at all, why should this even land in the Customizer. Just makes no sense.

    For years, it is not possible to search for specific Child Themes for example. If you want ALL Child Themes in the repo for, let’s say, Twenty Sixteen, you won’t find them. You only will find those, that have the term “Child Theme” somewhere in their (child) theme description field. But a lot of authors forget that or whatever.

    Please please, fix the search and filtering of themes first, and then discuss any features to bring theme search/filtering to more places into WordPress core.

    And if fixing the filter function is not possible or not wanted then please give a full text search that would be worth this name!

    Report

    • Fatima

      My thoughts exactly. Searching on WordPress.org is a massive PITA and we need better filtration options. Sticking that interface into the Customizer (which in my opinion is already overloaded) isn’t a good idea.

      Report

  3. Tada Burke

    I applaud and thank anyone who contributes their hard work—whether it’s a Lead’s decision, patch or community feedback. That said, I’ve personally thought the ability to switch themes in the Customizer is a “hmm, okay” concept. An acre of real estate is being neglected in `wrap > theme-browser` via `themes.php` respectfully. There’s a convenience factor jamming mucho into El Custo, but this orphans pre-existing screens/components which could better escalate on-boarding, e.g. capturing intent (switching themes) only via themes.php first, then contextually scale upon that acquisition inside Custo’s guts. It can get a bit squishy & schizoid once you’re inside Custo, so maintaining focus on 1 theme should be the only task. Just my silly opinion :) P.S. I also applaud people who can stomach long-winded Trac tickets …my eyes go dry and brain implodes.

    Report

  4. Robert

    Frankly, I doubt many will miss this feature…

    Report

  5. Rick Gregory

    There are two issues here. One is whether the feature should have been pulled. I can’t comment on that. The other is the “it’s their release” comment…. it may be the release lead’s call but that does not excuse them from communicating to the people who are primarily working on that feature about what’s going on, what decision is being made and what the next steps are. If there were deeper concerns, those should have prevented it from being in b1 too.

    Being a lead means more than being technical. Team communication is key.

    Report

    • Joachim

      I completely agree with this.

      While I do agree that it’s the right decision to pull a feature that obviously hasn’t been properly tested before merge, the fact that it was included in b1 is a symptom of poor management/communication.
      This needs to be acknowledged so it can be prevented in future releases. Learning from these mistakes will only improve WordPress in the long run.

      Report

  6. Chuck

    IMHO Customizer is for just that – current theme customization. Theme selection needs to be better, but it needs to be somewhere else. There also needs to be a refactoring of the way themes are organized and tagged on wordpress.org, to enable whatever the next version theme selection vehicle will do.

    Report

Comments are closed.

%d bloggers like this: