Table of Contents
In this part of website maintenance mini series we will discuss the last 7 tips to make maintenance easy and fast. We will start with tips on improving code readability and testing for browser compatibility. Then, we will move to accessibility, usability and how to optimize for speed. Finally, we will discuss content, SEO optimization and gathering feedback. Is it possible to make website maintenance fun again? Maybe, we will find the answer to this question in this article. Let’s begin.
Tips no.1-4 are in part 1.
Tip no.5: Improve code readability
Let’s assume that you are done with refactoring the CSS and JavaScript code. This means that you’ve removed all unnecessary and duplicate code. As a result, you were able to reduce the amount of code to a reasonable level. I also hope that you used some markup validation service to test your HTML and CSS code. If you did this, we can safely say that the first part of website maintenance is complete. However, this is just a beginning this process.
Using comments in a smart way in your HTML, CSS and JavaScript code
Another step you can take to make website maintenance as easy as pie, is by using comments in the right way. The truth is that we can use comments in many different ways. For example, we can “disable” fragments of code. We can temporarily remove fragments of code to try out different ideas and concepts. However, we can also use comments to make the markup more readable. This approach can be applied to all of them HTML, CSS and JavaScript.
How to comment your HTML code
Let’ start with HTML. My current practice is to mark the beginning and the end of bigger container elements. For example, it would be nonsense to use comments in this way for labels. Labels usually don’t contain too much other code or elements. Therefore, it is quite rare to have label spanning dozens of lines of code. However, what if you have something like a grid container? In that case, it can happen that this container will contain a decent amount of other elements. As a result, you can easily lose track of where it begins and where it ends.
When you always mark the beginning of the container, and its end with short comment, you can avoid this. It can be as simple as container’s class or id inside the comment on the beginning and on the end. This practice will help you even if your HTML code will be quite complex. You will still be able to identify what comment belongs to what element. Let’s say you are using basic bootstrap grid template. You have one main container that works as a wrapper for the main content. Inside this container, you have two rows. Each row then contains four columns with some content.
Example:
<div class="container">
<div class="row">
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div>
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div>
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div>
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div>
</div>
<div class="row">
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div>
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div>
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div>
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div>
</div>
</div>
This is relatively simple example. Yet, we can already see that it can be a little bit difficult to distinguish ending div tags. Fortunately, the example is using article element. Otherwise, it would be even worse. Now imagine how would the code look like if we marked every div with comment at the beginning and at the end.
Example:
<!-- Begin .container -->
<div class="container">
<!-- Begin .row -->
<div class="row">
<!-- Begin .col-xs-6.col-md-4.col-lg-3 -->
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div><!-- end .col-xs-6.col-md-4.col-lg-3 -->
<!-- Begin .col-xs-6.col-md-4.col-lg-3 -->
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div><!-- end .col-xs-6.col-md-4.col-lg-3 -->
<!-- Begin .col-xs-6.col-md-4.col-lg-3 -->
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div><!-- end .col-xs-6.col-md-4.col-lg-3 -->
<!-- Begin .col-xs-6.col-md-4.col-lg-3 -->
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div><!-- end .col-xs-6.col-md-4.col-lg-3 -->
</div><!-- end .row -->
<div class="row">
<!-- Begin .col-xs-6.col-md-4.col-lg-3 -->
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div><!-- end .col-xs-6.col-md-4.col-lg-3 -->
<!-- Begin .col-xs-6.col-md-4.col-lg-3 -->
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div><!-- end .col-xs-6.col-md-4.col-lg-3 -->
<!-- Begin .col-xs-6.col-md-4.col-lg-3 -->
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div><!-- end .col-xs-6.col-md-4.col-lg-3 -->
<!-- Begin .col-xs-6.col-md-4.col-lg-3 -->
<div class="col-xs-6 col-md-4 col-lg-3">
<article>
<!-- content -->
</article>
</div><!-- end .col-xs-6.col-md-4.col-lg-3 -->
</div><!-- end .row -->
</div><!-- end .container -->
Thanks to this cosmetic improvement, our code is more readable and easier to understand. Imagine that you work with another web developer or designer. Let’s say you would create basic HTML for a blog and then pass it on one of your colleague to add content. Your colleague would the pass it one someone else who would style it. To make this process as fast as possible, it would be crucial that everyone can quickly orient. Which example do you think would work better?
How to comment your CSS code
Just like with HTML, we can use comments to bring a little bit more clarity also to our CSS or Sass code. Thanks to that, website maintenance, in the sense of styles, will get much easier. In case of CSS (Sass), I like to use single and multi-line comments. This helps me distinguish between larger and smaller fragments of code. For example, I use multi-line comments to mark each Sass file I use in my atomic framework such as atoms, molecules, organisms, templates and pages.
Example:
/**
* Buttons
*/
.btn {}
On the other hand, I use single line comments to mark smaller parts of these files. The best example would probably be some file larger file such as template for homepage. In this file, I would again use multi-line comment to mark the beginning of the file. Then, I would use single line comments to divide individual sections of the file.
Example:
/**
* Homepage template
*/
/* Section one */
.sec-one {}
.sec-one .content {}
/* Section two */
.sec-one {}
.sec-one .content {}
Comments and Sass
In case of Sass, I also like to use single line comments for files containing styles that will not be compiled into CSS. For example, Sass files with dedicated to variables, functions, mixins and placeholder selectors and so on. These fragments of code are not directly compiled into CSS inside single file. Therefore, adding classic comments from CSS syntax would be nonsense. You would end up with lines of comments without any code.
Example of file for variables:
// // Variables // $radius--big: 4px; $radius--full: 35px; $radius--small: 2px; $shadow--lvl-1: 0 1px 3px rgba(0,0,0,.12), 0 1px 2px rgba(0,0,0,.24); $shadow--lvl-2: 0 3px 6px rgba(0,0,0,.16), 0 3px 6px rgba(0,0,0,.23); $shadow--lvl-3: 0 10px 20px rgba(0,0,0,.19), 0 6px 6px rgba(0,0,0,.23);
Example of file for colors:
// // Colors // $color--text: #111; $color--primary: #1e88e5; $color--secondary: #d81b60;
Comments for better usability
Many we designers also like to use CSS comments for describing fragments of code. I think this is a good practice not just for website maintenance. It is also very useful if you are working on the project with other people. In that case, you can use comments to describe what some specific styles do. You can also use comment block to include link to page where the style is used. Then, everyone will be able to work with your code, even if you will not be around.
Example:
/**
* Monochromatic table
* Custom-style monochromatic tables used to outline financial data. Table is using monochromatic colors to make keep the data readable.
* usage: table class has to be added right to the table tag.
* example: stats.html
*/
.monochroma-table {
…
}
How to comment your JavaScript code
To make the website maintenance easier, you can also use comments in JavaScript code. Let’s say you are using some language built on JavaScript such as CoffeeScript or TypeScript. In that case, you can use comments in the same way as is Sass. For example, if you like to split your scripts to modules, you can use comments to mark each module. Even if you don’t like to split your scripts into smaller modules or fragments, you can still use comments to improve readability of your code.
One good use of comments if to create documentation for functions and methods. Example of short documentation for function could contain a couple of things. First, it could include a short info about what the function does. Second, it could say what parameters are necessary and in which type. Third, it could say what is the result. Let me give you one example using jsdoc style.
Example:
/**
* Adds two numbers
* @param {Number} x
* @param {Number} y
* @return {Number} sum
*/
function sum(x, y) {
return x + y;
}
Comments or markup language
I should mention that JSDoc I used in the example above is a little bit more complex. It is not just bunch of random terms. JSDoc is markup language used to annotate JavaScript code. As such, JSDoc gives you a big advantage. You use it to generate documents in formats like HTML or RTF. This will help you scale up your project and make website maintenance easier. However, what if you’re not interested in anything like JSDoc? What if you are looking for a way to use simple comments, not learn new syntax? No problem.
You can use large blocks of multi-line comments at the beginning of functions to explain it. Also, if you want to use single line comments to insert comments on specific lines, go ahead. Find what works the best for you and fits your needs. Remember that the most important thing is to be consistent. It doesn’t matter if these guidelines will be only for you. It will make website maintenance much easier. When you create set of rules for how you document your code, you will be always able to understand it. You’ll know how the code works and how to use it.
Simpler example:
/**
* Function that adds two numbers
* These two numbers are provided as parameters x and y.
* Both parameters has to be either integers or floats.
* The output of this function is either integer or float.
*/
function sum(x, y) {
return x + y;
}
Use indentation and empty lines
There is one more way in which you can improve readability of your code. You can, and should, use consistent indentation and empty lines between HTML elements. The same applies to CSS rule-sets and JavaScript statements. In case of indentation, it is up to you to decide your preferred style – hard or soft tabs. My personal preference is to use soft tabs. It is for a couple of reasons. First, different text editors treat hard tabs different. For example, UNIX editors prefer hard tab is eight spaces. On the other hand, Windows editors and IDEs prefer that a hard tab is four spaces.
Second, trying to reach any agreement between editors in the terms of the “right” length of hard tab is already lost battle. Third, the same applies to agreement between people. Ask five developers on what’s the “right” hard tab length and you will get five answers. One solution is to drop hard tabs and prefer soft tabs (spaces) instead. This will help you avoid problems with readability of the code. Still, before you set any rules for your team, have a discussion about it.
Readability improvements in teams
If you work in a team, there is another thing you should consider. When you work with other people, code documentation has to be in line with the output of your team. The same thing applies also to team standards. Your documentation also has to work well for all members of the team. Therefore, when you decide to create documentation or style guide, it should be based on group agreement. Don’t try to force anything. Focus on open discussion and let everyone contribute. Otherwise, documentation will not work so well for your team.
Tip no.6: Test browser compatibility
Another important part of website maintenance process is testing browser compatibility. There is no doubt that we have to make sure our website works properly across different browsers. This is, in the end, part of the work our clients or employers are paying us for. Our clients or employers basically want to know just one thing. They want to know that they can present their website anywhere and any time. They don’t want to be afraid that the website will break because they loaded it on Firefox instead of Chrome. Therefore, we have to test it properly.
Old browsers and decisions makers
It is easy to say that we as web designers have to test websites on older browsers. However, this is very vague. How old has the browser be in order to include in testing? What about browsers that are too old, almost ancient? Should you invest your time into testing the website on these browsers as well? Where is the line between browser that is old and browser that is too old? Who should answer these questions? This is a lot of questions. Let’s take a look at the answers.
Let’s start with the last question because it is the least relative and easiest to answer. In the majority of situations, you should be the decision maker. This means that it should be you who will determine what browsers are relevant for testing. It is your job, not your client or your employer. There are at least three reasons for that. First, you are supposed to have more information about current state of browser usage. You don’t have to know the exact numbers for every browser.
Still, you should have at least some idea about current distribution. And, you should be able to tell your client these numbers in convincing way. Your client has to understand why you ditched this specific version of this browser. The second reason is that your client will probably not know what browsers his customers use. Even if he will know this, he will not know whether these information are useful for you. Meaning, he will not know what technologies and features will you use.
The third reason is that you are professional web designer. Your client hired you to do specific job. Therefore, you should do the whole service. This also includes advising your client about recommended technologies and practices for website maintenance.
Old and too old
Let’s suppose that you accepted that you are the decision maker in case of the tech side of the project. The next thing is to decide which browsers are too old and you are safe to ignore them. This is not an easy question to answer. There will be always some masochists using old operating systems (probably pirated) with older browsers. In most cases, this will be minor group of users, unless you are in China. Should you ignore these users completely?
Let me give you this answer. Yes and no. Or, it depends. Do you have any data from analytics provided by your client? Chances are that these data will help you solve this dilemma. Chose browser versions with significant percentage of usage among visitors. What if you don’t have any data at all? Who is your client’s target user group? Client’s website has to be optimized on specific customer or user persona. Use these information to find statistics about browser usage.
If neither of these options is available, there is third way. Take a look at website such as CanIUse. This is a great source of information. Many web designers use this website only to find current support of all features and technologies across all major browsers. However, it also contains statistics about current distribution of users among the major browsers. However, these information are only estimates, they are still better than having nothing at all.
The question of Internet Explorer
I guess that the majority of you will probably be interested in Internet Explorer. Should you support version nine? What about version eight? Or, should you calmly ignore both of these versions? Y immediate answer is “yes”. Supporting Internet Explorer 8 is just nonsense. Unless I am wrong, even html boilerplate dropped support for IE8. Well, they are talking about it constantly on GitHub. If these cautious guys are thinking about it, I think that you can ignore this version.
What about Internet Explorer 9? Based on project I worked on this year, this version is also pretty much dead. Every project I worked on supported only Internet Explorer 10 and higher. Sometimes, even support for version 10 was result of moment of nostalgia. In other words, it seems that clients are willing to slowly leave Internet Explorer 10 behind as well. This is my suggestion. First, use IE 10 as the lowest version for support. Second, discuss with your client going for 11.
The Big Five (Chrome, Firefox, IE, Edge, Safari)
The last question related to website maintenance and testing browser compatibility is which browsers you should focus on. This answer is easy. Just focus on the big five. These are Chrome, Firefox, IE (10+), Edge and Safari. I intentionally skipped other browsers such as Opera, Blisk, Vivaldi or Tor. Although these browsers use different “brand” name, they are using engines of the big five. For example, Opera and Blisk are both built on webkit. Unless I am wrong, the same is true for Vivaldi. Tor is built on Firefox.
As you can see, if you test your website on all major browsers, you will cover the majority of potential issues. If you are like me and you usually work with Chrome, I would suggest that you focus mostly on tests in Safari and Edge. Sometimes, Firefox can require some fixes. Still, it is great browser pushing the web forward. The majority of work will be done in Safari and Edge. So, make sure to cover these two browsers.
The last thing I want to say about browsers and compatibility testing. It is part of your job. Don’t look for shortcuts or ways to speed it up. Make sure the website is working flawlessly everywhere. Your client will see and appreciate your effort. I saw a lot of web designer half-assing this of the process. Also, if you are not sure about what browsers to support, remember this. The sooner you decide the better. Otherwise, it will hold you back from making any progress on the project.
Tip no.7: Test accessibility and usability
Another part of website maintenance process should be focused on testing its accessibility. First, you should make sure that your website is usable on different devices. This doesn’t mean just responsive design. Accessible and usable design goes beyond mobile phones, tablets, desktops and anything in between. Website that is built with accessibility in mind has to work on devices that are more “exotic”. Example of such a device can be screen reader or eBook reader.
Usability and going beyond visuals
When we build websites for these devices, we have to go beyond design and visuals. We have to think carefully about the content and its structure. Devices such as these readers are often quite limited when it comes to visual features. In the best-case scenario, you will get black and white version of the website. In the worst-case scenario, you will get only rough transcript of the website – only the text and images. This means at least one thing. Every decision that’s related to which element should you use will have significant impact.
If we translate this into simpler language, putting h1 everywhere will not work. From now on, you should do following. First, learn about the description and recommended use of HTML elements. The best place for that will probably be documentation created and maintained by W3C. Yes, it is a longer read, but it is worth it. When you finish it, you will be able to deliver outstanding outputs that work everywhere. In case of website maintenance, you will be also able to correct badly written websites. I know that these are small details. However, details are what really matter.
The second you should do is to learn about and follow the best practices. Many times, there is a difference between recommended and best practice. We discussed this in the first part of this article about website maintenance in the section about JavaScript linters. It can happen that linter will tell you to do one thing and best practice another. Then, it is better to follow the best practice than recommendation. The only exception could be when best practice is outdated. If best practice is derived from old version of syntax, following newer recommendations is better.
Accessibility and ARIA
Building accessible website also means that you may have to consider different ARIA role attributes. Many HTML tags already contain these attributes. For example, aside, nav, header, main, footer all contain role attributes. This means that these attributes don’t have to be explicitly written in the syntax. However, there are many other attributes that has to be written in the code. How can you know which one? First, take a look at the documentation for ARIA roles. Second, when in doubt, write every role attribute. It is better to write more some attribute “twice”.
Third step is to use HTML validator. This tool will help you with a couple of things. It will help you find any bugs in the syntax. It will also help you analyze the structure of the content (proper use of headings, etc.). Finally, it will notify you about using ARIA role attributes that are not necessary. Let’s say you implemented default attributes for elements such as main, footer, aside and header. Then, validator will notify you that these elements don’t require these attributes and you can safely remove it without doing any harm to accessibility.
Accessibility, usability and health
The second side is about making sure your website is usable for people with various health problems. For example, some people are colorblind. In this case, the biggest problems are caused by blue, red and green colors. You have to make sure color palette of your website uses contrasting colors. So, even if someone can’t recognize specific color, she will still be able to say that its different shade. Quick way to test this is by turning your website into black and white version. Try to apply grayscale filter on the html or body element. Are elements easy to distinguish?
Tip no.8: Optimize for speed
Website maintenance should also include optimization for speed. It is not enough to optimize your website once, when you launch it. You should do this every time something new is added. Or, even better, you should automatize it. If you are using task runner such as Gulp, you can use plugins to streamline this process. Then, these plugins will do the work for you automatically. Anyway, how can you optimize your website for speed?
Compress everything
The first thing is to minify all HTML, CSS and JavaScript files. This is simple task that will not take too much time. Before you minify everything, I would suggest that you create backups. You can also use two versions of assess. One version will be used for development (ugly) and the second for production (minified). This is a common approach to web development. The second thing is to take care about other assets such as images. These files should be compressed.
You will be surprised how much space you can save when by compressing these assets. Fortunately, you don’t have to afraid of losing quality. Proper tools will be able to compress your visual assets and you will not see any difference, except in the size of the file. My favorite toolkit includes JPEGmini, PNGoo and SVGo. If you use Gulp, there is a plugin for that.
Build mobile first
My third and last tip for website optimization is probably not so useful for website maintenance. Build every website mobile first. You no longer start with desktop. Instead, you start your design and development with mobile screen and increase the resolution. This may be uncomfortable for designers used to “desktop first” design. However, I believe that it helps you design faster. Designing for mobile screen is often the hardest, especially if you begin with desktop.
Should you squeeze it, remove it or completely restructure it? When you begin with mobile screen you have to make all these decisions immediately. Everything that comes after it is usually easier because you get more space. As I said, this is not as useful for website maintenance because the website is already built. However, it is a good thing to know for future web development. Also, you may convince your client for rebuilding the website because it will make future maintenance easier. I know, it will take some time. However, you will provide your client with better service.
Tip no.9: Keep your content fresh
Another tip for website maintenance is related to its content. Do you want to keep your website up-to-date? Then, you will have to regularly update or remove old content. Sure, this may not be part of your job. However, if it is, don’t ignore it. Fresh content can help your website in any ways. First, fresh content can be great material to share on social media. This way, you can get new visitors to your website. These visitors can then become your customers (or your client’s).
Second, fresh content will show search engines that your website is still active. Otherwise, its rank could start to decline. Remember, search engines like active websites that are updated regularly. Third, doing this content audit will help you discover broken links, missing assets and other issues. What if you are not in position where you can’t control the content? You can still suggest couple ideas to your client. Doing so will show that you care about your work.
Tip no.10: Improve SEO
Part of website maintenance should be also regular check of SEO relevancy. First, your website should be optimized for SEO. This means that your page titles and descriptions has to be set correctly. You should also specify which pages should be indexed and which shouldn’t. Reviewing robots.txt file can be also a good idea. You may want to disallow search engine bots from indexing some directories. Next, you should review your sitemaps. If you don’t have it, create it.
The lastly step is to analyze the content of your website. Make sure you are using keywords that are relevant to the content. Also, make sure you are using the right amount of keywords. Too much will look like a spam and too little will not do the work. To make your website search engine friendly you have to stay somewhere in the middle. If you know someone skilled in SEO optimization, ask him on some tips. Just stay away from any black hat tips and tactics. First, they usually don’t work well or for too long. Second, potential penalty outweighs potential benefits.
Tip no.11: Gather feedback
The last tip for thorough website maintenance is to gather feedback in the end. When you are done with everything, ask your friends or colleagues to take a look at the website. When you do that, make sure to ask the right people. Asking someone who never saw line of code to review quality of your code is a waste of time. To review your code, reach out to other web designers and developers. To test usability and accessibility of the website, you can ask anyone.
The upside of this type of testing is that no knowledge is required. You just want to know if your website is fast and easy to use. However, you will get the best result by asking people with different backgrounds and age. In other words, test the website on your adult friends, their kids and also your grand parents. If you are lucky and have grand grand parents, ask them as well. If they can use your website even without knowing how to use smartphone, you did good job.
Closing thoughts on website maintenance
Congratulations! You’ve completed the second part of this website maintenance mini series. We discussed a lot. In a recap, you should start the process with improving code readability. This means using HTML, CSS and JavaScript comments in a smarter way to divide individual modules. You can also use comments for better usability by writing small description about the code. If you want to take this farther, you can use markup language to generate documentation for your code.
Website maintenance is also about testing browser compatibility. You have to make sure your website works perfectly on all major browsers. What versions will you support depends on you, just make sure to test on the big five. Next, functional website is also about accessibility and usability. Make sure your website can be used by devices such as screen or eBook readers. Also, some people have health issues such as colorblindness. Test contrast of your website for this as well.
One of the keys for high-quality website is speed. Today, we want everything to be fast. Visitors will give your website only a few seconds to load. And, there is usually no second chance. Therefore, compress and optimize everything you can. If you are building the website from scratch, build it mobile first. Forget the desktop. Start with mobile screen and go up. Fresh website also requires fresh content. Part of website maintenance should be regular content audit. Improve what you can and remove what is no longer relevant.
Part of the content audit should also be testing and optimizing SEO. Make sure you are using all required meta tags and relevant keywords. Lastly, you should ask for feedback. Let other people test your website. Watch their reactions and listen to their suggestions. That’s it.
If you liked this article, please subscribe so you don't miss any future post.
If you'd like to support me and this blog, you can become a patron, or you can buy me a coffee 🙂
Become a Patron
