How much access should a business have to the inner workings of its website?
IMPACT's Senior Developer Tim Ostheimer explains his take on this question.
John: When people say the back-end of a website, what do they mean?
Tim: There are potentially two different meanings to “back-end” when referring to a website, but the word summarizes the parts of a website that can’t be seen by viewing it.
The opposite of this is the “front-end,” which is what you see when you visit the website using a browser.
Another way of defining these meanings is with the words “client-side” and “server-side.” The client-side of a website is also known as the front-end, and it’s made up by the code that a user’s browser reads and uses when viewing a website.
The server-side of a website is everything that happens before that. It’s called this because it’s where many of the operations which occur on the server where the website is hosted take place.
On something like a CMS (content management system), there is often separate code used on the back-end versus the front-end.
For example, the back-end of a WordPress site is written mostly with PHP, whereas the front-end code is all HTML. The backend code is used to determine what front-end code displays for users.
But, server-side code isn’t always what people mean when they mention a website’s back-end. Often, the back-end of a website is used to describe where the content editor interacts with the website’s database to manage what displays on the website.
The way a CMS works is that there is a database (sometimes more than one) which hosts all of the content that is displayed on the site. These databases contain many tables and rows of data that are associated with different parts of the website.
The code that is used on the server-side of a website determines how the data in these databases is used, whereas the code used on the client-side of a website is read by the browser to create a functional website.
This is one reason why HTML, the code used to create the front-end of a website, is actually not formally known as “code” at all — it’s a markup language.
In our industry, when someone mentions the back-end of a website they are typically referencing the interface which is used to allow content editors to manage and manipulate the website content.
Rather than editing the database directly, the back-end is a browser-based tool where the website can be edited intuitively.
For example, logging into HubSpot or WordPress and editing the content of a page or configuring its layout would typically be considered logging into the back-end.
So, how do I get there?
John: How does someone access it?
Tim: This is always dependent on the CMS, but the experience is usually consistent in that you use a secure method to log in so only authorized users are able to access it and modify website content.
Some websites may have a more complex back-end setup where different teams or people manage different parts of the website data, and the methods used to access these parts of the site may not even be the same.
In these situations, the experience may be completely custom and it may not be as simple as logging in via a typical web browser.
Can I mess it up by accident?
John: Should people be afraid of “messing it up” in the back-end?
Tim: It can be very easy to cause unwanted changes to a website if you’re able to access the back-end, but a lot of that depends on the content management system and the interface.
The editing experience may be as simple as providing inputs where the content editor can easily manage their page content or pages, or sometimes the same interface may allow them to make significant changes to the layout and design of the page.
The modern content editing experience for websites is usually not as dangerous as it once was.
Years ago, some websites may have been entirely coded with HTML instead of using a CMS.
In these situations, the content editor was interacting directly with the front-end code instead of using a database and interface to easily manage their content so it was very easy for mistakes to happen.
Now, most websites are built on a CMS, which allows website developers to build a website that can be easily managed by others without requiring they ever go near the code.
But, websites should still be managed carefully. Because most back-end interfaces for websites provide access to a lot of the code, it’s best to stay in the parts of it that you’re expected to.
For example, if you’re a marketer and are only responsible for the content on the website you probably shouldn’t try to edit any of the templates or back-end code that you aren’t supposed to be anywhere near.
Can non-coders code?
John: There always seems to be this dichotomy: people either code or they don’t code. Do you see it that way, or are there levels in between?
Tim: This discussion can get very complicated because there are many different coding languages and most are not used for websites.
In fact, most coding languages are not used for websites and most coders don’t know more than a few languages. So, although your internal product developer may be great with code, that doesn’t necessarily mean they know anything about your website.
On the other hand, HTML and CSS are used strictly for determining the layout and visual structure of a website.
HTML is a markup language that handles the structure of elements that make up the front-end of a website whereas CSS is a cascading style-sheet that applies different behavior and formatting to those HTML elements.
A content editor should never need to fully understand all of these languages, although being familiar with the basics can be very helpful to better understand exactly what is going on when editing the content of a page.
It can also be very helpful when troubleshooting why something is not working the way you want it to.
I always suggest a content editor have some understanding of the concepts of HTML and CSS since it can help make them more confident and efficient when managing their website, but most websites built on a CMS will use an interface which is easy to understand and provides all of the control they need in a very straightforward way.
Why should a business care about the back-end?
John: How much control should a business have over its website?
Tim: The answer to that question is one the business should determine, but at IMPACT we always want to see companies have a dedicated marketer who has ownership over their website content.
As a result, that marketer should have all of the controls they need to manage their website and the expectation for that should be a part of the initial conversations.
Then, this becomes the responsibility of whoever is building the website to build that experience.
Additionally, their job is to build the template structure used on the front-end which means a website developer actually has multiple end-users to take into consideration, whereas a website designer and content editor only have one.
It’s always best to plan when you’re able to, but it can be hard to future-proof a website. We’ve found that there is an ideal balance between flexibility and structure that allows the content editor to easily control what they need without limiting their options.
Many marketing websites are built on a static template structure which provides a pre-built layout for the editor to add content to but it does not allow them to fine-tune their pages or adjust the design to better fit its purpose.
Rather than building templates in this way, at IMPACT we prefer to design based on the purpose of various types of content and allow the editor to combine them however they need rather than force them to settle on a few specific templates.
How IMPACT builds websites
John: How does the way we build websites help make the back-end more user-friendly for non-coders?
Tim: We previously built many of our websites on a static template structure but we found that it wasn’t a good editing experience for our clients.
Since the layout and overall design of the template was predetermined, any variation was typically impossible or required a developer to go in and make updates to the template.
As a result, sometimes the requested change could be difficult to implement since the design was shared among multiple pages.
The change could require a lot of planning or discussion to figure out what was needed, and sometimes it meant that our clients might be waiting multiple days or weeks before our team had the availability to actually implement the change even if it was relatively quick.
For a typically small request, it just didn’t make sense to keep doing things that way.
Our solution was to start looking at pages as a combination of sections instead of a single template. This is a change in mindset which begins at the very start of our design process.
Rather than building full templates, we consider the different layouts that are needed to create all of the pages on a website and provide our clients with a structure that lets them easily combine and configure them as needed.
The result of this is an editing experience that gives the marketer full control over their website but provides them with an intuitive foundation to work with.
They are able to build completely new website layouts without needing to know code or design since the structure is already in place.
They are able to make retroactive changes without waiting on a developer or going through the design process again.
But, most importantly, content variation is prioritized from the start so they already have everything they need to build new pages even if it’s something that wasn’t specifically planned for.
A website is the most important tool a marketer can have, and our goal is to train and empower our clients so they are able to take ownership of their marketing — so we build our websites around that mindset.