Why Bother About Web Quality ?
Yeah.. why, really ? As long as it works… So 90's… Today, we have all the tools we need to do our job, and do it well. But what is web quality ?
A translated definition, from a really good French book would be:
Web quality is the ability of an online service to satisfy explicit or implied needs.
from Opquast: “Qualité Web : les bonnes pratiques pour améliorer vos sites”
Beyond this definition, from Temesis’ book, many sides of our everyday job are Web quality related:
- Accessibility
- Security
- Performance
- UX
- Ergonomics
- Tests
- Documentation
- etc.
This notion of quality is perfectly attainable by every one of us, and we have to take it into account in the early stages of a project.
Think “quality”
What are our projects goals?
We want to give our customers an accessible, efficient, scalable and maintainable solution. A solution that satisfies its needs. And to achieve this, we often have to find the good compromises.
Most of the time, a dialog starts between you and your customer, who wants a fast, good and cheap project. But unfortunately, it’s barely possible.
The customer is not (always) a bad guy, trying to rip you off. He himself just doesn’t know what he really wants.
Being attentive
A quality job often starts with being attentive. Beyond what we sell, we play a key role: we’re the customer’s guide, his adviser. We have to make him think about and understand his OWN needs. How many times have you been asked for a website capable of brewing coffee (to deliver by yesterday) ?
We need to ask the right questions, provoke questioning, and be sure that we all work towards the same direction. This way, we avoid useless back and forth contacts, and reduce disappointments (“I did not picture it like this…” says the customer).
It’s also an opportunity to tackle technological constraints. This step is crucial, as it allows us to define a scope and give greater responsibilities to the customer, regarding his priorities. Moreover, when you take the time to explain him what is doable and what is not (and why), you take part in his digital skills improvement !
What is vital for me ?
Once your project starts off on solid bases, you can start working. Each actor in the project must be involved in your quality approach.
Be careful, don’t start overdoing, giving your team members every single quality book or accessibility guidelines you can find.
Remember, too much information kills information, and that would only make them feel frustrated, or think that quality is really hard to attain, even unattainable. Hence, work won’t be done.
Instead, start small.
Ask yourself what is vital in your quality approach. Prepare some simple checklists, for every profession. These checklists, which will fit your team skill level, will grow by themselves.
Some points will automatically be treated and, as your team skills grow, as they suggest improvements, you’ll adapt your checklist, leading to an even more qualitative job.
It will be the project’s common thread. It will give your team the feeling of constantly going forward. It will be the end of asking your designer to create a 404 page or a favicon the day before you launch, you will not have to urgently compress scripts on the production server anymore. (Don’t lie, I know you’ve done it !)
Produce “quality”
To produce quality, actors of the project must be aware of their responsibilities. Every actor. You have to raise awareness among them, involve them in every phase of your reflection, listen to their suggestions. It’s an educative and rewarding job.
If needed, there are a lot of great books to read, and professionals are always ready to help via social networks (especially on Twitter).
Code quality
It’s at the heart of production. The 90’s mantra “it’s good since it works” makes no sense.
« Programs should be written for people to read, and only incidentally for machines to execute. »
- Structure and Interpretation of Computer Programs. Abelson et Sussman
At the time when open source becomes more and more on the rise, here’s a piece of advice from Captain Obvious: you’re programming for other people !
Even on a personal project, it will allow other developers to take part and push the project forward.
In a web agency, it’s a guarantee for the future. What would you do if the main developer, who worked on this specific project, were to go away ? What if he must work on another project ? What if you need to hire a freelancer to continue his job ?
Some best practices then seem vital:
- Respect the standards
- Focus on accessibility
- Test and comment your code
- Use explicit names for your variables and functions
- etc.
With this, we make sure that the project is maintainable and durable, while maximizing the compatibility with existing tools (essentially browsers)
Since the topic of this post is not to give a full list of tools, I’ll just mention W3C validator, WCAG, Opquast checklists, task runners, etc.
Documentation quality
A documented code is a maintainable code. Writing documentation makes us think beforehand. By the way, I recommend you have a look at Thomas Parisot’s talk about README Driven Development.
A good documentation includes context, goals, sources, concrete examples. Talk about why, how, etc…
Quality is expensive (?)
Many times, you’ll hear the customer say he won’t pay more for a quality website. And he’s right. A website MUST be of good quality. When you buy a car, you expect it to fully work, not only to have 4 wheels and a metal frame.
Producing quality must become an habit, a normal and automatic approach.
Between us, rest assured: costs quickly decrease drastically. The main idea is to capitalize on previous projects and automate processes.
From a project to another, you won’t have to browse Google once again to find GZIP compression htaccess instructions, or how to activate cache. You will already have created those exacts same files during your last project, following your quality checklist !
What does this bring ME ?
Well, at the end of the day, a lot of things.
You, or your agency, have better processes and are more effective. Your brand image quickly improves.
Your team improves, and developers feel valuable. Everybody is involved in the quality approach and everybody can propose improvements. The produced work is therefore better and better. Continuous improvement spotted.
The end user is happy too. Your product is fast, efficient, accessible, documented.
And, last but not least, the customer is satisfied and is saving money, most of the time.
Avoid the pitfalls
As with all process, we have to stop at a certain point. Following Pareto’s principle, aka 80–20 rule.
80% of demands can easily be achieved. The other 20% depend on several factors and often require a lot of additional time. In our job, time factor is really expensive.
Does this additional time required to deal with those 20% really worth it ? Will the end user, the customer, be happier ? Do I have the required resources to do it ? If I do it, will the services, the content suffer ?
We cannot influence social widgets quality, should we still use them ? How to deal with user content quality ?
That’s many things to think about. If you understand French, reading Elie Sloïm’s “Conformité, validation et sursqualité” could help you position the boundary.
Just do it
Benefits are obvious. Just produce quality. Do it by your own if you’re the only one in your team to believe in this approach. Even if people tell you you’re losing your time.
Do it because you like to get things right. Do it to improve your skills. Do it for continuous improvement.
Just do it.
PS : useful links
Thanks for reading ! If you liked this post, please use the button below to recommend it and follow me :)
