DEV Community: Fabián Larrañaga

How to test web extensions?

Fabián Larrañaga — Wed, 15 Apr 2020 20:23:41 +0000

Originally published in Streaver's blog.

You are running your web extension successfully, thousands of users are using it but development is getting harder. Each time you make changes to it you feel less comfortable and confident about not breaking any feature. In the rush to release your extension you opted to not test it, or you were not sure how to do it. Whether this is your case or you are just curious, this post pretends to help you overcome this situation by showing you how to test web extensions.

We will be testing a web extension we previously built. You can find the example web extension code and if you are curious about how to implement one, you can also check this tutorial for showing how to create a web extension in Vue.

How should I test my web extension?

When testing an application, and thus a web extension, you always want to test it at different levels to ensure with a certain confidence that the application works as expected. Testing at different levels requires you to balance your budget, time and level of confidence you need to reach and dedicate for testing. There are basically 3 levels of testing: Unit Testing, Integration Testing and System Testing. This post will cover Unit and Integration Testing of web extensions with Jest and Puppeteer. I'm not covering System testing because with current tools it's not possible to test the full experience of web extensions, however, we will try to make it as similar as if we were testing the web extension end to end.

Unit Testing

Individual units are tested.
Tests just a single module, component or class to validate it's correctness.

Integration Testing

Test the sub systems and modules and their interfaces.
They are used to test how various parts of your application interact.
They are generally used to test important workflows within our application.

System Testing

Test the application as a whole.
Allow you to test user interactions with your application, running tests in either a real or a headless browser.
Are the most expensive ones, in terms of requirements, and time to be built and run.

Now that you know a bit more about the different levels for testing an application, let's focus on testing our web extension.

Setup Testing Library

Let's grab our already working web extension example. If you want to follow along you can checkout to the tag no-tests-yet.

Now, we need to install Jest, the testing framework we will use.

npm install --save-dev jest

After installing it, we will need to specify how we want to run our tests, so you will need to add to your package.json the following:

// package.json
// ...
"scripts": {
  "test": "jest"
},
// ...
"jest": {
  "verbose": true,
  "moduleFileExtensions": [
    "js",
    "json",
    "jsx",
    "ts",
    "tsx",
    "node",
    "vue"
  ],
  "transform": {
    ".+\\.(css|styl|less|sass|scss|png|jpg|ttf|woff|woff2)$": "jest-transform-stub",
    "^.+\\.js$": "babel-jest",
    "^.+\\.vue$": "vue-jest"
  }
},
// ...

Our extension is built in Vue

Since our extension is in vue, we also need to install the following libraries:
npm install --save-dev jest-transform-stub
npm install --save-dev vue-jest
npm install --save-dev @vue/test-utils
npm install --save-dev babel-core@bridge
You can understand better why they are needed if you try running your tests without them installed.

Before writing the first test, I'd like to remind you that in our web extension we have been using a library to make it work across different browsers webextension-polyfill. So, if you try to run the tests the code will fail, for that reason, we'll need to mock it. We are going to use jest-webextension-mock. To install it please do:

npm install --save-dev jest-webextension-mock

Lastly, you will need to set it up similarly to what we did with the overall jest configuration, in this case we need to add the setupFiles key under jest like:

// package.json
"jest": {
  // ...
  "transform": {
    // ...
  },
  "setupFiles": [
    "jest-webextension-mock"
  ]
}
//

Now that we have our testing libraries in place it's time to test the extension. Let's go!

Unit Testing the Popup

Let's remind how the popup looks like:

So...What should I test?

You should focus on validating that the component has all the elements it should have.
For example title, subtitles, buttons, inputs, colors, and so on. Also if you have conditionals on it under some property that is being passed, you should validate it renders as expected given the different alternatives you have for it.

This might give you the clue that the test file will be conformed by a few things:

Import of the component you want to test
Render it, passing the properties it receives
Look for the elements it should be displaying

Lets create a __tests__ folder under the component folder, there we will place the tests that correspond to the popup component.

Now that we have the folder, we need to add a test file for the component. Let's call it App.test.js.
Note the .test extension, this is really important to let jest know that this is a test file and use
it once we are running our test suite.

We have the file, let's now test it out.

import { shallowMount } from "@vue/test-utils";
import App from "./../App.vue"; // import the popup component

describe('Popup', () => { //describe block specifying which object we are testing
  // We are just testing the initial state, you could add tests for the different conditionals
  // you consider important for your component
  describe('initial state', () => {
    let wrapper;

    beforeAll(() => {
      wrapper = shallowMount(App);
    });

    it('shows welcome message', () => {
      const header = wrapper.find('h1'); // looks for the first h1 tag element on the component

      expect(header.exists()).toBe(true); // validate the element exists
      expect(header.text()).toBe("Hi there! 👋 Hope you're doing great!"); // validate the text's content
    });

    // test the button with text "Do the magic!" is there
    it("displays 'Do the magic!' button", () => {
      const mainButton = wrapper.find('button');

      expect(mainButton.exists()).toBe(true);
      expect(mainButton.text()).toBe('Do the magic!');
    });

    // test the first set of radio buttons is there and all are unchecked
    it('displays all radio buttons for changing body color unchecked', () => {
      const radiosContainer = wrapper.find('.body-color-radios');
      let radios = radiosContainer.findAll("input");

      expect(radios).toHaveLength(3);

      radios = radios.filter(radio => radio.checked);
      expect(radios).toHaveLength(0);
    });

    // test the second set of radio buttons is there and all are unchecked
    it('displays all radio buttons for changing popup body color unchecked', () => {
      const radiosContainer = wrapper.find('.popup-body-color-radios');
      let radios = radiosContainer.findAll("input");

      expect(radios).toHaveLength(3);

      radios = radios.filter(radio => radio.checked);
      expect(radios).toHaveLength(0);
    });
  });
});

Great! We had Unit Tested our popup component. To run them, simply execute npm test on the console, make sure you're in the root path and you will see how your tests start to run.

End2End-ish/Integration Testing with Puppeteer

The following test we are going to dive into is not a fully end to end test, however,
it will introduce some techniques that are really useful and the base for testing our whole system in the future.

Here we will be doing the following things:

Starting a real chrome browser.
Simulating user interaction with our component.
Validating the result of the user interaction is what we want it to be in our app.

Let's create a new folder __tests__/integration folder and inside of it, place a new file App.test.js.

Now let's install Puppeteer.

npm install jest-puppeteer puppeteer --save-dev

Start by creating the browser instance where we will be testing our extension. You simply need to do:

const puppeteer = require('puppeteer'); // import Puppeteer
const path = require('path');

// Path to the actual extension we want to be testing
const pathToExtension = require('path').join(
  path.join(__dirname, '..', '..', '..', '..', 'dist')
);

// Tell puppeteer we want to load the web extension
const puppeteerArgs = [
  `--disable-extensions-except=${pathToExtension}`,
  `--load-extension=${pathToExtension}`,
  '--show-component-extension-options',
];

describe('Popup page', () => {
  let page, browser;

  beforeAll(async () => {
    browser = await puppeteer.launch({
      headless: false,
      slowMo: 250,
      devtools: true,
      args: puppeteerArgs
    });

    // Creates a new tab
    page = await browser.newPage();

    // navigates to some specific page
    await page.goto('https://google.com');
  });

  afterAll(async () => {
    // Tear down the browser
    await browser.close();
  })

  it('tests something, will come back to this shortly', async () => {
    // ** will have the code in it
  });
});

Till here, we are specifying in which conditions our chrome browser should open so we can start testing our extension.

Please note that we need to explicitly ask Puppeteer to allow our web extension, otherwise it will not be there for us to test it.

If you want to validate this is working, you can run in your console npm test, and you will see a browser instance opening, navigating to Google and closing after a couple of secs.

It's time we test our popup in the real browser. Let's make sure our popup changes the body color after clicking the different checkboxes.
To achieve that, we need to first open the popup, and then do some clicks on the radio buttons, after that we should check the background color changed.

How can I achieve this?

The first thing we need to do is access our popup directly. Unfortunately, there isn't a way to click on the action controls from a chrome instance with Puppeteer, but there is a workaround for this. The popup is no other thing than an Html and it can be accessed directly from the URL, so we simply need to know the URL for it. As you might be guessing, it's popup.html, so we just simply need to know how to open an extension from its URL. To do that, there are a couple of ways but the easiest one is to create a unique ID for the extension so we can use it forever. Once we have it we can simply open: chrome-extension://${extensionId}/popup/popup.html on the browser.

Getting the extension Id
I'm not going to explain it by myself, instead, I recommend taking a look to this thread at StackOverflow.

Remember to add the key and id generated to the manifest.json to make use of them.

  // src/popup/__tests__/integration/App.test.js
  // Small refactor to not have to open the extension on each test
  // ******
  beforeAll(async () => {
    // Open popup url, and wait for it
    const extensionId = '<YOUR-EXTENSION-ID>';
    const chromeExtPath = `chrome-extension://${extensionId}/popup/popup.html`;

    await page.goto(chromeExtPath, { waitUntil: 'domcontentloaded' });

    await page.reload();
  });

  afterAll(async () => {
    // Close the browser after tests finish
    await browser.close();
  })
  // ******

  it('changes the background color on click', async () => {
    // ** new code replacement

    // Search for the radio buttons by their identifier, click on them and
    // return the resulting body color after clicking them.
    const bodyColors = await page.$$eval(
      '.popup-body-color-radios input[type="radio"]',
      radios =>
        radios.map(radio => {
          radio.click();
          return document.querySelector('body').style.backgroundColor;
        })
    );

    // Check the colors the body had match the colors we have predefined
    // for each of the radio buttons
    expect(bodyColors).toEqual(
      [ 'rgb(191, 231, 197)', 'rgb(201, 218, 248)', 'rgb(244, 238, 188)'],
    );
  });

More sample tests
In the web extension example repository you can find a few other examples to test for example the default background color or the amount of radio buttons by using this Puppeteer approach.

Please note that the tests, unlike what we did before on the unit tests, they are async. This is because Puppeteer operates asynchronously and we don't have the result of the invocated functions immediately after they have been called.

The other integration test we are missing at this point is how our popup is communicating with the content script. Unfortunately, we don't have a way to test them automatically given the implementation that we have on our extension. We are simply doing a sendMessage call to our content script which is listening to us and since the connection can't be established between them due to the context of our tests, we can't succeed on testing that a message is sent after clicking the button. In other contexts, this is easier and achievable, you will probably get inspiration from what we have done already. You can also find ways for testing the background script.

Our automated integration tests run on the compiled app!
Be aware of this, each time you change your web extension and run the tests using Puppeteer, you MUST build the extension again, otherwise, you will be running the tests with the previous version of the app. If you are under development still, you can simply run:
npm run build:dev

This is it. I tried to give you real working examples of how you could test your web extensions. I focused it on a particular example but I hope it helps you get ideas and kick off testing with Jest and Puppeteer on any web extension you are building.

Stay safe and build great software while in quarantine.

Hope you enjoyed and learned something new. ❤️ :: Follow me :: Follow us

Building a web extension with Vue at speed of light

Fabián Larrañaga — Tue, 18 Jun 2019 11:39:24 +0000

Originally published in Streaver's blog.

Getting started with the creation of a web extension using VueJs.

What is a web extension?

Chrome's definition

Extensions are small software programs that customize the browsing experience. They enable users to tailor Chrome functionality and behavior to individual needs or preferences. They are built on web technologies such as HTML, JavaScript, and CSS.

At Chrome's official document you can see more info on what they are and what you can do with them.

Generating our Web Extension

We are going to use the great tool vue-web-extension by @HugoAlliaume. We only need to have the Vue CLI installed. If you have always used Vue through the CDN distribution, then you need to install it by running:

$ npm install -g @vue/cli
# OR
$ yarn global add @vue/cli

Please check Vue CLI installation guide for more info.

Once you have successfully installed Vue CLI, please execute:

$ vue init kocal/vue-web-extension my-extension

The previous command will drive you through the creation of our web extension. In the process, you will be asked a few questions such as project name, libraries we want to use, license, etc. They are there to make your life easier and reduce the boilerplate in the initial version of your web extension. So don't worry about it!

Keep it simply

If you are not 100% sure about adding a dependency or not, I recommend keeping it simple. You can always opt to add it manually later.

For simplicity, and in the context of this tutorial I set the following values:

? Project name my-extension
? Project description A Vue.js web extension
? Author Streaver
? License MIT
? Use Mozilla's web-extension polyfill? (https://github.com/mozilla/webextension-polyfill) Yes
? Provide an options page? (https://developer.chrome.com/extensions/options) No
? Install vue-router? No
? Install vuex? No
? Install axios? No
? Install ESLint? No
? Install Prettier? No
? Automatically install dependencies? npm

Now that we have the web extension skeleton, it's time to build the extension. Simply run:

$ cd my-extension
$ npm run build:dev

At this point, you should have compiled the extension successfully (in the terminal should be many indicators of that, such as no errors displayed or Built at: MM/DD/YYYY message). If that's the case, you should be able to see a new folder dist in the root path. It contains the compiled version of my-extension. Yay! 🎊

Let's run our extension locally

Google Chrome

First of all, we need to enable the developer mode. In order to do that, open Chrome browser and type chrome://extensions in the search bar. Right after that, you will be able to see several cards for each extension you have installed before. What you need to do now is just to turn the switch Developer mode on. Look at the top-right corner as shown in the following image to find it.

Now, we need to add our extension my-extension to Chrome. Remember we have our distribution under the recently created dist folder, so what you need to do is look for the button Load unpacked at the top-left and select the dist folder found in the root's path of your extension. After that, you should be able to see it listed within the rest of your extensions.

Hot Reloading

Once you have loaded the extension pack, vue-web-extension allows you to keep watching for new changes and hot reload the extension. To make use of this, you simply need to run npm run watch:dev.

Voilá 🎩 ... Our extension is there 🎉

Go ahead, click on the extension's icon next to the search bar and see what happens...

Understanding the extension structure

Let's start by taking a look at our extension's tree:

.
├── dist
│   └── ...
├── src
│   ├── icons
│   │   └── icon_48.png
│   │   └── ...
│   └── options
│   │   └── ...
│   └── popup
│   │   └── App.vue
│   │   └── popup.html
│   │   └── popup.js
│   └── background.js
│   └── manifest.json
├── package.json
├── webpack.config.js
└── yarn.lock

What do we have?

manifest.json

The manifest.json file contains important information about your extension such as its name, permissions, icons, etc.

content script

A content script is no more than a "Js file that runs in the context of web pages." Basically, the content script will give you the possibility of interacting with web pages that you visit while using the browser. Yes, it has access to all pages you have open in the browser 😱. Not bad 😏

To inject the content script, we need to tell the manifest.json which is the file and when to add it.

// src/manifest.json

"content_scripts": [
  {
    "matches": [
      "<all_urls>" // can use different matching patterns here
    ],
    "js": ["content.js"]
  }
]

With the option matches you can explicitly tell the browser in which pages that you visit the content.js should be injected. For more matching patterns visit: match_patterns.

Customizing the extension

Suppose we want to display something in the current page once the user interacts with the popup. We need to communicate the popup with the actual web page.

In our content script we'd like to listen for events from the pop-up so let's add:

// src/content.js

// This constant is safe, it's just a string in base 64 that we will use below.
const messageToShow =
  "IyMjIyMjICAjIyMjIyMjIyAjIyMjIyMjIyAgIyMjIyMjIyMgICAgIyMjICAgICMjICAgICAjIyAjIyMjIyMjIyAjIyMjIyMjIyAgICAgIAojIyAgICAjIyAgICAjIyAgICAjIyAgICAgIyMgIyMgICAgICAgICAjIyAjIyAgICMjICAgICAjIyAjIyAgICAgICAjIyAgICAgIyMgICAgIAojIyAgICAgICAgICAjIyAgICAjIyAgICAgIyMgIyMgICAgICAgICMjICAgIyMgICMjICAgICAjIyAjIyAgICAgICAjIyAgICAgIyMgICAgIAogIyMjIyMjICAgICAjIyAgICAjIyMjIyMjIyAgIyMjIyMjICAgIyMgICAgICMjICMjICAgICAjIyAjIyMjIyMgICAjIyMjIyMjIyAgICAgIAogICAgICAjIyAgICAjIyAgICAjIyAgICMjICAgIyMgICAgICAgIyMjIyMjIyMjICAjIyAgICMjICAjIyAgICAgICAjIyAgICMjICAgICAgIAojIyAgICAjIyAgICAjIyAgICAjIyAgICAjIyAgIyMgICAgICAgIyMgICAgICMjICAgIyMgIyMgICAjIyAgICAgICAjIyAgICAjIyAgIyMjIAogIyMjIyMjICAgICAjIyAgICAjIyAgICAgIyMgIyMjIyMjIyMgIyMgICAgICMjICAgICMjIyAgICAjIyMjIyMjIyAjIyAgICAgIyMgIyMj";

chrome.runtime.onMessage.addListener(function(request, sender, sendResponse) {
  // Once we receive a message from the popup
  if (request.msg) {
    // If message has the `action` key `print_in_console`
    if (request.msg.action === "print_in_console") {
      // print awesome text on console
      console.log(`%c ${atob(messageToShow)}`, "color:#38B549;");
    } else if (request.msg.action === "change_body_color") {
      // message contains different `action` key. This time it's a `change_body_color`.
      document.body.style.background = request.msg.value;
    }
  }
});

icons & browser actions

As you may have seen, by default, my-extension has a puzzle piece (thanks to the amazing library we used). If you want to change it you must modify the manifest.json. There you will see two settings for icon_48.png and icon_128.png respectively, simply replace those images by your custom images. That icon doesn't come alone, they are also what we call browser actions. Through it, you can display a tooltip, a badge or a popup. 🤔 For example, in our default setting we are defining the icons, but also the title (try it yourself by posing the mouse over the extension's icon for a few secs) as well as the popup page (click the icon to open it). Our manifest looks something like this:

// src/manifest.json

"icons": {
  "48": "icons/icon_48.png",
  "128": "icons/icon_128.png"
},
"browser_action": {
  "default_icon": "icons/icon_48.png", // optional
  "default_title": "my-extension",
  "default_popup": "popup/popup.html"
},

Still confused? 🙄 I invite you to take a look at the official Chrome's browser action documentation.

background script

The background script, compared to the content script, it has full access to the browser API but can't access the current page as the content script can. So it will happen that you depend on both scripts if you want to do really useful things with your web extension. Also you will need to communicate them in order to pass the information around. We will see that in a minute. A practical example of a background script would be listening to clicks, for example when there is a new tab opened.

The same way you did with the content script, you'll need to explicitly tell the browser who is your background file by doing:

// src/manifest.json

"background": {
  "scripts": [
    "background.js"
  ]
},

We are not going to do anything with background.js in this example, but if you are curious about it, please check a web extension we have built in the past: whosnext vue web extension.

messaging

As we said before, content script and background script have some limitations when it comes to communicating or getting data. They run in different contexts and they have access to different information. This forces us to communicate and pass information through messages. The same happens between the popup and the content script.

Let's check how a web extension communicates the different parts of it:

One more time, I suggest you consider the official messaging documentation if you want to understand it in more details.

In the context of this web extension, we need to send messages to our content script each time the user interacts with the popup. Why? Because we want to make changes to the current page. So we will catch those messages coming from the popup and do some crazy stuff on our page.

Let's add the following code to the popup/App.vue file:

<!-- src/popup/App.vue -->

<template>
  <div class="extension">
    <h1>Hi there! 👋 Hope you're doing great!</h1>

    <button v-on:click="writeInConsole">Do the magic!</button>

    <div>
      <h2>Want more magic?</h2>
      <span>Try them:</span>

      <div>
        <input type="radio" v-model="bodyColor" value="#f4eebc">
        <input type="radio" v-model="bodyColor" value="#bfe7c5">
        <input type="radio" v-model="bodyColor" value="#c9daf8">
      </div>

      <h4>even more?</h4>

      <div>
        <input type="radio" v-model="popupBodyColor" value="#bfe7c5">
        <input type="radio" v-model="popupBodyColor" value="#c9daf8">
        <input type="radio" v-model="popupBodyColor" value="#f4eebc">
      </div>
    </div>
  </div>
</template>

<!-- src/popup/App.vue -->

<script>
const browser = require("webextension-polyfill");

export default {
  data() {
    return {
      currentColor: "#FFF",
      currentPopupColor: "#FFF"
    };
  },

  computed: {
    bodyColor: {
      get() {
        return this.$data.currentColor;
      },
      set(val) {
        this.$data.currentColor = val;

        // Once `bodyColor` changes it sends a
        // message that content script will be listening
        browser.tabs.query({ active: true, currentWindow: true }).then(tabs => {
          browser.tabs.sendMessage(tabs[0].id, {
            msg: { action: "change_body_color", value: val }
          });
        });
      }
    },

    popupBodyColor: {
      get() {
        return this.$data.currentPopupColor;
      },
      set(val) {
        // Once `popupBodyColor` changes, we change the popup
        // body color to the new value, no need to send message,
        // it's the same context
        this.$data.currentPopupColor = val;
        document.body.style.background = val;
      }
    }
  },

  methods: {
    // method called once popup button is clicked, at that moment sends a
    // message that content script will be listening and will do some action there
    writeInConsole() {
      browser.tabs.query({ active: true, currentWindow: true }).then(tabs => {
        browser.tabs
          .sendMessage(tabs[0].id, { msg: { action: "print_in_console" } })
          .then(() => {
            alert(
              "Open the browser's console to see the magic. Need to have at least one tab in some page."
            );
          });
      });
    }
  }
};
</script>

At this point your web extension should look like this:

If you want to check how the whole project looks like, please visit web extension example on Github. You can also check a more complete web extension we made in vue at whosnext repo.

WebExtension polyfill

In this post I used only Chrome's documentation as reference because it's really comfortable reading through it and for making the tutorial simpler, however, be aware that the extension is built using webextension-polyfill which means your extension is supported in Chrome, Firefox & Opera.

Hope you had enjoyed it. ❤️ :: Follow me :: Follow us

Optimizing remote daily scrum meetings

Fabián Larrañaga — Thu, 11 Apr 2019 20:03:38 +0000

Originally published in Streaver blog.

Why care about optimizing meetings?

Meetings are a really important part of our job, thus having good meetings is something we must care about. How many times have you felt a meeting is not being as effective as you can think of? It's likely that the average employee spends approximately 30% of his or her working time in meetings. Because so much time is spent in meetings, it is vital that we ensure they are well-organized, planned, and beneficial for all the participants, or at least be conscious about that.

A well-organized meeting also has a huge impact on the success of a team. Meetings in general help in strengthening interpersonal bonds, improve communication and teamwork, increase team morale and satisfaction, and boost productivity. Now that I mention this, can you think of any reasons not to invest time on making your meetings better?

Our MVP in terms of meetings is the daily standup (aka daily scrum meeting). For those who don't know what it really is, let me explain it briefly.
Daily standups are everyday meetings supposed to take between 5 and 15 minutes with all the team. It's supposed to have all participants standing up since it helps to remind people to keep the meeting short and to-the-point (this explains its name). The dynamic is pretty simple, all the participants will share their updates one-by-one to the rest of the team until all had spoken. The peculiarity here is that everyone's update must answer the following three questions:

What did you do yesterday that helped the Development Team meet the Sprint Goal?
What will you do today to help the Development Team meet the Sprint Goal?
Do you see any impediment that prevents you or the Development Team from meeting the Sprint Goal?

This is basically all you need at this point to understand what I'm talking about, however, if you want to learn more about it I suggest considering the Scrum guide, look for Daily Scrum on page 12 to get more info about this in particular.

There are many factors that can affect daily standups to be effective and relevant to the whole team. Meetings have challenges by themselves but they get empowered when the meeting is scoped to a maximum of 15 minutes total. Some common challenges that you may be thinking right now might be the arrival on time of all participants, the lack of concentration, the engagement, the self-organization, and many more... but now think about the remote daily standups. Can you think of any other challenge in this context?

Unfortunately, there many new hazards that appear when it comes to remote daily calls. Why? Basically, you have all the same kind of issues I shared before plus others like internet connection, issues with the browser, lack of attention- if the camera is off you'll never notice it, lack of tracking, people always speaking at last, etc. However, not all of this is necessarily bad and in fact, you can tackle many of them and take advantage of remote meetings.

Our approach to making meetings better

A few weeks ago, right before the VueConfUs2019 - which was awesome and I strongly recommend - we identified some aspects of our remote daily standups that we could have been doing better so far. We kind of identified 3 main areas:

Time wasting
Participants' feeling
Traceability

So what was left at that point was to find a way to solve (at least minimize) these concerns. We decided to build a web extension that we called whosNext.

The extension is pretty simple, everything starts when it detects a new Google Hangouts Meet call is started. All the people within the same call is being displayed in real time on the web extension and is visible by everyone. When someone at the call decides it's time to start sharing their updates, the extensions sorts in which order each one must speak. This simple action covers the 3 main areas.

By assigning a random order to each speaker:

we guarantee the time for asking "who wants to go next?" or for "deciding which should be the next person" gets reduced to zero so there is no waste of time.
we smooth the feeling of "being always the last person to talk" or the extroverted personality of those that always want to go first. We think that everyone deserves to be the first sometime and this works perfectly well together.

But the extension has more power. We also decided to add the capability to reflect when you are done and automatically invite the next participant to start talking. This is great because allows you:

to keep track of how much time you have consumed and be aware of the rest of the team, which is as important as you are.

How it looks:

I hope this post helps you in taking a moment to think and analyze your position towards remote meetings and meetings in general. It's great to take some action and suggest changes if you feel you can do something better, no matter what it is. It's important to bear in mind that a suggestion doesn't mean you will change all the meetings from one day to the other, in fact, that's something I don't recommend at all. However, you can do baby steps by trying minor changes and evaluating how they perform. Once you have a verdict, you can decide to incorporate it or just discard and try a new one.

I'd love to hear your thoughts about what you have done to make your meetings better.