The most important question that clients fail to ask is how we go about building websites. The actual process, techniques and rules that we follow when we solve problems, develop custom functions and organise stylesheets.
What I am going to do here is explain exactly how we go about building sites, what technical solutions we employ, how we organise code, how we make our decisions and how we address uncertainty. This will be a long page. I am going to be as detailed as possible whilst avoiding technical jargon. Feel free to skip to relevant sections using the navigation panel.
A website is a technical product and there is a huge variety of methods, processes and solutions for developing websites. Each process, even the bad ones, have pros and cons designed to make the work easier for that developer or team. To clients, some of those cons are unacceptable and some of the pros are absolute requirements.
But since most clients don’t ask what methodology their developer follows, they taciturnly accept the pros and cons that their developer decides. If they have a bad developer, or even a good but specialised developer, those pros and cons may be unacceptable to them. However, if they only find this out at the end of the project, they usually have to accept the status quo and/or they may not even be aware that there is a better way.
Introduction to concepts
Every decision has a pro and a con
But first there is an oft overlooked reality that we need to establish. Almost every decision made in development has a pro and a con.
Usually, every decision is a trade off with a pro and a con in one of the following attributes:
- Time and cost of developing the website
- The skill required by the developer who builds it
- The user friendliness of the backend
- Loading speed of the site
- The minimum requirements needed of the server
- Control of the code, layout, style and functions
- Dependency on 3rd parties
- Risk of having a security / stability flaw
- The cost to fix each security / stability flaw when they happen
E.g., an off the shelf slider plugin like Revolution Slider is fast to install and requires no coding knowledge to setup, but it’s fiddly and frustrating to use and slows the website page load speed down dramatically. Alternatively, a build it yourself slider such as Flexslider is much leaner and faster and is easier for a user to edit but needs a skilled developer to setup.
Likewise, an atomised portfolio input system (where you have a single data specific input field for each for bit of data: e.g. subtitle, description, gallery, testimonial) is easy and intuitive for even the office junior to use and produces consistently templated pages but removes the freedom for that editor to build their own layout if they feel a specific portfolio item warrants it.
An introduction to WordPress
WordPress is our CMS (Content Management System) of choice. It’s not the only one we use. We have worked in dozens of others. But it’s the one with the greatest market demand and so it’s the one we work in as standard.
WordPress was developed as a blogging platform and was later altered to be used as CMS for commercial websites, but its internal logic is still very much what you expect a news website to need.
The core role of WordPress is to be an interface between a set of files (that include: the sites stylesheet; the sites function files; the site’s image files; and the sites templates) and the site’s database (which includes: the content; revision history of the content; menu system; user list; and general site settings). WordPress is a very good technical solution at this core role.
However, there is complication, which is ironically both the biggest strength and the biggest weakness of WordPress as a platform. That is that it is very easy to install plugins that extend the functionality of WordPress.
This is great because it means that an awful lot can be done quickly and cheaply. Don’t know how to install Google Analytics in the header.php file? Search for Google Analytics in the plugin library and in two clicks you can install a plugin that will put an input field in the backend of WordPress so you don’t need to.
This is a problem because it incentivises shortcuts and these shortcuts have consequences.
This is especially risky if the purpose of the plugin is so simple that no developers use it. No one with the skill to inspect the code in the example Google Analytics plugin would need to use it, so would never have installed it on their projects, and never would have looked at it. Thus, you can be pretty sure that that plugin has little or no community oversight and is a fertile place for malicious players and the mistakes of underdeveloped developers to fester.
Alternatively, a plugin like ACF (Advanced Custom Fields), which is a partial website solution that handles creation of inputs and requires a developer to then code the outputs, and is used exclusively by developers, is under constant peer review and scrutiny and thus is a very safe and well-made plugin.
However, a more frequent problem than security is inefficiency. Most of the plugins designed to be used by non-developers work by creating an interface in which you set what functions you want and then it saves those settings in the database. However, that’s not how databases were designed to work. They are using MySQL (the database) to do a role that PHP was beautifully designed for. It’s the equivalent of using a power drill to hammer in a nail. It’ll do it, but it’s so much slower, messy and prone to unwanted complications.
Each coding language used in website development: PHP (server-side functions), JS (device side scripts), MySQL (database), HTML (templates) and CSS (styling) are intelligently designed to efficiently solve the kind of problems that you encounter in their area. If they are used in the manner that they were designed to be used the site will be fast and stable and any issues will be easily identified and resolved.