Earlier this week, I was talking with Chris – our product midwife at 8BIT – about the differences in expectations between engineers, developers, designers, tweakers, and end users when it comes to modifying WordPress themes.

I started my career in software engineering – specifically, I used to work in .NET followed by Ruby on Rails – as well as object-oriented programming before moving into fulltime WordPress development.

And you know what they say: Old habits die hard.

Old Habit Die Hard

Did someone say “die hard?”

Case in point: ask my team what I did when I first became the lead developer of Standard. I spent more time yanking out template code, abstracting it into `functions.php` and a collection of other files all of which would make sense to someone comes from a different background, but not WordPress.

And here I am, years later, where I’m significantly more familiar with “the WordPress-way” (even writing blog posts on Coding Standards and various APIs even) and there are still issues to be solved around this very issue.

Modifying WordPress Themes: Developers and Users

One of the things that gives WordPress a leg up in the design and development space is the ease of which the hobbyist can tweak a theme in order to get it to look how they want.

After all, if you think about themes in their purist form, they really are a collection of markup and styles (located in `style.css`, of course) along with a few calls (such as `wp_head()` and `wp_footer()`) to the WordPress API.

Sure, they may include JavaScript and there may be a call to something in `functions.php`, but I don’t think that’s something that’s absolutely necessary or critical to a simple, straightforward theme.

A Developer’s Perspective

In the latest release of Standard – even in work that I’ve done in my plugins – I’ve begun to employ both LESS and JSLint via CodeKit in order to help better organize the code and to enhance the load time and performance of the product in question.

But here’s the thing: Occasionally, I – or the team – will receive a comment about not being able to make changes to `style.css` because it’s all one minified line of code.

Furthermore, there’s no hope for modifying the JavaScript because it’s not only been minified, but it’s even been obfuscated. This is the topic for another discussion, so I digress.

A User’s Perspective

But as far as the styles go, is this a valid concern?

I think so, especially for those who know just enough to be dangerous when it comes to tweaking their theme to look just the way they want.

So let’s say that a user purchases and/or downloads a theme of their choosing and ready to make a few customizations – perhaps change some colors, alter some fonts, or add some type of CSS transition.

They open up `style.css` and…

What is this? It’s a one CSS!

A User's Perspective

What’s a one CSS, anyway?

But seriously, a customer opens the stylesheet to begin making their customizations and they can’t because the CSS has been minified.

At this point, some may stop right there and think the theme’s been incorrectly developed, that they’ve wasted their money, or that something has gone wrong.

A Case of the Empathies

As developer’s it’s easy to write this stuff off and say “they don’t understand – we’re helping them by making their site faster!” and it’s because we don’t have the reputation of being the most empathetic type of people.

A Case of the Empathies

You know that feel, bro?

Oops.

And though there is some truth in that, come on. It’s important to ask: Are we breaking a typical expectation of someone who’s working with a WordPress theme? Are minified stylesheets out of the question?

Personally, I don’t think so. I see it as a point of education.

First, I think we need to make sure the user understands what they are getting in the product. Next, they need to know how to make changes: If it’s a theme, then create a child theme – perhaps we can even provide an empty stylesheet with a set of empty selectors and code comments. Third, if we’re working with a plugin, we offer a `custom.css` file that allows them to modify the look and feel as needed.

Where Are We Headed?

As much as as I’d like to believe we’ll head in the direction of minified styles and optimized JavaScript, I think that’s a bit of a way off – at least as far as WordPress is concerned – not because the community is dragging (there are incredibly bright people working on and with WordPress), but because of the expectations that our user base has.

Change is tough – this is true of any team, organization, or piece of software – and the longer or more developed any of the above are, the harder it is to change course.

To that end, I do believe that we’ll begin to see more and more people begin to use LESS, JSLint, and/or other similar tools for making front-end development easier, and more optimized, but it’s also going to have wait for the average user to catch up.

On average, I’ve no idea how long that takes – I’ve not been doing this long enough – at least not yet.