With each subsequent release, the WordPress community seems more and more willing to accept breaking changes—though not necessarily related to code.
Dramatic shifts in user flows are shipping with new versions of WordPress and are turned on by default, forcing users to opt out if they want their existing experience back. Clearly, the experience of new users—or users building new sites—is the priority for WordPress core. But, enterprise software companies live and die by the way they shift user experiences because disruption and wasted time are the enemy. This role of software administrator has become a necessity for large organizations using WordPress every day.
In this session, we’ll discuss the evolving role of a WordPress administrator and the opportunity to better serve your organization through thoughtful change management.
- Evaluating and categorizing changes to the WordPress experience to manage the rollout of core, plugins, and themes
- Tailoring the out-of-the-box WordPress experience to suit your organization
- Managing and streamlining user support by triaging issues and questions
Cliff: I want to talk to you about the evolving role of the WordPress administrator. I will be on this first slide for a moment because I want to give an introduction I think it's really important and helps set the context of why this idea is impactful and why it helps you. It's helpful to center ourselves in the reality we live in now.
Right now, it can feel like a lot is happening to us and that the individual actions we are able to take aren't necessarily making a huge difference. There's a lot of change happening in the world around us and it's easy to feel out of control of the most important things that happen to us in our lives, right?
So, that can play out in a number of ways, even down to the elections we're part of and the way we make decisions about who makes decisions for us and we experience the feeling of having other people making life and death decisions for us.
That can make us feel out of control a lot. I think it's important to feel that and acknowledge that is true and happening. If it is true that the people we elect in America make choices that impact us in serious ways. We should feel the consequences of how we participate in democracy and in our lives, in general, and how we choose to take action.
To hone in on something about that feeling and as individual . . . We are seeing, at the same time that it feels out of control and things are happening to US, we see that individually and collectively, we have power. We have to identify the ways we use the power and get good at leveraging it.
Everyone is certainly talking about the COVID situation. As many things in the situation that cause us to feel powerless, that exist, we've done things individually and collectively that have made a difference. Individually, those that choose to stay 6 feet away, and staying inside though it hurts us financially, mentally, physically, spiritually-- those that wear masks to protect the vulnerable-- those that interact with the people and are honest about exposure and testing, and all these things.
We individually make decisions. As we add them up, for those that participate in that and continue to do so, myself included, have an impact. We have heard "flatten the curve." We did do that. We collectively used our actions to get people out of the ICU so hospitals could handle the flow of people. We, together, through action, did save lives in doing that.
I want to bring that up. It's important to recognize the difference between the sensation of things happening to us, that we can't control, and the reality that some things can't be changed, but some CAN be, if we assert ourselves, individually and collectively. Understanding the sensation of things happening and the reality that we impact certain aspects is huge. We concentrate efforts and resolve and strengthen the muscle of collective action for ourselves.
You might say, "Thank you for the rant. I'm here to talk about WordPress." We are. It's not as important as trusting science to keep from harming ourselves and others or that Black Lives Matter, but flexing this muscle can help us respond to decisions beyond your control and often are. This can help you serve your clients and community better, as well.
There's a longstanding pattern in WordPress that has accelerated that is causing me to talk to people more about WordPress administration. The community is decisively not the decision maker for new parts of the WordPress project.
A lot of times, it feels that changes in WordPress are happening to you, especially if you make your living off of it. And you have little to no control over outcomes. These huge, impactful changes show up in regular releases with no real warning.
Often, they happen before the release, or at the least, unless you're heavily involved in the release, you may not be aware it's there.
That sensation of things happening to us, as I mentioned-- I know I'm not alone in feeling it's happening to those that have gone to bat for WordPress for the last decade-- both the project as a philosophy and the code base of WordPress itself.
We've told clients to believe in the ideology behind WordPress and that we can trust it. That new changes won't happen to you over time, because WordPress has a philosophy of backwards compatibility. We believe it, as members of the WordPress community, and told clients.
We leveraged our trusted relationships to prop up the philosophy of WordPress. The huge changes happen to us and therefore, clients. Big important changes and shifts to how WordPress works show up in releases and show up for people that didn't opt into them.
This is evident with the Gutenberg project. By any definition, the WordPress community wanted to slow the roll of the new idea for new users. There were collective reasons to slow it down and be methodical. But the block editor have made changes to what people got used to for years.
The WordPress work flow and things that did the most common things were something we were used to for ten years. It pretty much worked the same as before. The block editor shows up and changes that.
The big changes like that, that affect our clients, are shipping by default without the consent of the community, despite myself and countless other people who invest in WordPress saying, "It goes against backwards compatibility." We believed and trusted that philosophy and stood up for it.
Look at it a bit differently. It was safe to upgrade because of backwards compatibility and staying up to date was right. It would work and never break because of this philosophy. That's not the case anymore. Full stop.
Experiences also need backwards compatibility for the philosophy to work and for WordPress to be trusted and your clients to trust you for trusting WordPress. Experiences, at the end of the day, aren't backwards compatible when things are shifting and changing with versions.
As changes roll out, they are treated as opt out not opt in. That's the proper way. Backwards compatibility means not to change something unless the user agrees. We have a way to let users consent in a clear and deliberate ways. There are ways to navigate the basic changes without the mechanisms for opting in.
I want to bring up this larger idea of experiences being backwards compatible and WordPress administrator is because I am part of the WordPress community, with a day job, working for a software enterprise company. Part of my job is ensuring that user workflows don't change because they power the largest companies in the world and millions of people rely on software and updates. We do this thoughtfully. We intentionally use the rollout of software to gain trust by never changing the work flow.
We do this for a number of reasons. The only exceptions we have for pushing a change to work flow is validating with real users and prove that we make the work flow better, more intuitive and will help people. Users are able to see and understand the value. It's part of the testing to ensure we roll things out, appropriately.
We would never do what the WordPress project has started to do more and more. We value existing users too much to push new and unexpected on the work flow. In the reality, where this happens more and more with WordPress, your clients need expertise and nuance to guide new features and changes. Upgrading by default is safe for code base but not their work or their job.
The WordPress project clearly won't defend the end user's experience. They have different goals, making the editor opt in and not opt out, means existing users aren't the target audience. Take it at face value. Including that independent decisions are made in contrast to community feedback.
"If we ship this in a new version; it will hurt my clients." The consensus doesn't impact the WordPress and we accept and respond to it.
What I hope to convince you is to shift you from being a WordPress consultant or designer or someone who assembles WordPress project and look for opportunities to invest in WordPress administration.
We'll talk about what this looks like in the WordPress space. I hope by the end, you feel positive about the opportunities in front of you, to be better at your job, to help your clients and your future clients with their business powered by WordPress.
I mentioned earlier about my day job. Changing a user's workflow still provides a mechanism and allow them to decide when impact/changes roll out. When we necessarily change something about a user's workflow, security, application platform, we provide an mechanism for administrators to decide when it works for their business/clients.
They may have customized the platform to suit their business, building on the code base, building on the way the platform works, the existing work flow and that works with applications and concepts. Pushing down changes may cause breakage in unpredictable ways, though we use the best practice.
We provide a buffer and opportunities for administrators to decide to roll it out. We apply this to the WordPress space. This should be more similar with WordPress in major updates. You may be an expert in helping clients, writing code, recommending hosts, managing hosting, etc. I want to encourage you to be that buffer between the WordPress project and your clients. Many of them need you there, whether they know it or not.
Managed hosting has evolved in the last 5 years. It's not a replacement, but a really awesome tool in your tool belt. I want to break down what this looks like, specifically.
It means, for the clients you serv, your roll is to be aware of and absorb change and dispense it in a sensible way. It means thinking more about the implications of the major version changes to WordPress, themes, and plugins and how to best present them to clients.
What does administrating WordPress mean? First up, it means that you need to evaluate core features ahead of time.
Some already do this. I want to bring more people on board with this. It's relatively inconsequential for someone new to experience the latest version. For better or worse, it's the way. It's how they work with website CMS, they have established muscle memory and keep their business running.
We are talking about existing users, the gigantic portion of the web using WordPress to power personal website, business, nonprofit, anything. We built up 1/3 of the web and now WordPress is changing the way things work for the 1/3 of the web.
Existing users aren't spending time reading make.wp.org. Your clients aren't engage in community discussion and pushing back. It's not their job. Honestly, or personally, I wouldn't wish that on them anyway. It's a pain to be involved in community feedback when the best interests of your clients differs from where the WordPress project wants to go.
An administrator deals with this as an expert, predicts the impact on end users, and decide what the rollout should look like depending on the next versions.
As a reminder, these decisions that change user work flow happen at the last minute without input. Though you follow all the decisions on make.WordPress.org. These opt out changes come into view. I wish you could see the finger quotes I'm using around "opt out." You decide whether it benefits clients or gets in the way.
You evaluate changes and figure out how/if it benefits the people that pay you money and trust you to roll out an experience to trust. You can decide in advance that the new features are coming and won't interrupt the day-to-day and let you know if you need to use them. If it WON'T help clients, you have to mitigate it and evaluate core features.
I'll give you some examples. There are good changes that are out and are big. You can communicate that. There are good and bad ones. There are some that need thought for your use case. Let's talk about core features that are good and don't require preparation or mitigation.
For instance, new site help board is so rad. It's great work, beatifically designed, and easy to understand. Critically, it stands apart from other features. It doesn't change anything, but is a new opportunity to learn more about your site, do more testing, opportunities to improve your site, etc. It's not in your way.
That's an example of a great feature that you can rollout and won't harm anything and gives further information. If you have more nuance about what you want to get into, about how certain users shouldn't see it, fine, but doesn't ruin work flow.
Another example of a good change pushed down are changes to the file editor. It used to be a hell hole of possibility, where you could take your entire site offline and lock yourself out because you forgot a semicolon. The changes rule. They are great.
They prevent the problem, make it more obvious what to do and give you a prompt to understand what is happening before you edit the files. I was happy to be part of the conversation when these were decided on the WordPress side before shipped. It prevents damage and doesn't change the existing experience.
It doesn't make existing files the ideal, but it's a safe feature, something your clients can absorb immediately.
Let's be honest, some features are trash for existing users. Administrating WordPress means absorbing some disruption coming downstream. Big, new features should be rolled out differently in recent versions of WordPress. Listen, that won't happen. We see over and over, existing users experience isn't valued over the new users. This is an opportunity to absorb disruption for your clients.
Let's take one example of something that should be opt in and wasn't, that you, as WordPress administrate can absorb. WordPress 5.4 shipped full screen by default.
I make my living being a professional experienced designer for Enterprise Products and make no apologies for saying this decision was trash and violates usability principle. To ship out a new default experience that people aren't opting into . . . Thinking about a less technical person. You're in WordPress in your site, clicking the same links and buttons and you're represented with a different experience because you upgraded WordPress, what you're supposed to do. It's what we encourage people to do.
You land on a page like this, removing the navigational context that is necessary to use your website like you did yesterday, before the upgrade. To make sure you're clear, you shouldn't expect the behavior to change. It's not an exception, though it's obviously the wrong decision.
Google is all about turning this off. You can see why the decision was made and the concern expressed and how it was ignored and overwritten by pushing the change. WordPress didn't ship a helpful mechanism for opting out. The opt out mechanism wasn't great and doesn't work the way it should.
This change shouldn't have happened to begin with, but happened. This is something to prevent as a WordPress administrator. You stand between the WordPress and your clients to make sure they can get their jobs done without disruption and observe the change so clients can do what they want every day.
Some users require preparation. They may not be inherently good, without default, or inherently bad. Some need thinking based on your set up and how you manage a website for someone else. To put it consciously, being a WordPress means you need to have administrator type thinking. The way that media files work requires coordination and thought. It affects how media is uploaded and processed.
Those changes are well documented and well discussed and led by great people. It was great and totally needed. It has hidden costs to customization that you made or plugins you use. I use Delicious Brain products. They filled in the gaps for WordPress administrator. They were on the top of the change and predicted what it meant for their clients and that impacts my clients and my help.
If they didn't do that, I wasn't aware of cascading failure for media across sites because of the WordPress update. Because this is a user experience principle that you're familiar with in the space. People think that they did something wrong when something is wrong.
They ding their confidence because they assume they did something wrong. Angry people are quick to blame, but you'll see that people say, "I must be doing something wrong. What did I do to cause This?" There's a lack of trust and you need trust with your clients.
That's how you deal with WordPress Core. Think of other ways to be a WordPress administrator with plugins and themes. Reading change logs enables you to be helpful to your clients.
Plugins, often, adhere to semantics. We see a major version coming out, and because of semantic versioning, could break customizations or tweaks to the plugin. WordPress Core isn't adhering to this, and we go from 4.9 to 5.0 and it's not different from 5.0 to 5.1. That means, at the least, because most adhere to semantic versioning, we ask plugin authors to take it seriously and you can, too. You see a plugin and evaluate in a sandbox environment before rolling it out. You assume minor versions are generally safe.
If a plugin author breaks the trust of shipping a patch version, by shoving in big changes, messing out the rollout, a big bug, deprecating API, etc. Do two things. One, find a reliable source for plugin functioning, if you have to absorb more and more change.
One thing I've had success doing, holding plugin authors accountable by giving them feedback and prevent them from breaking chains in minor versions. Don't remove APIs or filters or a plugin in a minor or patch plugin. Make a major version upgrade so people can understand there's an upgrade and it's major and it needs to be tested out. That indicates big changes to how my customization works.
When we talk about themes, we enter the wild, wild west. It's even worse than using semantic versioning and the fact that WordPress doesn't use semantic versioning. Things have no consistency with version numbers. They are irrelevant in many cases. I've seen updates that change the styling of the theme used, by reputable theme authors. Evaluating an update for a theme requires reading the change log, nothing else will save you with theme upgrades.
You'll have to go through and parse whether you need to read maintenance and security changes and if you need to counteract the changes brought in that you don't want. We talked about managing Core upgrades, plugins, themes, versioning and change logs come into play, and staying involved in the community and part of how you absorb the disruption and change for clients.
It doesn't have to be a defensive stance with WordPress administration. Once you have your sea legs, for lack of a better term, make it better for the default WordPress. Administrating WordPress can be about tailoring for individual clients. It's not just about being a consultant, "you shouldn't do that" and ignoring it, but own the experience for your client. Tailor it and help them get their jobs done.
What is cool about this and WordPress being backwards compatible, I made a presentation in 2015, "Friendly and Safer WordPress Admin Areas." Using hooks and filters to hide dangerous things still work today. You can remove things that don't help people and remove dangerous features.
At the time, I communicated dangerous features were the editor, but it's safer now. Something that could be dangerous is surfacing to your client the ability to block robots from reading your site? I can't remember how many times I left that checked when making transitions. You can go and use hooks and filters to hide or deemphasize things that aren't helping.
Set your goal and make your client feel confident in the interface. Set yourself a goal of breaking into the site being impossible for a client. I've done that before. It's not actually impossible, but you can make headway getting there. Do an audit of a features available in admin area and what your users need to get the job done.
What I like to recommend is being more hands on with the management of installing and deactivating plugins. You may consider disabling the ability to add in new plugins. What do your clients need access to or not? In my experience, start with "secure by default" and then open it up. When you have a trusted relationship, be honest. "This is what I recommend."
You can say, "We disabled the add new plugins link by default, because we want to manage and support the code on your site. We have experience to evaluate plugins before Added to avoid trouble." People are more open to this than it seems.
You can remove a disabled link from a plugin or a group of them. You can easily hide them from the plugin listing. When you look at existing plugins, they don't have a cashing or security plugin. If they don't need to see it, get rid of it so they can't. This helps people feel safe and confident.
You can push further and keep optimizing for the focus. Use hooks and filters and custom CSS to hide distracting items that aren't dangerous but aren't helping. SSEO shipped an upgrade with a notification system and included red notification bubbles for when there's something to check out in the area. I didn't like it.
It confused clients. They thought something was wrong with The SEO because of the color red and what it communicates. I use CSS to hide the bubble. I helped people manage that and we can find other ways to detect issues without distracting issues.
Many use admin area for advertising. I love disabling stuff when people ship it. Often, one, you're managing licensing for clients. They don't need constant nags to upgrade to something else. Plugins don't accommodate for this common scenario.
You can clean up the admin area, keep them focused on what matters without distracting them with prompts for upgrades, downloads, plugins, etc. You can think deeply about what people want to get done.
It's important to think about supports and licensing and how it works for your clients. Consider an idea of supporting all the code on your site. I've seen companies doing this recently and I'm encouraged by it.
For instance, think about how going to a plugin author works when you say there's an issue. You have a problem/bug. What do they ask? "Disable everything that makes your website function and look correctly and try it again to see if it works." You break the heck out of your site to find out if the problem is with the plugin or with someone else. It's reasonable from a plugin author, but not from a client perspective. They don't understand between production and live and staging environment where you do this.
I recommend that you as an expert or WordPress administrator, say, "Client, if you have questions, come to me. I'll be happy to get your question answered for you." What you can do on their behalf, is go through the debugging process and don't learn about the staging process, and learn about the plugin developer and better frame it and have a more effective conversation.
People who aren't technical don't know the words to communicate what is happening. You do. You have an existing relationship with the plugin developers and skip in the pleasantries, like "Unplug and plug back in your router." You can help folks with the support and answer questions on their behalf. It sounds like more work, but it's less work, you're making processes more efficient and effective.
To tack on, an additional thing, using hooks/filters for how plugins present on the backend, you highjack the links array and filter out links in the list. You can remove it so clients aren't confused and creating support tickets with licensing, when it's easier for you to answer the questions.
Finally, administrating WordPress means personal growth for you. I really want to leave on this point. I think this is an emerging concept, why I was happy to talk about this today.
A lot of you, though I can't see you and you can't see me because my camera is off, but I'm so inspired and honored to meet so many in the WordPress community. You're passionate and you're about backwards compatibility and you're in the right place to leverage WordPress administration for your own personal growth.
In the last 5 years, it's amazing to watch the WordPress community grow and expand, and the market. How do we innovate WordPress? I worked on a service, "WordPress as a Service" a new concept. But now it's ubiquitous. There are amazing tools to use.
Think about yourself as a WordPress administrator means you can market yourself and deliver WordPress to users. It gives you the opportunity to gain expertise and make WordPress the thing it is in our hearts. A great tool for end users to manage businesses.
As you grow and become a WordPress administrator, it's a tool. WordPress itself isn't the experience. The experience is what you decide what it is with your clients. This is a great example to tie back with why I set things up for why I did this to begin with.
We have the sensation of things happening to us, but we lose track of how individually and collectively, we can do things. Individually and collectively, you can slow the roll out of destructive experiences. It can shield them from making changes for existing users. Instead, you can say, "I choose to create the experience for users and I will take control of it."
As a WordPress administrator, you grow in your confidence and skill set. You can say, "I design and control the experience. I care about my users more than anyone. Together with my clients, we create a WordPress experience that we deserve." Thank you for letting me talk about this. I'll toss it back to Rachel for the last few minutes that we have here.
Rachel: There are a couple questions we'll go through with a few minutes left.
Someone asked-- what can we do as a community to bring issues like the one you pointed out in the design process for WordPress?
I think they meant "for WordPress." I think they are asking what we can do as the WordPress community, about the section on Gutenberg and what we can do as a community to make sure that doesn't happen again . . .
Cliff: I want to be clear. I am giving my perspective and experience here. Part of why I wanted to talk about this, I don't know if there's a mechanism for the community to effect the change we want to make there. There's plenty of attempt to slow out the rollout due to changes to workflow. But to be frank, they didn't do much to make the impact we wanted to make.
My hope is that people internalize that and start to say, "What can I do to shield my clients from what is inevitable and will continue to happen." It's not a super positive answer, but it's the most correct and most helps us.
Rachel: We are out of time. There were a couple other questions. Cliff can log onto the website and answer them later. We have to go for now, sadly. We are really glad Cliff could join us. Thank you, Cliff.