We were lucky enough to get our first ever review of Styles today — an article written by Brian Krogsgard! We’re big fans of Brian’s contributions, articles, and interviews in the WordPress community, so it’s an honor to be getting attention from him. 🙂

Brian brought up some great thoughts in his article, and it’s our pleasure to address them here. We’re really excited to hear you think it will be useful for people who don’t know CSS!

Integration with WordPress Customizer

One year ago, we already had 2 years invested in our own user interface, complete with a gradient picker and image replacement. Even with all that time invested, though, we couldn’t continue working on Styles unless it did everything possible to compliment the WordPress Customizer. We refuse to use plugins that conflict with WordPress core functionality.

We think the result of this decision has been phenomenal. Now, when theme designers choose to use Styles, users don’t even have to be aware that they’re using anything except default WordPress. Ease of use is our primary goal — for users and theme developers alike.

Selling support for more themes

The plugin homepage has a cart icon and a “free” banner on each of these themes, hinting rather obviously that their intention is to offer paid extensions for customizing other popular themes.

Brian caught on to our hint. 😉 But we don’t want to be the only people selling these themes. Our hope is to foster a marketplace similar to Easy Digital Downloads, where developers can benefit by releasing support for their own themes.

We make it crazy easy for theme developers to add options to the WordPress theme customizer. Just look at the link. Setup takes 2 minutes. The first option group takes less than 5 minutes. These videos weren’t rehearsed — this was my first time looking at that theme!!! If you’re a theme developer, give it a try. You won’t be disappointed.

If you’re interested in creating or selling theme options with Styles, get in touch!

More layout options in the future

I wanted to change padding and margins on various elements, and it didn’t have them available for my demo. In general, if a user knows CSS, I think it’s just as fast to customize a site with CSS alone.

The very first version of Styles did have margin and padding, but then we came to the same realization that Brian did — users who understand margin and padding likely understand CSS, and it’s just as fast to code it as it is to use the interface.

We don’t want to add features to Styles “just because” — we want them to truly make people’s lives easier.

That said, there are some features we plan on adding in the future, some of which existed before the rewrite. First on the list is bringing back the gradient picker that behaves just like Photoshop. Another feature at the top of our list is color palettes.

First, though, we want to get Styles into the hands of as many users and theme developers as possible. 🙂

Including CSS in the theme header

I like that the plugin is interfacing directly with the WordPress Theme Customizer API. At the same time, like other visual “frameworks”, Styles spits all of these customizations into the head of the document, and has potential for bloating a website.

We’re not sure this is the case, but we’d love to hear more from Brian if he’s seen otherwise. In the past, Styles was able to output CSS in three different ways: in the theme header, in a saved CSS file, and at a custom URL served by WordPress.

In the end, we reverted back only outputting in the head for a two reasons:

1. Saving to the head was faster

Saving to a file added another HTTP request to users’ sites, and serving from WordPress slowed down the request even more. In the end, the amount of CSS output from the plugin was short enough to include in the header efficiently, and it made the plugin play nicely with all caching plugins without any additional configuration. Performance won all the way around.

2. Saving to a file caused issues for Style’s target audience

As Brian pointed out, Styles is for people who don’t understand CSS. File permissions are much more complex than CSS. We found that even mentioningthem caused panic for many users!

At one point, we output to the header only if we had to, and then notified users that if they wanted to set their permissions correctly, we could save output to a file. You’d be surprised how many users thought this was an error because they didn’t understand what it meant.

We’re open to adding file output back in the future, but we’d want to see that it does in fact improve performance, and even then, we’d likely only release it as a feature for developers.

Questions?

We’re really excited to see that Styles is making people’s lives easier. How has it helped you? How can we make it better?