Aging Design: How to Keep Your Websites Young
Websites are like people. The birth is where the decay begins. Just like yourself, you can keep your website in good nick. This takes good care. Find out how exactly that's supposed to look like here.
In the beginning, it's a feeling of being in love. The world is beautiful, the flowers are blooming, the air is pleasantly balmy. Your own website is live, and it looks fantastic.
After all, that's the most important thing, right?
[caption id="attachment_104495" align="aligncenter" width="1024"]
During spring, (a developer's) life is simple. (Photo: Pixabay)[/caption]
I know this feeling. I've been working with media since 1994. Small and large projects are scattered on my path. I still take care of some of them today, while I have dropped some, and had to drop some. However, the hardest projects have always been the one that I had to - or let's say - was allowed to take over.
These include some large projects that looked to be in great shape in the beginning. Upon closer investigation, it was obvious that the opposite was the case.
Can I throw this away? In this example image, the answer is clear. (Photo: Pixabay)[/caption]
Barely any client is willing to pay for the proper, and very elaborate analysis of this question. Thus, you maneuver yourself through data junk and inscrutable structures that you ignore, hoping that you ignore them with good reason.
Problem #2: 404 Errors
Wherever there's too much data, there's a lack of data in another place. Who's supposed to keep an eye on all the formerly active sites, and remove them if necessary? Let's not do that, it costs money.
Even if there are no real 404s, you'll always find broken links - basically 404 on detours. At some point, someone decided that content XY is no longer needed, and removed it. He didn't consider the fact that this content was linked to the pages A, Q, and Y, though.
In some cases, there are small issues regarding .htaccess and mod-rewrite. In other cases, you actually need to manually remove weak spots.
Simply ignoring it is no option, as the problem affects the ranking, and decreases the site's visibility. Additionally, visitors could easily stumble across these mistakes - especially when coming from a Google search result page. I guess you can imagine how trustworthy this makes you seem.
Problem #3: Defective External Links
In a project that I took over, I found close to 72,000 external links. Can you imagine my level of excitement?
You shouldn't ignore this problem either. The Google rank suffers heavily from defective external links. No matter how much effort you put into your SEO: if you don't fix broken external links, you'll destroy everything you just built.
[caption id="attachment_104500" align="aligncenter" width="1024"]
No link holds forever. (Photo: Pixabay)[/caption]
Additionally, linking sites that don't exist (anymore) is not a sign of high-quality content. The possible loss of trust is hard to measure, but not neglectable either.
Probleme #4 and #5: Unclear Code Blocks and Outdated Functions
I'm wording this a bit vague on purpose. To me, unclear code blocks are snippets of any kind in all parts of a website.
Especially under WordPress, we commonly encounter sites that don't work properly, even though they should work at a glance. I've spent days searching for the responsible code snippet that some developer has implemented years ago, wherever the solution was the easiest to accomplish. Coding standards? What's that?
In this context, I often find outdated functions from earlier language versions - especially PHP -, which you certainly wouldn't use anymore.
Problem #6: Content Management Systems and Blends of Different Platforms
There are content management systems that you can't update just because there's a new update. And even with CMS' where this is possible, you don't know if you should actually do that. You never know if, and to what extent, previous technological caretakers have tampered with the core. Until a few years ago, this was pretty much a standard thing to do.
[caption id="attachment_104499" align="aligncenter" width="1024"]
CMS gone wild: when clear structures turn into a maze. (Photo: Pixabay)[/caption]
Content management systems set up by so-called web developers, which basically have no idea of these systems, are just as bad. In the worst case, you won't even find the structure that the CMS originally defines.
Things get even worse when the entire nomenclature was ignored. At this point, any update can be the sudden death of the website. Likelihood? Over 100 percent. This happened to me a few years ago, using a Contao installation.
Another thing I can't get enough of are blends of CMS and non-CMS. For instance, the page operator wanted to add a database query, but the previous web developer didn't know how to do that with the given CMS. Thus, he simply flange-mounted an HTML site connected to an external MySQL database that delivers the desired information. If you're lucky, you've noticed this before handing in your offer - I doubt it.
Problem #7: Technological Principle Decisions of the Year Dot
They still exist today: sites that don't work on mobile devices. Even worse: sites that will never work on mobile devices.
In the year 2000, on the Internet World fair in Berlin, I looked into barrier-free web design for the first time. Even back then, the approach relied on future web standards, allowing sites to be designed more or less independently from the display device. Sure, that was a lot of work. And barely anyone was willing to put in that much work (and even less were willing to pay for it).
[caption id="attachment_104496" align="aligncenter" width="1024"]
Designer, don't go through the wrong door. (Photo: Pixabay)[/caption]
Those still sitting on a site that can't be mobilized have missed out on all trends for a very long time. However, these slugabeds do exist - and they even operate large projects.
Another project I took over years ago fully relied on Flash. Even back then, building everything on Flash wasn't necessary. The service provider was trying to become indispensable in the long run - and he succeeded. The client only contacted me once the Flash agency was shut down. Luckily, it was rather easy to convince the client that he had to let go of his website.
Writing has never hurt anyone. (Photo: Pixabay)[/caption]
Updates should be documented, especially if there were problems. Which problems occured, and how were they fixed? You'd be surprised if you knew how much this could help you in the distant future.
Generally, I have to recommend:
Website fitness takes effort, but no vitamins. (Photo: Pixabay)[/caption]
You should also stay up to date regarding coding standards. On one hand, you have to be aware of which functions are considered outdated, and have to be replaced, on the other hand, you have to pay attention to basic standards like the separation of form and function.
Although this may seem like a detour right now, you'll be happy about it if you ever end up in that situation. And the person that will be allowed to take over your project will be especially thankful.
During spring, (a developer's) life is simple. (Photo: Pixabay)[/caption]
I know this feeling. I've been working with media since 1994. Small and large projects are scattered on my path. I still take care of some of them today, while I have dropped some, and had to drop some. However, the hardest projects have always been the one that I had to - or let's say - was allowed to take over.
These include some large projects that looked to be in great shape in the beginning. Upon closer investigation, it was obvious that the opposite was the case.
The Most Common Projects of Twenty Years of Experience
Yes, a project can soot like an old chimney, or calcify like the deep cervical artery of a smoker. It's an equally creeping process, with equally drastic potential consequences. In the following, I'll introduce you to what are by far the most common problems that I've encountered over the past 20 years, all the way until this day. Problem #1: Abandoned Content and Data Junk By far the biggest problem is the sheer size of the projects. Organically grown websites contain very scattered branching in the folder structure, and a massive amount of dead files. The problem is that it's not easy to tell what's still needed, and what can be deleted. [caption id="attachment_104497" align="aligncenter" width="1024"] Can I throw this away? In this example image, the answer is clear. (Photo: Pixabay)[/caption]
Barely any client is willing to pay for the proper, and very elaborate analysis of this question. Thus, you maneuver yourself through data junk and inscrutable structures that you ignore, hoping that you ignore them with good reason.
Problem #2: 404 Errors
Wherever there's too much data, there's a lack of data in another place. Who's supposed to keep an eye on all the formerly active sites, and remove them if necessary? Let's not do that, it costs money.
Even if there are no real 404s, you'll always find broken links - basically 404 on detours. At some point, someone decided that content XY is no longer needed, and removed it. He didn't consider the fact that this content was linked to the pages A, Q, and Y, though.
In some cases, there are small issues regarding .htaccess and mod-rewrite. In other cases, you actually need to manually remove weak spots.
Simply ignoring it is no option, as the problem affects the ranking, and decreases the site's visibility. Additionally, visitors could easily stumble across these mistakes - especially when coming from a Google search result page. I guess you can imagine how trustworthy this makes you seem.
Problem #3: Defective External Links
In a project that I took over, I found close to 72,000 external links. Can you imagine my level of excitement?
You shouldn't ignore this problem either. The Google rank suffers heavily from defective external links. No matter how much effort you put into your SEO: if you don't fix broken external links, you'll destroy everything you just built.
[caption id="attachment_104500" align="aligncenter" width="1024"] No link holds forever. (Photo: Pixabay)[/caption]
Additionally, linking sites that don't exist (anymore) is not a sign of high-quality content. The possible loss of trust is hard to measure, but not neglectable either.
Probleme #4 and #5: Unclear Code Blocks and Outdated Functions
I'm wording this a bit vague on purpose. To me, unclear code blocks are snippets of any kind in all parts of a website.
Especially under WordPress, we commonly encounter sites that don't work properly, even though they should work at a glance. I've spent days searching for the responsible code snippet that some developer has implemented years ago, wherever the solution was the easiest to accomplish. Coding standards? What's that?
In this context, I often find outdated functions from earlier language versions - especially PHP -, which you certainly wouldn't use anymore.
Problem #6: Content Management Systems and Blends of Different Platforms
There are content management systems that you can't update just because there's a new update. And even with CMS' where this is possible, you don't know if you should actually do that. You never know if, and to what extent, previous technological caretakers have tampered with the core. Until a few years ago, this was pretty much a standard thing to do.
[caption id="attachment_104499" align="aligncenter" width="1024"] CMS gone wild: when clear structures turn into a maze. (Photo: Pixabay)[/caption]
Content management systems set up by so-called web developers, which basically have no idea of these systems, are just as bad. In the worst case, you won't even find the structure that the CMS originally defines.
Things get even worse when the entire nomenclature was ignored. At this point, any update can be the sudden death of the website. Likelihood? Over 100 percent. This happened to me a few years ago, using a Contao installation.
Another thing I can't get enough of are blends of CMS and non-CMS. For instance, the page operator wanted to add a database query, but the previous web developer didn't know how to do that with the given CMS. Thus, he simply flange-mounted an HTML site connected to an external MySQL database that delivers the desired information. If you're lucky, you've noticed this before handing in your offer - I doubt it.
Problem #7: Technological Principle Decisions of the Year Dot
They still exist today: sites that don't work on mobile devices. Even worse: sites that will never work on mobile devices.
In the year 2000, on the Internet World fair in Berlin, I looked into barrier-free web design for the first time. Even back then, the approach relied on future web standards, allowing sites to be designed more or less independently from the display device. Sure, that was a lot of work. And barely anyone was willing to put in that much work (and even less were willing to pay for it).
[caption id="attachment_104496" align="aligncenter" width="1024"] Designer, don't go through the wrong door. (Photo: Pixabay)[/caption]
Those still sitting on a site that can't be mobilized have missed out on all trends for a very long time. However, these slugabeds do exist - and they even operate large projects.
Another project I took over years ago fully relied on Flash. Even back then, building everything on Flash wasn't necessary. The service provider was trying to become indispensable in the long run - and he succeeded. The client only contacted me once the Flash agency was shut down. Luckily, it was rather easy to convince the client that he had to let go of his website.
How to Avoid These Problems
The best advice I can give you, regarding the future of your web projects, is the following:No experiments!Never rely on the newest, neatest horse, but stick to established standards. Of course, a certain foresight into the future should still be given. The future of our branch is pretty easy to tell. Proprietary solutions are never the right path. With large providers of proprietary solutions, strategy changes will ruin your business before you can say deoxyribonucleic acid. Another piece of advice:
He Who Writes, Remains!It doesn't hurt to take care of a meticulous documentation of your web project. What is used where, why and how? Which conventions apply, and what for? If there's a corporate identity, it has to become the design guideline. [caption id="attachment_104498" align="aligncenter" width="1024"]
Writing has never hurt anyone. (Photo: Pixabay)[/caption]
Updates should be documented, especially if there were problems. Which problems occured, and how were they fixed? You'd be surprised if you knew how much this could help you in the distant future.
Generally, I have to recommend:
Keep it rolling!404, broken internal links, and non-existent external links don't turn into problems if you document every change to your site, and pay attention to the side effects and interactions. Ten errors are quickly fixed during operation. Once 10,000 errors have accumulated, things get tough. [caption id="attachment_104494" align="aligncenter" width="1024"]
Website fitness takes effort, but no vitamins. (Photo: Pixabay)[/caption]
You should also stay up to date regarding coding standards. On one hand, you have to be aware of which functions are considered outdated, and have to be replaced, on the other hand, you have to pay attention to basic standards like the separation of form and function.
Although this may seem like a detour right now, you'll be happy about it if you ever end up in that situation. And the person that will be allowed to take over your project will be especially thankful.