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
I just watched Morten Rand Hendriksen’s talk about empathy at WordCamp Europe. He makes some generalities among the same lines.
Morten is awesome and his talk at WCEU was excellent!
You go, girl!
The WordPress admin is confusing enough for clients as it is, since they expect everything to work like Microsoft Word, so just getting them to wrap their heads around having a CMS at all is tough enough. Back about 2011, before I was confident creating custom post types on my own, I installed a plugin that allowed me to create post types and taxonomies from the WP admin. I came to regret it deeply, and I never did that again.
Thank you, Sallie! And good for you. Somewhere along the way we made it easy for us and harder for the clients. It’s worth discussing some of the ways we can make the back-end easy again while giving us (the developers and designers) the tools we need to get our stuff done too.
Hi Tonya,
“Sally” should not be an administrator – when she is an editor and you remove all unnecessary items from the backend – things become a lot simpler for her and her webdev…
At least that’s how I do it for 99% of my clients – combined with a maintenance contract for updates.
ps. like your sites! You make it very tempting to try you as a teacher 🙂
Hello Henk,
Many developers opt to set the client up as an editor. But there’s a flaw in that approach: we are then delivering a site where the site owner does not have full control of his/her site. Our jobs as developers is temporary. We build and deliver the site. Then it’s turned over, the site owner owns the site and needs full control of it.
You might be hired to manage the site for them or maybe not. But even if you are, is it forever? Even though they may hire for you for a maintenance contract, that does not mean it’s forever, as they move opt to cancel with you.
You see the “editor” role does not allow the person do the following:
And how about if it’s a membership or e-commerce site? They don’t have access to the tools they need to run their site.
Think about it. You go away and now think about the site owner. His/her role is limited. How is s/he going to hire another developer and give them access to the site? How is s/he going to add or remove features via plugins? How about will the site get updated? The site owner can’t do any of these basic tasks. S/he is forced to have to pay someone else.
Making a site owner an editor is doing them a disservice because now they can’t use their site to the fullest extent. Instead we need another solution which is just to let us do our jobs. Remember – our jobs are temporary. We do not own the site. We are the hired consultants and workers.
I wrote an article which talks about why this a flawed strategy. The article presents one of the solutions that I’m thinking about. Also, some of those ideas you can watch Jackie D’Elia and I chat about here on rethink.fm.
Thank you for your comments. Cheers,
Tonya
P.S. Thank you about your complement on my teaching style. Come on over to KnowTheCode.io as there are a lot of freebies to give it a try.
Hi Tonya,
I think you and me share this point of view, however, I am not a WordPress developer yet! I found WordPress about 2 months ago and I’m trying to learn it from that point. The only reason I am trying to develop a WordPress theme is to make a unique site for my friend. And my background is mostly static HTML/CSS with a little of PHP and Javascript and when I started out with WordPress I honestly panic like the admin is a bit messy, the first idea I had is maybe moving some of that default dev only menus to a new off canvas menu bar and add a button on top to simply get this stuff out of the way. But I don’t have that skills yet and like I don’t have the money (like I don’t get paid and my county’s official money value is really low compared to the US Dollar and Euro) I am stuck with free learning resources and free plugins that seem to add a ton of extra things to the admin menu and huge banners and nags what is a pure nightmare that most of the time don’t even go beyond the basic of theme development before hit the payment wall.
What I’m trying to build is a theme and a simple way to admin it and add content, delete and be able to build on this code base over time and not limit my friend of be able to do anything but make sure her focus not get overwhelmed and lost by this admin interface and options she never going to use.