Developers, We’ve Made the WordPress Back-end Complex and Disconnected

There’s an alarming trend in the WordPress back-end: we developers are polluting the back-end and building disconnected, complex solutions for the site owners. I understand the path that lead us to this state. But now it’s time to stop and think about the site owner first and what his/her needs are. Let’s first talk about the problems and then in subsequent articles, I’ll present a series of ideas and solutions.

Through the Eyes of the Site Owner

Site owners choose WordPress not only because it’s the best CMS solution on the market, but because of its ease-of-use. They want and need to publish and manage content. That’s the whole point of using a CMS like WordPress. They don’t want to design their site, add new post types, or setup some custom feature. No, they hire a developer to do those tasks and deliver a ready-to-go, custom, specific site to meet their needs and share their message.

Let’s do an exercise. I want you to think of the most non-technical person you know. Do you have that person in your mind? Now let’s call this person, Sally. So Sally logs into her site and lands on the Dashboard page. There are small links there for her to quickly do various common tasks. But then she sees all the options on the side menu. Hum, how does she feel now? Posts. Media. Pages. Appearance. Settings. Then we developers add more stuff in there such as theme setup pages, customization pages or meta boxes, and more. It’s confusing and overwhelming.

Editing Content for the Front Page

Sally is running some new special or announcement. She needs to change the content on her front page. The theme has widgetized areas in various spots and then other features from the front-page.php template which are not editable. Where does she go to make the changes? In her mind, changing an interior page is as simple as going to Pages and then editing that page in the editor. But the de facto model for front page templates is different.

She gets confused and frustrated and then calls you. Now you walk her through the steps. A month later she needs to do it again. She calls you.

Installing a New Theme

It’s a year later and Sally wants to change the look of her site. So she buys a theme, installs it, and what happens? Hum, the new theme has new image sizes and different sidebar widgetized areas. Where did the content from her previous theme go? Frustrated she calls you again as in her mind, her site is broken.

Sally is disappointed that the new theme doesn’t look like the site where she bought it. Maybe she doesn’t realize that she has to walk through the steps that the theme author wrote. All she wants is to have it look like what she bought.

And maybe the content has styles in it. That means when she switched to a different theme, the content has the old branding and colors.

To her, the site looks broken. She calls you.

Breaks Her Site

While exploring all the menu items in the back-end, she finds a page where you can setup some custom feature, such as a custom post type or field. She’s curious and tries to edit something. Whoops, she just broke her site. She calls you.

We Developers Pollute the Back-end

We developers are polluting the back-end with interfaces that make it easier for us to do our work outside of the code. Various plugins and even themes offer customization and setup interfaces to do tasks such as add custom fields, custom post types, custom taxonomies, styling into the content, and more. It is the de facto product development model for themes and plugins. Setup, customization, and configuration is available to you from the back-end.

This model is flawed. Why? Because it is developer-centric, providing us the tools we need to setup the site. But it adds complexity and bloat into the back-end for the people who will run the site. It’s confusing to them and offers the potential for them to break their site should they change anything. This model stands in contrast to the “ease-of-use” and “simplicity” draw of WordPress.

Let me be more specific. Let’s say your client wants a Portfolio and categories for that portfolio. Maybe s/he needs to select some options for each portfolio article such as the date, client’s name, website, etc. Ok, all of these custom features require code changes to add the functionality to the site and then styling to have it match the overall branding of the site. If you built it yourself from scratch, you would create a plugin called “Acme Portfolio,” for example. Perfect. Now the functionality is enabled through a specific plugin.

But many developers instead use plugins which remove the need for you to build a custom plugin. These plugins add the interfaces into the back-end for you to do your work. The custom features are then stored in the database.

Do you see the issue here? Think about it for a moment.

When you build it from scratch, you are hard coding the site specifics into the plugin and the database interaction is just to handle the content only, as it should be. When you use a plugin to do the heavy lifting for you, everything is in the database and there has to be an interface for you to do your thang. That’s extra code which slows down the back-end. That’s an extra options page or meta boxes where the site owner can break his/her site. That’s slower on the front-end because it has to pull the setups from the database to know what to do. Hum, do you see the problem now?

Why do we want to make it harder and more confusing for the site owner? Why would we ever want to give her/him a solution where s/he can break the site? I know that’s not our intent. Rather, the current product model intends to serve the technical person. I get it.

User-First Development

One of our jobs is to deliver solutions which propagate the ease-of-use benefit. We need to think about the person who is managing and using the site. The back-end should be very lean and simple. All setup and customization features could go elsewhere. There are unique business opportunities here for all of us.

I want you to think about what I’m pointing out. Hold that image in your mind of the most non-technical person you know. Each time you deliver a solution, think about that. How technically savvy is your client? Are you making it uber easy for her/him to manage and publish content?

We need to move away from the Developer-First model and towards the User-First model.

.wrap It Up

Your mind might be swirling at this moment and possibly your eyebrow is raised as you wonder how we can move from where we are now to achieving the user-first model. Don’t worry. I’ll present ideas and solution in subsequent articles.

The point of this article is to plant seeds in your mind and get you to open your eyes to what is going in the back-end. Think about the needs of the site owner first. It will help you to make the leap to what I’m suggesting.

A closing thought for you: We should never give the means for a site owner to break his/her site. If they can, then we didn’t do our job. It’s time to rethink what we are delivering to them and see it through his/her eyes.

Psst….Hear Me Talk About These Ideas on Rethink.fm

Hey, Jackie D’Elia and I were chatting about these ideas on her new podcast, rethink.fm, along with a bunch of other ideas too. Check it out to help you to visualize the points in this article. watch on Vimeo