DEV Community: Émile Perron

A Comprehensive Guide to Website Testing

Émile Perron — Tue, 29 Nov 2022 17:13:12 +0000

Let's say you built a new website. It looks good, and you're happy with it, and your clients are happy about it too. Fantastic!

But before you launch it for the whole world to see, how are you to know if you've made a mistake? Did you forget to remove placeholder content somewhere? Or miss a bug that will cripple your visitors' experience?

If you want your website to be tip-top, there is no way around it: you must test it!

In this guide, you'll find everything you need to know to start testing your sites. Clear instructions, battle-tested tools, curated resources and more await in the lines below.

So what are you waiting for? Jump in and give your visitors the high-quality browsing experience they deserve!

Before you start testing

Define the scope of your project

Testing a website without defining a scope is sure to cause never-ending changes. And never-ending changes are sure to cause tensions.

To avoid that, take a few minutes to think about each of the key points below. This will help you define ahead of time which types of issues you must resolve, and which types you can ignore.

If you're working with a team, make sure you do this part together. You may have different perspectives, opinions and knowledge. Unifying these early on will help you avoid problems later on.

‍

Deadlines

You don't want to find yourself having to launch when you haven't yet tested your most important pages.

So before you get started with the testing, you need to know what your deadlines are.

Here are some questions to kick-start your discussion on that topic:

When do you need to launch the site?
Can you push back the launch if need be?
Does someone have to approve the changes you make? If so, how long will that take? Should you plan time in case they request more changes at that point?
If you run out of time, can you do more changes after the launch?

You should also discuss any other factors that may affect your deadlines.

Defining the deadlines ahead of time will help you define how much testing you'll be able to do. Once that's known, you can set priorities and plan accordingly.

‍

Target audience

A website selling skateboards will be different than a site about retirement pensions. They have completely different purposes and audiences.

With different audiences and purposes come different expectations and requirements. Knowing your audience is important. It will help you make good decisions for the user experience when testing.

Here are a few examples of questions you may want to ask yourself:

Is the audience tech-savvy?
Are they looking to buy something or to get information?
Do they know what they're looking for, or do you need to help them find it?
Do they have the same vocabulary? (ex.: they look for "oak trees" while you use the term "Quercus Fagaceae").

Answering such questions will help you understand if your design and UX are appropriate.

‍

Client expectations

Even if you know the audience well, your clients may have extra requirements that you didn't think of.

They may have special accessibility and/or user privacy needs. They may need special features that are specific to their industry. They may need to have legal notices on certain pages.

Oftentimes, clients provide these requirements early on in the project's lifecycle. But they may have forgotten - or perhaps you have!

Make sure you are aware of these requirements before you start testing and implementing changes.

‍

Laws and regulations

The last thing you want is to get your client sued (or to get sued yourself). To prevent that, you have to be aware of the legal requirements for the website you build.

There are many basic laws and regulations for web development. Elementor's Starting Guide to Legal Compliance offers guidance on the most popular ones.

You should also be aware of any industry-specific laws that apply. If you're not sure, make sure to ask your client(s). If they aren't sure, recommend that they contact an attorney to learn more about it.

‍

Define clear roles for team members

If your team doesn't have a testing process in place, make sure you define clear roles for who does what.

Here are a few questions to help you define the roles:

Will one person test the entire site, or will you split the testing among many people?
Will the person who tests the website also fix the issues they notice? Or should they report them to the team to get them fixed?
How will you keep track of the changes you make during the testing process? Should you inform someone about them?

What should I test?

Now that you've established the scope of the tests for your project, it's time to start testing!

First off, every page on your site should load without any blatant errors. Okay, you probably did not need our guide to figure that part out.

Here is a comprehensive list of things you should test your websites for.

‍

First impression

When visitors first come to your site, you have about 10 seconds to capture their interest.

If your website does not clearly communicate what it's about and how it can help the visitors, you're toast. End of story. Goodbye!

There are countless guides on how to improve your landing pages, but here is a quick summary:

Clearly state what your website is about, in a way that your target audience will understand right away.
Keep things simple: too many options and attention-grabbing elements can confuse visitors.
Have a clear call to action to guide your visitors.
Avoid popups, overlays, prompts, flashing chat boxes, etc.

‍

Content

Writing great content and formatting it for the web can be tricky.

Here are a few guidelines to make sure your pages present content that is helpful to users and that they will read it:

The content is formatted into easily scannable chunks, with short paragraphs, (sub)headings, lists, etc.
Each page starts with the most important piece(s) of information.
Every piece of content serves a purpose: there is no filler content.
The content is free of typos, grammatical errors, etc.

About that last point: you might have heard that pages need a certain word count to be "good". But that's a bit misleading.

Your website's content is only good if it helps your target audience. If you can provide the same amount of value with fewer, simpler words, you should do that. Write your content for humans, not search engine algorithms.

‍

Navigation

So you have good content. Awesome!

But... can your visitors find it?

Ensuring your visitors can easily navigate through your site to find the information they're looking for is key.

To get started, here are a few things you should verify:

The logo in the header links to the homepage.
The navigation contains links to all of the main pages and sections of your site.
Every link in the navigation works correctly and leads to the right place.
Dropdown menus and mega menus work as intended.
The mobile/tablet menu button (often referred to as the "hamburger" button) opens the navigation when it is clicked or tapped.

Searchability

Not every website has or needs a search feature. But most common CMS, such as WordPress, Webflow and Shopify offer search functionalities.

If your site has many pages containing lots of information on various topics, it could likely benefit from being searchable.

If you do offer search features, here are a few more things you should ensure:

All relevant types of content are indexed in your search engine.
Search results are appropriate and sorted based on relevancy and/or closest matches.
Typos, accented characters, capitalization and pluralization in search queries still result in appropriate results.
Your results page clearly indicates when no results are found, and suggests alternatives.

‍

Design

Design is very subjective: what pleases one person may be despised by another.

Despite that, here are a few design guidelines that will provide a better user experience:

Photos and images on each page convey relevant information (i.e. avoid useless stock images).
Clickable elements (links, buttons, paginations, etc.) have clear visual indicators showing that they can be clicked.
The icons used on the website are either standard and immediately recognizable or are accompanied by a text label.
Empty states are designed and implemented for all lists that could potentially be empty.

Additionally, if you have a large website with lots of pages, products and/or articles, you should ensure that visited links are displayed in a different colour or style in order to look "used".

‍

Usability

Even a well-designed site with good content can push visitors away if it's riddled with annoying bugs and usability issues.

We don't know exactly what your website contains in terms of interactive elements, but here are a few things to ensure when testing:

Every link on the website works as intended (W3C's Link Checker can help find dead links, but only a human can check if a linked page actually matches the link's label/intent).
Information that only appears on hover is adapted on touchscreens such as mobiles and tablets (learn more about this by reading Cíntia's article: Mobile doesn't have hover, dude!).
Audio and video players do not start automatically on page load.
In-page tabs work as intended, and each tab's content matches the tab's label.
Carousels, slideshows, embedded maps, and all other widgets are working as intended.

‍

Forms

Online forms are incredibly useful for businesses and site owners.

But when they're done wrong, forms can easily become the number one pain point for your visitors.

Make sure the following points are respected in every form, and you should be in a pretty good state.

Content and layout

Every form asks for as little information as possible.
Forms are presented in a single column (unless fields are very closely coupled... and even then, exercise caution).

Form fields

Required fields are marked as such in every form.
Labels are close to the fields they describe.
Labels are not displayed as placeholders within inputs.
In longer forms, related fields are grouped together.
Each field uses the right type of input and is sized according to its expected value.
Fields with requirements or limitations have their instructions clearly explained as help text under the field's label.

Form errors

Error messages provide clear indications of what is incorrect and of how it can be fixed.
Error messages in forms are placed right next to the field containing the error.

Form submissions

Forms are protected from spam bots (see reCAPTCHA vs hCAPTCHA vs Friendly Captcha).
Forms display or redirect to a success message when they are submitted.
Form submissions trigger some sort of communication with the person responsible for the website or the form.

I've seen issues with the latter happen so often that I will repeat it once more, just to make sure it's not forgotten:

Form submissions trigger some sort of communication with the person responsible for the website or the form.

This means your form should send an email or a text message, or be submitted to a CRM. The person on the receiving end must be made aware that a new form submission came in!

There is nothing more annoying for all parties than form submissions not being received by the person who's responsible for them. Visitors get no answer, and site owners get a bad rap for something that is often not their fault. So please, as a personal favour to me, make sure you test this for every form!

‍

Responsive

Depending on your target audience, the devices from which they browse your site will vary a lot.

But in most cases, you can expect the majority of your traffic to come from mobile devices and tablets.

That's why testing your site on a variety of devices is key to ensuring that your visitors get the best experience possible, no matter what device they use.

Here is a list of devices and resolutions we recommend you test your site on:

A Chromium browser (Google Chrome, Microsoft Edge, Opera, Arc, etc)
Firefox
Safari
Mobile devices of various sizes (e.g. iPhone, iPhone Pro Max, iPhone SE, etc.)
Tablets of various sizes (ex.: iPad, iPad Pro, iPad Mini)

If you know some of your visitors use a specific device that isn't listed above, make sure to test it as well!

When testing on phones and tablets, make sure you test on both device orientations (portrait and landscape).

That's a lot of devices!

The most efficient way to do this is to own a wide range of devices and to test your websites on those devices. But as you can guess, it can quickly get complicated and costly.

If you don't want to do that, you can test your website with BrowserStack. Their service allows you to interact with real devices of just about any kind: iPhones, iPads, Android phones and tablets, MacBooks, and more.

Although testing with a service like BrowserStack isn't as smooth and responsive as testing on your own devices, it is still incredibly helpful as it allows you to detect problems on devices and browsers you do not have access to.

‍

Browser compatibility

Now that Internet Explorer is retired, browser compatibility is much easier than it was before.

But that does not mean it's not worth testing!

There are still many different browsers in use today:

Firefox
Safari (iOS Safari and macOS Safari)
Chromium-based browsers (Chrome, Edge, Opera, Arc, Samsung Internet, and more).

These browsers all differ from one another. An easy way to see how much they differ is to look at CanIUse's Browser Comparison.

Even the Chromium-based browsers differ from one another depending on the version of Chromium they use and the browser-specific implementations they provide.

This is why testing on every major browser, as well as any other browsers your visitors are likely to use, is important.

Here is a list of browsers and devices we recommend you test your site on:

A Chromium browser (Google Chrome, Microsoft Edge, Opera, Arc, etc)
Firefox
Safari
iPhone (iOS Safari)
Android mobile device (Chrome, Samsung Internet)

Just like testing for responsive design, using BrowserStack to test on devices and browsers that you do not own can be incredibly helpful.

‍

Social

There's no denying that social networks are a big part of most people's life nowadays.

To make the most of that, make sure your website looks good when it's shared on social media, and that your social media channels can easily be found on your website:

Every public page has an og:image meta tag with an image that represents the page/article.
Every public page has an og:title meta tag with the page/article's title formatted for social media previews.
Every public page has an og:description meta tag with a short and appealing snippet describing the page.
Every public page has an og:url meta tag with the page's canonical URL.
Every public page has a twitter:card meta tag indicating the type of card to use for display on Twitter (learn more about Twitter Cards).
The website's footer (or header) contains links to the brand's main social media accounts.

To learn more about this, take a look at our Social Media optimization page.

‍

Accessibility

To quote the W3C:

Web accessibility means that people with disabilities can equally perceive, understand, navigate, and interact with websites and tools. It also means that they can contribute equally without barriers.

Making sure your website can be used by everyone is simply the right thing to do.

Plus, depending on your type of organization, your location, your audience and/or the locations from which your site is accessible, you may have to comply with certain web accessibility laws and regulations. The W3C has a great tool to find accessibility laws and policies that apply to you.

In any case, here are a few basic guidelines to ensure a minimal level of accessibility for your website:

Pages use <h1>-<h6> heading tags to organize the structure of the content.
Elements use semantic HTML whenever possible (e.g. using <section> or <article> instead of <div class="section"> or <div class="article">)
Every image that conveys information or context provides a textual alternative via the alt attribute.
Every decorative image has an empty alt attribute, indicating that it is not relevant to the content of the page.
Every page can be navigated logically using only the keyboard.

Accessibility is a very vast subject, and these are just a few pointers to get you started.

To learn more about accessibility, check out our Accessibility page: you'll find short explanations on the subject and great resources for accessibility testing.

‍

On-site SEO

Search engine optimization is a field of its own, and it can become pretty complex if you dive into it head first

SEO is no different than most of the other sections in this article, there is a myriad of things that can be done to improve your site.

Here are the essential things to test for on-site SEO:

Every page has a <title> tag with a unique title (if possible, keep it around 50–60 characters).
Every page has a short meta description that tells users what they can expect from the page.
Every page has a simple URL that is easy to read and understand (i.e. real words, not numbers or random characters!).
Every page defines its canonical URL.
Every page loads in less than 3 seconds (more about this below).
Old URLs that have been renamed or removed are redirected to their new location via 301 redirects (and have been tested).
Alternative domain names redirect to your primary domain name (e.g. mywebsite.com and www.mywebsite.com, or mywebsite.ca and mywebsite.com).
The robots.txt file allows search engines to crawl all public pages.

Once these checks have been done, your site has its SEO basics covered. But as we said, there's a lot more to SEO than what we covered in this list, and it can be a good skill to have if you're building many websites for clients.

If you want to go further, we recommend you take a look at Moz's Guide to SEO.

‍

Loading speed

As stated earlier in this article, you only have about 10 seconds to convince your users that your site is worth visiting.

If your page takes 7 seconds just to load and become interactive, that leaves very little time for you to convince people.

Plus, making sure your pages load and become usable quickly improves your users' experience, which should be your #1 goal.

Here are some of the main things you should look at to improve your page speeds:

Every image is sized appropriately and optimized.
Render-blocking JavaScript is removed, deferred, or executed in a web worker.
Render-blocking stylesheets are reduced as much as possible.
CSS, Javascript and HTML are minified.
Browser caching is enabled.
Compression is enabled.
Unnecessary redirects are eliminated.
Your server has adequate resources and configurations to handle your traffic (reducing server response time).

To start testing your website's loading speeds, check out our Loading Speed page. ‍

Moz's write-up on Page Speed can also be a good place to start if you want more information about improving Page Speed.

‍

Security

Most of us have seen or heard about sites that got hacked or imitated by bad actors, or of user information being stolen and sold online.

These guidelines will help you reach a basic level of security for your site:

An SSL certificate is set up and configured for auto-renewal.
Requests to non-HTTPS URLs are redirected to HTTPS.
A Content Security Policy is set up on the site to prevent script and data injection.
The x-frame-options header is configured to prevent click-jacking attacks.
Website backups are set up and configured to run frequently.

If your site manages any information about your visitors or users, especially personal information, you should make sure to apply best practices in your development and to vet the libraries, services and vendors you use to ensure that they are secure as well. Neglecting to do so may result in fines and legal trouble, so it's worth taking the time to learn about beforehand.

‍

Editability

If the website you built will be managed by someone else, they need to be able to edit it.

That's not gonna be a problem: the site is built with a CMS!

Are you ready to hear the bad news?

If you do not make any special effort to make using the CMS easy and intuitive, you'll find that most clients will have a hard time using it.

And when people have a hard time using a CMS, the likelihood of the website breaking skyrockets. 💥

So you have to put in some effort to make it more intuitive for your clients. But how?

Here are a few tips to guide you:

Keep in mind that your users are likely not tech-savvy.
Keep in mind that new people are likely to take over the website management role without receiving much training (if any).
Be consistent when naming things. Using two different words to mean the same thing can be confusing.
Name things using your client's vocabulary, not yours.
Disable and/or hide sections, features and links that are irrelevant to your clients.
Add guardrails where possible: validating client inputs and actions can prevent the majority of issues that commonly "break" websites.
Guide your clients: if your CMS allows you to add help text, use that to provide context and clarifications.

These tips may seem simple, but stick to them! Use every opportunity your CMS gives you to make the admin experience better, and it will most definitely pay off.

It's also important to note that some platforms have a better user experience for their administrators than others:

Wordpress's admin panel is known for becoming increasingly bloated and confusing with every plugin you add. This can be improved by reducing the number of plugins you use and by hiding unnecessary sections and navigation links with plugins or custom code.
Shopify's basic features are easy to use, but third-party applications often come with their own management interfaces which aren't always as straightforward or intuitive. This can be improved by researching and testing different apps to find the one with the simplest interfaces and workflows.
Webflow's Editor does a great job of keeping things simple and intuitive for clients, as long as you adequately name your collections and pages.

Improving your client's experience will not only make them happier: it also reduces the number of support requests you receive from them. It's a win-win! ✨

‍

Analytics

If you want to get some data about how your site is doing after you launch, you should set up some sort of Analytics service.

The most commonly used platform for this is Google Analytics. But Google Analytics is already illegal in some EU countries, and will likely be ruled illegal in many others in the future unless they take a sudden turn.

At Koalati, we recommend you analyze your analytics needs and go with a privacy-friendly alternative like Plausible or Fathom. You can also browse a more complete list of Google Analytics alternatives.

‍

A few more things...

These last few things might not be as crucial as the rest, but they're good to test for as well:

The website has a working favicon that matches the brand.
The 404 (Not Found) error page matches your brand and contains link(s) to the website.
The site's system and plugins can be updated safely and easily without major risk of breakage.

‍

And... that's it! You're done!

Congratulations, you have thoroughly tested your site and are ready for launch! 🎉

Summary

Thoroughly testing a website before launching it is essential to ensure a high-quality user experience.

You need to think about:

First impression;
Content;
Navigation;
Design;
Usability;
Forms;
Responsive;
Browser compatibility;
Social media optimization;
Accessibility;
On-site SEO;
Loading speed;
Security;
Editability;
Analytics;
... and even more!

To help guide you through the process, Koalati offers a comprehensive website quality control checklist, which you can use to test your sites along with your teammates and report issues that need to be fixed.

How to disable Webflow animations for users who prefer reduced motion

Émile Perron — Fri, 19 Aug 2022 19:10:11 +0000

Webflow animations and interactions can really make a site shine.

However, some of your visitors might be dizzied by all of the fading, twisting, shifting and scaling that Webflow allows you to create. Others might just prefer websites to be more static and information-focused.

These users often have the "Reduce motion" setting turned on on their computer.

Respecting this user preference is important to improve your site's accessibility, especially for animation-heavy sites.

In this article, we'll show you how you can disable your Webflow animations and interactions when prefers-reduced-motion is turned on.

‍

The code

Let's skip straight to the part you're most likely interested in: the code!

Here is the short script that you can add to your site's footer via the Site settings > Custom code tab in Webflow:

<script>
    // Cancel Webflow animations for users who prefer reduced motion
    if (window.matchMedia("(prefers-reduced-motion)").matches) {
        const cancelAnimationsInterval = setInterval(function () {
            if (typeof Webflow == "undefined" || typeof Webflow.require == "undefined") {
                return;
            }

            clearInterval(cancelAnimationsInterval);

            // Stop Webflow's handling of animations
            Webflow.require("ix2").destroy();

            // Reset the inline styles for every element that has already been initialized
            const animatedElementsSelector = "[style*='will-change'], [style*='opacity: 0']";
            for (const animatedEl of document.querySelectorAll(animatedElementsSelector)) {
                animatedEl.style = "";
            }
        }, 10);
    }
</script>

You should place this script at the very top of your footer's custom code. Otherwise, slow or heavy scripts that precede it might prevent it from stopping the animations early enough, which could result in a weird flash of animated content for visitors with reduced motion turned on.

‍

How it works

When you add this script in your site's footer, it appears before the closing </body> tag.

At that point, Webflow's interactions script should already have been loaded and initialized, but not enough time has passed for the browser to render the animated element's starting styles.

The script first checks if the user prefers reduced motions. If they do, it will:

Wait until Webflow's script has loaded.
Tell Webflow to stop processing and handling interactions and animations.
Remove inline styles on elements that Webflow already started animating.

In practice, all of this happens within a few milliseconds.

From the visitor's point of view, your site will simply appear as though it does not have any animations when loading the page or scrolling.

For visitors who don't have the "prefers reduced motion" setting turned on, the script doesn't do anything: your site will appear as you designed it, animations and all!

‍

Before & After

Here's a preview of Koalati's website, which is using this script, with and without the prefers-reduced-motion setting turned on.

‍

With prefers-reduced-motion turned OFF.

‍

With prefers-reduced-motion turned ON.

‍

A few things to keep in mind

Hover, focus and active effects aren't affected.

This script only disables the animations generated via Webflow's Interactions tab.

Your hover, focus, focus-visible and active styles are not affected by this script, and will therefore remain unchanged.

This is by design, as hover, focus and active states are important for your site's accessibility.

‍

Animations generated by custom code aren't affected.

If you use custom code (Javascript and/or CSS) to create animations and interactions, these won't be disabled by this script.

Only animations and interactions generated via Webflow's interactions tab are disabled by this script.

‍

All inline styles are removed from animated elements.

This script will automatically remove all inline styles from the elements that are usually animated (when visitors have prefers-reduced-motion turned on).

For most Webflow sites, this won't be an issue.

However, if you intentionally add inline styles on some elements that also have Webflow interactions, you should make sure that these elements aren't broken when this script is introduced.

If they are, you can try to update the animatedElementsSelector to ignore those elements.

If that doesn't work, you'll likely need to adapt the code to match your needs.

‍

If you use Webflow Interactions for important components (ex.: menu burger button), this script is not adequate for you.

Seeing as the script disables all Webflow interactions, you'll want to implement your own solution if you use Interactions for important components such as a menu toggle button.

However, you should be aware that using Webflow interactions for important interactive components is generally not great for accessibility to begin with, unless you manually add custom code to handle the accessibility side of it.

Summary

Disabling Webflow interactions and animations for users who prefer reduced motion is an easy way to improve your site's accessibility, especially if you use a lot of animations.

Luckily, for most sites, it can be done in just a few minutes thanks to the short code snippet we provide in this article.

Which tech stack should I choose?

Émile Perron — Fri, 08 Jul 2022 16:18:14 +0000

Are you looking to build a website for your product or company?

Or perhaps you already have a website and you're thinking about revamping it?

In this article, we'll help you understand:

What a tech stack is;
How the stack you pick affects you and your users;
What matters most when selecting technologies.

Ready? Let's dive into it!

‍

What's a tech stack?

Simply put, a tech stack is the choice of technologies you use for a particular project.

Every technology you use to build, deploy, test, maintain and update your project is a part of your "tech stack".

Are you building on a website builder like Squarespace or Wix? Are you using a no-code or low-code hybrid like Webflow? Are you setting up a Wordpress website? Are you creating a complex web app with React? Are you using a CSS framework like Bootstrap or Tailwind? Are you connecting to external APIs? Are you managing a web server yourself? Are you hosting your site on GitHub pages, or perhaps Netlify?

The landscape of web technologies is evolving quickly, with new technologies being released just about every week. There is a near-infinite number of combinations to choose from.

So before starting development on a project, you need to decide which tools and technologies to include in your tech stack.

‍

What should I take into consideration when choosing a tech stack?

Before we go into more details, here's a summary of things to take into consideration:

Speed
Speed again
Security
Accessibility
SEO
Maintainability
Platform limitations
Community
Ease of use
Pricing

Let's dive into each of these elements to help you better understand what to look for.

‍

Speed

Speed is paramount on the modern web.

You want every user interaction to be as fast as possible:

Pages should load and become usable as fast as possible;
Loading of data within a page or component should be as fast as possible;
User-created content (ex.: a blog post, a comment, etc.) should be posted and displayed as fast as possible;
Emails and text messages (ex.: 2FA, email confirmation, etc.) should be sent and received as fast as possible;
... you get the point.

Every technology you use should therefore be well optimized to reduce unnecessary processing and connections.

This applies to both backend and frontend technologies and solutions, as both will impact the user's experience.

‍

Security

Just about every language and technology used on the web is secure when used as intended.

However, when adding external solutions and integrations into your project, you'll want to make sure they're secure.

Additionally, hacks and data leaks are always a possibility, no matter how secure a product might seem.

To defend yourself against potential attacks or leaks, you need to make sure that the services and technologies you use:

have access to as little of your users' data as possible;
safely hash and/or encrypt any sensitive or personal data;
do not share your data with other services or platforms unnecessarily.

‍

Accessibility

Speed is an essential part of the user experience, but it's not all there is to it.

When choosing user-facing technologies and solutions, you want to make sure that they allow you to build good-looking interfaces that are functional and intuitive. You also want to make sure that people can actually use these interfaces.

When evaluating technologies with which to build your app or website, make sure they either generate accessible interfaces and features by default or that they allow you to freely edit the HTML to improve the accessibility yourself.

When evaluating an external tool, service or integration where you don't have any control over the interfaces and the code behind them, you'll want to make sure these interfaces and features match your accessibility standards.

‍

SEO (Search Engine Optimization)

Just like accessibility, your technologies should either be SEO-friendly right off the bat or allow you to edit the code so that you may add search engine optimizations yourself.

This relates to meta tags, usage of semantic elements, pre-connection to external origins, and many more.

If indexability and SEO are important for your project, you'll want to make sure you either go for a server-side or statically generated website / app, or with a SPA hybrid that allows you to render meta tags and other such elements on the server so that they're available without Javascript. This will allow crawlers who don't execute Javascript (which is... most of them) to find the data they need to display your site correctly in search results and social media previews.

‍

Maintainability

If you are planning on updating and maintaining your site or application over time, you need to make sure that the technologies you choose won't die out in the coming years.

A good way to determine if a technology will still be maintained and viable is to:

check if it is still maintained right now (this may seem obvious, but you would be surprised at how many people start using "archived" technologies without knowing it);
check if it has a public release schedule with plans for the upcoming months or years;
check how many people are contributing to its development and maintenance (the more active and recurring contributors, the better).
check if it heavily depends on other technologies that are likely to not be maintained in the near future.

You also have to look into what it takes to keep the system up to date and running smoothly.

Here are a few more questions you can ask yourself when thinking about the maintainability of your new site:

Can I update it myself?
Do you need an expert to take care of it?
If we have to bend this platform out of shape to do what we need, how easy will it be to maintain?
If I need to find someone new to maintain the project in the future, how many capable people are available in the market?

‍

Known limitations

We've touched on that before, but you need to know a technology's limitations before you can decide if it can work for you.

For example, a no-code / low-code website platform like Webflow doesn't have a backend you can access and develop on. It doesn't have an easy-to-use file uploader and manager if you need to manage documents outside of its Collections feature. It also includes the jQuery library by default on your site, and you can't remove it.

For some people, these limitations are deal-breakers. For others, they won't ever be an issue.

At Koalati, we use Webflow to build and run our marketing website (the one you're on right now). Some of the limitations are minor pain points, but we knew about them ahead of time, and we decided it was worth the trade-off for the speed of development it offers.

Because we knew the limitations ahead of time, we were able to make that decision knowing full well that there would be minor pains, but never any major issues.

This is the type of decision you're about to make, so researching the limitations ahead of time is a must.

‍

Community

Many people aren't aware of this, but most web developers and designers heavily rely on online communities in their daily work.

Communities are useful to help debug an issue, to find inspiration, to ask about best practices, to get a second opinion, and much more.

Communities also contribute to the development and improvement of a platform or technology.

Finally, the size and level of activity of a community are also good indicators of how large the talent pool for that particular technology is. This may be important if you need to find new people to help you maintain the project in the future.

That is why it's important to make sure that there is a thriving community around a platform or technology before building your project around it.

‍

Ease of use

It's important to make sure that the end result will be easy to use by both the users and the project's maintainers.

A good example is a blog platform that requires the maintainer to use Markdown or HTML to write a blog post. This might be great for the person who's maintaining the blog at the moment, but what if that person quits or has to delegate that task? Wouldn't a regular text editor have been a better option?

There is no one-size-fits-all answer here: ease of use varies based on the target audience. So think about who will be using which tool and which feature, and plan accordingly.

‍

Pricing

Different stacks come with different price tags.

Before building your entire project on top of a technology, you need to make sure that you understand the pricing implications and that you can support this price for the lifetime of the project.

You also need to consider how much time a platform or tool can save you (or how much more money it can make you!), as well as what the tradeoffs are.

For example, you can easily find a hosting provider that will charge you $1.99/month and give you the domain for free. But:

Is that price going to change after your first year or two?
Is that domain only included for the first year?
Does that hosting have any significant limitations? (speed, server location, server resources, etc.)
Is maintaining your site on that platform taking much longer than on an alternative platform?

Just like platform limitations, understanding pricing is important as it's something you might be stuck with for a very long time.

So make sure you understand the pricing structure and requirements before making that long-term decision.

‍

Your tech stack doesn't matter.

Now that we've covered all of the elements that do matter, let's skip to the hard-hitting truth: your tech stack doesn't really matter.

The truth is that most technologies can deliver good speed, security, accessibility and SEO when they are used correctly.

Of course, we're talking about actively maintained and updated languages, frameworks, libraries and platforms - you don't want to use COBOL (an ancient language used in many legacy systems) to run your backend.

But X is better than Y!

You might have heard that technology X is better than technology Y!

Some technologies have a bad rap, but a lot of that is based on personal preferences and experiences (which are often biased and/or out-of-date).

Unless you are building a high-availability platform with thousands of simultaneous requests and you plan on maintaining that platform for 10+ years, it's unlikely that you'll run into major technical issues, no matter which major technologies you use.

Just keep things as simple as possible while ensuring fast speed, accessibility, SEO and maintainability.

‍

If the stack doesn't matter, what does?

The most important part of a project's development and maintenance is the team behind it.

Experience, motivation and care

A non-experienced team (or an experienced team that doesn't care) might deliver horrible results, even if they use the "best and latest" technologies. On the other hand, an experienced team who cares can deliver an outstanding experience to your users, even if they don't use the newest tech available.

If your project is handled by a motivated and experienced team who truly cares about what they are creating (and the people who will use it), your tech stack doesn't matter.

Let me say that twice, just to make sure it sticks in your brain.

If your project is handled by a motivated and experienced team who truly cares about what they are creating (and the people who will use it), your tech stack doesn't matter.

Whenever a choice has to be made, the team will decide what's best for the project and its users based on the criteria laid out above (along with other context-specific criteria).

If your team is skilled and cares about the end-user, chances are the stack they choose will work just fine.

‍

Summary

A tech stack is the combination of technologies with which your project is built, deployed and maintained.

But the specific stack you go for doesn't matter a whole lot, as long as you go for technologies that:

are actively maintained (and that will be maintained in upcoming years);
have an active community behind it;
match your needs;
can deliver a good experience to end-users.

What really matters most is the mindset, intent and experience of the team that builds your website or application.

If you have access to skilled people who know what they are doing and who really care about the end-user, chances are the stack they choose will work just fine.

We publish these website audits not to shame the teams behind the sites, but to educate creators on how to audit and improve the websites they build.

Web components in 2021: the Good, the Bad and the Ugly

Émile Perron — Sun, 02 May 2021 16:42:47 +0000

Web components are a native set of features that provides outstanding scoping of styles and functionalities. They can be used in a regular, framework-free web page, but also with any Javascript framework of your choice (e.g. React, Vue, Angular, Svelte, etc.). This makes web components excellent for building reusable elements that need to be shared publicly or reused across multiple projets. At least, in theory.

In reality, there are some drawbacks that can make web components almost unusable in some projects.

In this article, I will explain what makes web components great, what their drawbacks are, and I will provide some guidance to help you decide whether or not you should use them in your projects.

The Good

The two main features that make web components powerful are the Custom Elements API, and the Shadow DOM.

The Custom Elements API is what allows you to create and register your components as new HTML elements. It also allows you to define lifecycle callbacks for your new element. Overall, it is pretty great and fairly simple to understand and get into, for both novice and experienced developers alike.

The Shadow DOM is what provides all of the encapsulation of styles. It gives your components their own DOM, which is separate from the rest of your document. This means that global styles cannot affect it (except for CSS custom properties / variables), and that its own styles cannot affect other elements in the parent document.

The HTML <template> and <slot> elements are also used in most custom elements, allowing you to easily create templates with dynamic content without having to reach for a third-party templating system or language.

Browser support for all of these features is great: unless you're still supporting Internet Explorer, you're unlikely to run into any deal-breakers. There is one exception to this, which will be explained later in "The Bad" section.

Plus, as mentioned at the start of the article, not only are web components compatible with just about every Javascript framework out there, but they can also be used in good old vanilla Javascript, without a framework. That's because web components are basically just ES6 classes extending the native HTMLElement. That means you can share components across your project or your company's entire ecosystem.

Additionally, there are some great libraries and packages to make building web components easier, as well as an online platform where you can find and share web components with others: webcomponents.org.

The Bad

Flash of Unstyled Content

Let's start with the Custom Elements API. The only drawback I have experienced with custom elements is the potential for a Flash of Unstyled Content. Since custom elements are declared and registered in Javascript, it can take a few milliseconds for them to be loaded, processed, registered, and finally rendered. While this is happening, your custom element are left unstyled or hidden.

This could be a major drawback for a marketing website where you have just a few seconds to engage with your visitors in order to keep their attention, but in web applications, it's not really a deal-breaker, especially since your browser's cache dramatically dampens the issue after the initial loading.

Here's an example of FOUC with a "tabbed container" web component on a reload without cache (on a local development server):

Here is the same component rendering on reload, with browser cache (still on a local development server):

As you can see, browser cache makes this a non-issue for repeat visits.

Shadow DOM doesn't play well with native forms

The biggest issue I have encountered with web components is the fact that they do not play well at all with native form functionalities. This is due to two things:

Custom elements cannot extend elements other than HTMLElement (without tedious workarounds and major drawbacks);
Form elements inside the Shadow DOM are not considered as such by the component's parent form.

Remember how the Shadow DOM doesn't use global styles? This means that if you want to use a <form> inside a web component, you will have to re-define the styles of every <input>, <select>, <textarea>, <button>, <label>, <fieldset>, and more, within your component's styles.

Of course, you could make each of these elements their own web component, so they each encapsulate their own styles. However, because form elements such as HTMLInputElement cannot be extended by custom elements, your custom input component has to include the <input> in its Shadow DOM. And this is where you run into the next issue: inputs (and other form elements) within the Shadow DOM are not considered part of the form.

For example, if a form's submit button is inside the Shadow DOM, the form cannot be submitted by pressing Enter inside an input anymore, unless you add your own keydown event listener to replicate this feature yourself.

Here is another example that is a little more complex and telling. If you want to make a custom input, you have three solutions:

You can generate a <input type="hidden"> in the regular DOM, beside your custom element, and manually replicate a bunch of built-in features to ensure your input is synchronized correctly at all times, triggers the right events, is validated correctly, is accessible, looks good, and works well.
You can make every form element, including the <form> itself, its own web component, and forego native <form> elements for your entire project.
Handle every form who uses this custom input element with Javascript

If you are already in a Javascript-heavy environment, where every single form is handled via Javascript, and every component implementation already requires a lot of work in order to be usable and accessible, this might not seem like a major issue.

However, if you are more vanilla-oriented, newer to web development, or simply like simple solutions and environments, this is likely to be a MAJOR deal-breaker.

A non-negligible percentage of the web components I would like to build are meant to work with forms or form elements in one way or an other, and I expect it is the same for most other developers.

The Ugly

The worst part is that there isn't much information on the web about what is being done to fix or circumvent this issue of incompatibility with native forms.

Web component libraries like Shoelace simply implement their own custom form element, which must be handled manually in Javascript.

Librairies that aim to help build web components, such as Google's Lit, cannot allow extending built-in elements because Safari doesn't support customization of built-ins.

Where we stand, and whether should you use them

Overall, just a few weeks/months after embarking on my web component journey with a big smile and sparkling eyes, I find myself not pessimistic, but slightly disappointed about the current state of web components and their future outside of Javascript framework projects and ecosystems.

I still believe the idea and general implementation of web components is great. But the drawbacks when it comes to native forms make them much less easy to learn and to implement into.

You should use web components...

if you're already handling all your forms manually in Javascript
if you have (or plan on having) multiple projects or ecosystems with different technology stacks in which you need to share/reuse components
if you don't mind taking a lot of time to reimplement built-in functionalities and accessibility before you can really start working on your own business-related features (or if you can use an existing component library like Shoelace to save on the initial development time and costs)
... or if you don't need your components to interact with forms or form elements

You should not use web components...

if you want to retain the ability to use native forms
if you need to support legacy browsers

A light in the distance

Just after I initially published this article, @westbrook commented to let me know about the ElementInternals spec which is currently implemented in Google Chrome (not in Safari or Firefox yet however). Once available in every browser, this could be a valid solution to the form-related problems I mentioned in the article.

Check out the following articles to learn more about this spec, its implementations, and the available polyfills:

One last thing...

If you are not in a Javascript-heavy environment but would still like to use web components for your forms (e.g.: you're building a Laravel or Symfony web app), you always have to possibility of developing a universal form handler to overcome the problems that are described in this article.

Sure, it's more complicated than just using native forms, and it will require you to do some more development and testing before you can get started, but it's probably the simplest workaround.

If you do have any other workaround or solutions in mind, I'd love to see them here in the comments or on Twitter.