Get 10 Free 
WordPress isn’t like other content management systems (CMS) on the market. Sure, there are other free and open-source options. But they don’t have nearly as big of a market share.
That leaves WordPress to compete with commercial offerings. Platforms such as Shopify and Wix come to mind.
Again, these systems can’t match WordPress’ market share. But they do have an advantage in marketing muscle. They have the resources to create a seamless campaign. They can speak to their targeted audience with clarity.
WordPress tends to struggle with messaging. You can see it at both the macro and micro levels. It covers big things like defining what the platform does and who it’s for. And it also happens with individual features.
The result is confusion – even among seasoned users. It also makes things harder for those who teach others. There’s a lack of consistency. Not to mention frequent changes to the terminology we use.
How much does this impact WordPress? Could it harm the software’s long-term future? And what can be done to create a more user-friendly vocabulary? Let’s take a deeper look at the words that define WordPress.
Who Are We Speaking To?
WordPress is an incredibly flexible platform. We can use it in a variety of ways. Thus, it appeals to both technical and non-technical users.
This appeal is both a blessing and a curse. On the bright side, WordPress continues to thrive in part because it offers so many possibilities.
But the words we use to describe WordPress don’t apply universally. A conversation among developers is bound to be more technical. Some terms are likely to confuse everyday users.
Yet it seems like developer speak is the dominant language in WordPress. We use exclusionary terms that are difficult for others to understand. You see it in the core software and third-party themes and plugins.
Perhaps this stems from where WordPress and its ecosystem come from. Many developers are responsible for both building and promoting products. Most aren’t marketers by trade.
Product descriptions and documentation tend to be written by developers. As such, developer speak is likely to be used. The content isn’t as user-friendly as it could be.
An Ever-Changing WordPress Core
The past decade has brought significant change to WordPress. The advent of the Block and Site editors has impacted content creation and website design.
Each of these items has undergone a descriptive overhaul. The Block Editor was initially referred to as “Gutenberg,” for example. The name was derived from the Gutenberg project, which oversees this and other features.
As for the Site Editor, it’s also a part of the Gutenberg project. But the feature was initially called “Full Site Editing.”
The names were eventually changed. They now more accurately reflect what each feature does. These are positive and well-intentioned moves. But the cat was already out of the bag, so to speak.
We now see these terms used interchangeably. This may not impact veteran WordPress developers very much. But what about new users? Do they understand that the Site Editor is the same as Full Site Editing? And what to make of the differences between block themes and classic themes?
We’ve created an unnecessarily confusing situation. And there is plenty of blame to go around. For instance, writers like myself have added fuel to the fire.
How Do We Fix the WordPress Word Scramble?
Here comes the difficult part. How do we use terminology that everyone can understand?
I think it starts with the WordPress project. Feature names should be reflective of what they do. But they should be named and described in the simplest of terms.
Perhaps this sounds like no big deal. But WordPress contributors have a lot on their plates. There’s only so much time to argue about names.
We did see a lot of thought put into this recently, however. The Command Pallete feature that shipped with WordPress 6.3 underwent a name change. Project contributors debated the merits of the original name (Command Center). They realized that it might be taken out of context and addressed the issue.
The creation of user-friendly terms will trickle down to the community. Writers will use it in their tutorials. And product makers will use it in their marketing efforts.
The community also has a responsibility. We must speak to WordPress users in plain language. We must limit the use of developer terms.
A little guidance would also help. WordPress has a developer-focused glossary of terms and a user-focused Semantics page. We should study them.
But perhaps we can educate product makers on methods for creating user-friendly marketing and documentation materials. That’s not necessarily a responsibility of the WordPress project.
Still, it could help to make the platform easier to understand. And it’s a part of keeping WordPress on top for the long term.
A User-Friendly Experience Starts with Words
The words we use matter. They can be the difference between friendly advice and an insult. People use them to form opinions.
What people read about WordPress will impact their decision to use it. If the software sounds confusing, they may head elsewhere. They may never fire up a demo to see for themselves.
It behooves all of us to think about how we talk about WordPress. Are we keeping new users in mind? Or are we losing them with technical jargon?
The impact may not be immediate. But by simplifying our language, we can attract more users than we lose. That’s highly important for the future of the project and its ecosystem.
Top