[wp-trac] [WordPress Trac] #26890: Add a switch themes link to the Theme Customizer

[WordPress Trac]

#26890: Add a switch themes link to the Theme Customizer
------------------------------+-----------------------
 Reporter:  celloexpressions  |       Owner:
     Type:  enhancement       |      Status:  reopened
 Priority:  normal            |   Milestone:
Component:  Customize         |     Version:  3.4
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:  ui
------------------------------+-----------------------
Changes (by folletto):

 * status:  closed => reopened
 * resolution:  invalid =>


Comment:

 I'm reopening this ticket as mentioned on #28979. Here's the relevant
 piece of discussion:

 > > ''Folletto'': The proposal you make is very similar to a design
 concept I was working on too, even if the "slide back" actually triggered
 a full screen view (from the left slides in a full page that covers
 everything, which is in practice the 3.9 theme browser), the reason is
 that it would be too constrained to fit inside a small column (even if,
 that would be exactly how it would behave on mobile).
 > > But apart from that, I agree 100% that it should be the hierarchy to
 imply there.
 > >
 > > We could still add an intermediate step: it could be simply a link
 back (click, open Themes panel in the admin area), and we can work on the
 better interaction (sliding panels, API, etc) at a later stage. ;)
 > >
 > > So... worth a new ticket? ;)
 > ''Celloexpressions'': Great idea! We could even slide in `themes.php` in
 a full-screen iframe from the left of the screen, and then trigger a new
 full pageload to get out of the iframe as soon as the user navigates
 somewhere (such as, most commonly, to customize a new theme). If you want
 to make a new ticket, or even re-open #26890 with a comment, I can throw
 together a rough patch as I have an idea for how we could accomplish that
 from a technical perspective. Now that we have an AYS for unsaved changes,
 linking away from the Customizer isn't a huge deal. If the Customizer was
 opened from `themes.php`, we would already have that page's DOM loaded
 thanks to customize-loader, so it would just be a matter of changing the
 animation that closes the Customizer iframe. Not the ideal experience that
 doing it all in the customizer would be, but a good approach while we
 build up the API, and at least we can start to make the themes vs.
 theme/site options relationship clearer. If we get a few people working on
 it, could probably get that into 4.1.

 The advantages are plenty:

 1. It would create a '''two way navigation showcase <-> customizer''',
 allowing a better customization experience
 2. It would '''reinforce a clear navigation hierarchy''', where Themes are
 at the top, then customizer menu, then individual customizer options, and
 then (well, on the side) the site preview itself the final result.
 3. It would '''consolidate''' further the customization experience in one
 "place".

 This can be done in a two step development (or more, if worth it):

 1. Convert the current "You are customizing" top accordion to a '''simple
 link''' back to the Themes browser page.
 2. Substitute the simple link back to a more structured navigation, with a
 full-screen sliding-in panel that contains the full showcase, with a
 '''smooth transition''' and ideally well integrated in the customizer
 navigation structure itself.

 I hope this helps. :)

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