As WordPress has advanced, many WordPress theme developers have created advanced theme frameworks complete with page builder functionality. These page builder themes and associated plugins help WordPress admins create custom layouts complete with sliders and other tools, the ability to apply hundreds of Google hosted fonts or those from font foundries, as well as apply style to layouts with WYSIWYG selectors or ways to add custom CSS to override the parent theme, all without having to actually employ a child theme.
The introduction of theme frameworks with page builders hasn’t necessarily eliminated the need for custom development, but it’s placed tools in the hands of non-developers to accomplish so much of what used to be contracted in paid development work. Web Developers in the true sense of the word use their coding abilities to create custom layouts and advanced functionality, but they’re not in the business of using page builders and the features that come along with them. They spent time learning to code, not making selections and moving around boxes. In addition, most website owners aren’t skilled in information architecture, the user experience, and UI/UX design. We now have a gap of experience to be filled with the “WordPress Assembler.”
The WordPress Assembler is someone with who works with one or more theme frameworks and has a deep understanding of what these products can do. They spend more time learning the admin systems of themes and plugins than they do actually writing code. One could make a comparison to non-developers who have learned to install, configure and manage E-commerce sites with the WooCommerce plugin. No development necessary. Just a comprehensive understanding of WooCommerce and how to apply CSS styles to override the visual display with new style selections.
This is where it gets really tricky! Making changes and pushing between staging and live environments. The WordPress Assembler understands layout changes are stored in the database and not in a style sheet for the primary theme or child theme. This makes it more difficult to push layout and style changes when content is constantly being published. If layout and style changes are stored in the database, so isn’t the content. If changes are made, then content needs to be updated in staging before pushing live, unless the WordPress Assembler always knows to only push the options table for the site or one of the many possible options tables in a multisite network. But there’s no manual that tells the WordPress Assembler where a theme developer is storing the instructions for the theme to follow.
The WordPress Assembler is also part information architect and part web producer. They understand the flow of content and what features of the framework or plugins will give them the desired result. For example, a site owner may want a breadcrumb trail on every page. In the past, a developer might make that feature work. Today, some theme frameworks have breadcrumbs baked in or you can find a breadcrumb plugin to do the job.
The WordPress Assembler is relatively new and while I have coined the phrase, the title has yet to be adopted. You don’t see ads for WordPress Assembler Ninja jobs on job boards, but I believe the day is coming that the WordPress Assembler (or something similar) will be a formal job title and along with it a the requisite set of skills and experience to support new website development. As theme frameworks evolve along with WordPress itself, website owner/operators are going to need a WordPress Assembler first before they need a developer. That’s not to say we don’t need developers. They’re going to be busy building the theme frameworks and plugins for WordPress Assemblers to assemble.
I invite you to comment on this post below. Do you agree that the WordPress Assembler is a new competency? How will designers and web developers adapt? Will this reduce the cost of web development?