[UX] New interface for editing, previewing, and saving theme settings

[mikemccaffrey]

While discussing what to do with the color module in #1905, we took a look at how other services such as Squarespace and Tumblr provide an interface for customizing the appearance of your site and previewing the changes before saving them.

We already provide the ability for themes to add their own custom settings to the theme settings forms. For example Bartik asks why style of tabs it should use for the main navigation menu. However, there is no way to preview the different options without making the changes, saving them, and navigating to a non-admin page that uses the public theme.

Perhaps we should implement an interface just like the ones above that show a bar with the settings on the left and a live preview of the public theme on the right? It could probably be done in contrib to start, but it seems like a good candidate for core functionality, since it would allow us to support a feature that other platforms have already trained users to expect.

We could also include a theme switcher in the sidebar interface, which would satisfy the request for that functionality in #1711.

[klonos]

Thank you for opening this issue here @mikemccaffrey. You beat me to it. Ever since I've read @wesruv's proposal about having a mini-preview on the appearance admin page by scaling down a live version of the website, I wanted to say precisely this: why scale down the one thing that the user cares about seeing what it looks like? That part should be prominent in that page.

I cannot come up with any ideas of how this could work on mobile because of the limited real estate, but then again I'm not sure if we should support such a thing on mobile to begin with.

Anyways, I'm all :+1: for something like this.

[dboulet]

It’s probably worth mentioning the Theme Customizer in WordPress as another example. It basically works exactly as you’ve described here, with a theme switcher and live preview. It also provides an API to allow themes to add as many of their own settings as they want.

[wesruv]

I haven't looked too much into theme settings, but in every theme I've seen implement them I've loathed them. They seemed to be trying to achieve functionality that should be in the module layer but not nearly as well.

In D7 they were usually fragile in a multi-environment workflow unless you were moving around the DB. I hope our theme settings are saved in a config file?

If there's a way to make theme settings easier to produce, I'm all for it. If someone knows of a Drupal theme where the theme settings were done pretty well, I'd be curious to know which one and what you like about it. This feature is a bit of a reach for me because I don't desire this from a theme.

One potential issue I have with moving Color module stuff to the theme is we lose the opportunity to have settings stick when you change themes. It's plausible (although I'd say tricky/may not work out) that we could make it so some color and font settings stay with them if they change themes.

At minimum, I think core should provide a field type for 'color' and a fallback for browsers that don't support the type natively.

I think it should also provide an easy way to specify and handle color settings.

The ability to make custom CSS files from a PHP template feels like it'd be an amazing feature, but I'm not sure how many contrib themers would actually use it...

why scale down the one thing that the user cares about seeing what it looks like?

I've used those two and they pack 10 lbs of UI in a 2 lb space. There's no room for instructions, a lot of labels are cryptic because of a need for brevity and the controls are all too small for touch screens.

I don't really need to see a pixel perfect version of the theme for colors, and it's likely a better use of space to make sure the form is user friendly.

Tumblr and Squarespace have considerably less features than a Backdrop, and if we used that same design, I don't imagine that our scrolling sidebar o' settings would get shorter.

I would say for a "Font size, font family" type editorial screen, having a scaled down version of the page would not be acceptable, but I I think I can do a variation on the design for that.

We could have a "zoom" function on the iframe. It'd be quite easy to implement and would allow the user to tweak in a well constructed user friendly form, and see it at full size.

[wesruv]

@dboulet any chance you could capture some screenshots of the Wordpress functionality you're talking about. I'd love to see that.

[hosef]

I have created a pull request that reworks the color form to all be in a single function and I removed the theme function so that everything is being performed with basic Form API stuff.

Currently, the code is using a very old version of the Farbtastic library to implement a color picker. I would like to add some way to detect if the browser supports the color input type and use that instead when it's available. I am not sure how to do that, so if anyone has some advise, I would appreciate it. There is also a newer version of Farbtastic at https://github.com/mattfarina/farbtastic, but I am not sure it is worth the effort to switch if we want to use color elements anyway.

[docwilmot]

First of all nice work @hosef. Two minor things:

One your PR title doesnt match this issue; it does a lot more than just reworking the code to be less complex. I t would be nice to either have a new issue for simplifying the code, or better rename this PR to match this issue, since this is really what youve done: youve created a new interface. This will make it easier for people to find (I had to guess that this was the right PR after seeing it on the video).

Second, about the PR itself though, the theme mini previews we have in core now allow a themer to put all the elements that have been color-enabled so a user can see them all. This live preview you've done, though fantastic, doesnt allow that. For example if I'm using the Borg theme, in which the footer was color enabled, but I dont have a footer on any page, I'd have to make a page first with a footer, then go back to the theme settings, navigate to my new page within the mini preview, then colorize it. And if its a complex theme with lots of color enabled elements, may be more an issue. Not saying thats a problem but I think its worth mentioning so we can consider it.

[klonos]

...any chance you could capture some screenshots of the Wordpress functionality you're talking about. I'd love to see that.

Here's why WP is kicking our butt: https://drive.google.com/file/d/1N0m834tAnQGGNlc-AUaxHNiTDkLHzAN7

...at the end of the video, when I click the X at the top-left, here's what my video capturing software failed to grab:

[klonos]

@docwilmot to @hosef's defence, the description for this ticket in the META ~is~ was "#1949 Improve the color settings page". File a new issue that is specific to the color settings page perhaps?

[docwilmot]

Doesnt matter much, as long as the PRs at least match their issues a little.

[klonos]

...I have created #3186 to match the work on your PR @hosef (and also updated the links and descriptions in the META). Lets take the color settings page-specific tasks over to that new issue, and keep this one a generic one about the theme customisation UI overhaul.

[klonos]

@hosef care to rename your PR please (at least the bit that refers to the ticket)?

[docwilmot]

As to my second point, I think my opinion there could be safely ignored. There is no point in wanting to see the colour of an element that doesn't exist on your site is there?

[jenlampton]

Looks like these labels may have accidentally been removed? Is there a PR here? Wait... didn't we just get a new theme color preview? I'm confused, and may be thinking of that issue.