I want to have a serious conversation about where the industry is going with web design and CMS use.
I’m speaking specifically in the context of building websites, whether blogs or business sites or info sites of any kind, just typical web design and development.
In the old days, a developer designed websites with pure HTML and CSS. Eventually dynamic languages and tools helped make code a little more DRY by having HTML includes and chunking out code blocks.
The problem with this was that the end users could not manage things because all the page content was right there in the HTML files and things could easily be borked by messing around in there. Routing was also a problem because every page had to be linked with an actual html file (or some file) in the web folder.
Then came the use of dynamic languages all the time, especially PHP. We could now run websites via a single endpoint (index.php) and route as needed, pulling in the content via a templating system. This setup has been evolving ever since.
But it suffered from the same problem. Content was inside the templates, it was hard for end users to edit. Technologies like Front Page and others tried to build “editable regions” to help end users have access to just the text parts.
These systems were quite rigid of course. The users might be able to edit some text, but change little else about their site.
The evolution of CMSes also happened. Developers could work with templates and code but put in the “user content” via template variables. The end users could then edit the values in these variables with some kind of admin interface, text boxes, wysiwyg editors.
These CMSes evolved but we found them still too rigid. Often a CMS would give you little more than a single wysiwyg box to enter the entirety of the content for a page. It was much harder to edit special blocks like headers, menus, footers, sidebars. It was also hard to enter custom code like widgets and forms and other things when all you had to work with was a single text box.
Now modular CMS functions enter the fray. CMSes built separate sections for editing content of sidebars and menus and widgets, and the developer once again stuck these sections into various places in the templates. Now the users had a pinch more control.
But it was still too rigid! There are too many 3rd party apps that need to be used. We’ve got headers and sliders and grids and forms and Google maps and the need for connecting any number of 3rd party APIs. It became too difficult or untenable to require a developer every time something needs entered in a page. But even then it’s not really possible for a developer to enter custom code in the “middle” of the end user’s wysiwyg content.
Now we get things like custom code blocks, shortcodes, or other types of “tags” that can be entered in a wysiwyg box which are linked to the actual code. Now end users have the power to install widgets and plugins which give them small code snippets which they can configure and place in their content where needed.
Once again we hit rigidity. A developer typically assigns an inner HTML area for end user content to go in. The end user has a hard time doing things like entering fixed width content followed by full width followed by fixed width again. They can’t do things like create their own column or grid structures unless those are entirely preassigned code chunks.
End users loose control over how many shortcodes are available or how to use them with their various options.
Now we enter the modern era. With tools like page builders and “live” editors, the end user themselves are able to create rows and columns as needed and stick in as many text boxes, title boxes, wysiwyg editor boxes, videos, code embeds that they need to get a page built.
This seems to solve most of the ills of the previous problems by letting the end user have so much control. But on the backend, it’s not so nice. The developer’s job now, rather than build nice things, is relegated to being a hacker, endlessly tweaking, fixing, adjusting the output of page builders, plugins, widgets, and code snippets. CSS becomes impossible, say bye bye to standardized nice markup or naming conventions, SASS files, etc. And hello bloaty mcbloatface output. The developer doesn’t have control over the HTML output of every widget and plugin an end user might find to install. Nor can they guarantee the safety and security and performance of using such tools.
Not only that, but when the end user gets to essentially design every single page with drag-n-drop glee and no standards, every page can look like something totally different from any other page.
This page gets a header and full width content. That page needs a purple background and black boxes. This page totally needs rounded corners and drop shadows on everything. That page is more “fun” and definitely needs all the fonts changed.
With great power comes great responsibility! If one is not careful, a page builder site can grow to 10s of thousands of lines of CSS, dozens of JS tools loaded for widgets even if those widgets aren’t used, horrendous output, endless CSS overrides and !important declarations, a dozen fonts loaded, and no real standard styling or branding locked in.
Now what I see in the industry is a combination of page builders and some small degree of developer control. The developer uses the page builder to design everything, then hands over the keys to the end user with some moderate instruction how to open it and find text blocks to update them. At this point if the end user starts changing styles and fonts and padding and margins and shadows and colors, it’s not the developer’s fault or problem. The developer can’t create generic CSS to handle the look-n-feel of every conceivable kind of HTML output that any plugin or widget might generate, there is endless possibilities. So any time the end user finds a way to change their content in some new way, a hacker dev needs to come in to fix the CSS jankiness.
Not only this, but the page builders themselves are little more than hacks! Take Wordpress for example. Early page builders were little more than front ends for sticking massive amounts of shortcodes into the main content editor. Have you ever looked at the raw text of a Visual Composer page? A sea of shortcodes. I imagine many page builders work that way, dumping their own custom code (which needs further interpretation later) into the single content box of the page. This feels very hacky!
It can’t work with tooling, it requires a second interpreter of special codes into HTML. Page builders come with their own sets of JS and CSS files which always need to balance with the main site CSS, the list goes on. And I’ve seen cases where an end user accidentally switches from page builder to raw text or something, and lose all the page builder code. That is ridiculous!
Modern page builders perhaps use some other technique then dumping codes into the wysiwyg box, but it still feels like hacky stuff and a bit unnatural. Different page builders can’t work with each other, and widgets and plugins must be designed specifically for that page builder.
And that brings me to my question. Where is this going next? What is the next evolution of balancing developer design and end user editability? Because something is clearly lacking.
Recently I worked on a business site built on Processwire. I like PW as it adopts what one might think is a more modern way of doing things. Instead of the end user being given one single wysiwyg box to put in all content, the developer on PW creates individual and unique fields for all the custom content of any given template.
The developer creates fields, the fields are assigned to templates, and then any page that uses that template gets all those fields.
(Note that I see this style of design used on WP too by using custom fields editor and creating special fields for output)
At first glance this feels pretty good, because the developer is in control of exactly what fields are needed for any given custom template, and can design those fields into the templates which can be standard HTML/CSS/PHP files. We can develop with normal code and have control over the output and CSS! Yay!
But this system runs into the rigid problem too. On this site I’m working on, there are templates with as many as 40 custom fields or more, each field linking directly to very specific output in the template. This is great if you build a design that is never going to change much, but I feel very locked in to all these custom fields which are directly tied to the developer’s original output code.
If I want to remove a block or section, it’s not just a matter of putting no content in a custom field, I have to delete the field from the template, and then edit the template files to adjust the output and remove the field reference. This is all done by the developer but that shouldn’t be the case. Why should you need a developer just to get rid of a div block that shows a customer quote?
But in Processwire, the development of a template is pretty well tied in to the custom fields assigned to the template and presented to the user to fill in.
Again, PW is great if your site structure and design is not meant to change much. And the end user is going to need a developer if they want any kind of basic change to structure, or require new fields or to remove other fields.
In Wordpress if you want to delete all the page builder output and start again, you can do that with a dozen clicks and your general template output is not going to change much. On Processwire if you want to remove all the page content and start again, you have to delete all those custom fields, which will completely destroy the output of the template that links to all those fields.
It seems we have two extremes with different focuses on how templates and content are built up. It seems to me neither approach is desirable. I want the ease of Wordpress page builder, but the control and cleaner output of Processwire.
I want, as a developer, to work with plain template files, designing in HTML with the ability to use HTML/CSS/JS/templating tooling to get the job done, no funny business. But I also need to make it easy for the end user to add/remove content as they see fit without destroying my templates, creating bloat, dueling CSS structures, etc.
I don’t want rigid structures of a CMS preventing me from doing any design I want in the templates. And I don’t want rigid structures of templates preventing the end user from adding/removing their content in any area of the site they wish.
What is the next evolution of the developer/user CMS workflow?
Some might argue that there is no real fix. If you want a highly custom design that is efficient with great performant code/output, then you need to use a CMS (or nothing) which gives the template control entirely to the developer. Something more like PW. And the end user is given very specific data fields that can be edited.
OR you give more control over the end user, which is going to require automated builders, drag-n-drop editors, widgets and plugins, generic and wildly variable output that will require a lot of hacking up and overriding, and bloated code.
Is it either/or?
I have to believe there is another way to solve this problem. For all I know there is already a perfect CMS out there for the job and I haven’t seen it yet.
What I do know is that the future of design is probably going to allow end users to edit their content “live”. Literally looking at the page and just click text and changing it. Plenty of page builders and tools do this now, but I do think this is the future, rather than sending the end user to a backend where they have to find fields and type in plain text, not knowing how it will look live until they save the changes.
So heavy developer control, heavy end user control, live editing. Is it possible?
For the sake of this conversation, I’m speaking only about the future of wrapping all this up into an off-the-shelf CMS. Will we have a CMS that perfectly balances this conundrum? For the sake of discussion, I’m not talking about developing from scratch, you know building Laravel or Node or Symphony or whatever. Let’s just talk about CMSes in particular.
Where do you see design and development going in these tools? How can you balance developer and user control over content without sacrificing tooling, standard templating, performant and standard output, etc?
And…have you found a CMS that does this really well?