Crafting a better work experience

Passer d’une application à l’autre pour réunir toutes les informations dont vous avez besoin est contre-productif.

C’est souvent le cas quand il faut jongler entre votre CRM et votre client de messagerie pour retrouver les informations d’un client.

Ne serait-il pas idéal d’accéder rapidement à toutes ces informations directement depuis vos e-mails ?

Si vous utilisez Missive pour gérer vos e-mails personnels et vos e-mails d’équipe, et que vous voulez afficher des données issues de votre propre base de données ou d’une feuille Google Sheets, Retool est un bon outil.

Voici un tutoriel pour utiliser l’intégration Retool et ajouter ces données à Missive.

Qu’est-ce que Retool ?

Retool est un outil puissant et flexible qui vous aide à créer rapidement et facilement des applications internes sur mesure. Son interface en glisser-déposer, simple mais puissante, vous permet d’ajouter n’importe quelle source de données à vos applications et de les partager avec votre équipe.

Comment utiliser Retool avec Missive ?

Retool est un excellent moyen de créer une intégration sur mesure qui relie une source de données à une application utilisée par votre équipe. Grâce à cette solution low-code, vous créez facilement les outils internes dont vous avez besoin pour donner un coup de fouet à la productivité de votre équipe.

Dans ce tutoriel, nous allons voir comment utiliser Retool pour afficher les données d’une feuille Google Sheets à côté de vos e-mails dans Missive.

1. Créer nos requêtes dans Retool

Pour voir les données d’une feuille de calcul Google à côté des conversations, nous devons interroger notre document Google Sheets depuis une application Retool intégrée à Missive.

Nous devons d’abord créer trois requêtes dans notre application Retool. Pour cela, connectez-vous à Retool et créez une nouvelle application en cliquant sur Create new > App. Si vous n’avez pas encore de compte, créez un compte Retool.

Ensuite, nous devons créer nos requêtes de données :

1. La première interroge les données de l’application Missive.
2. La deuxième interroge les données d’une feuille Google Sheets.
3. La troisième fusionne ces deux sources de données et affiche les bonnes données dans l’application Retool (la barre latérale de Missive).

Pour ajouter une source de données à votre application Retool, cliquez sur l’icône + et sélectionnez Resource query. Nous allons d’abord créer la requête qui récupère les données de la conversation sélectionnée dans Missive.

Pour ajouter une source de données à votre application Retool, cliquez sur l’icône + dans le panneau inférieur gauche nommé Code et sélectionnez Resource query.

Commençons par créer une requête qui récupère les données de la conversation sélectionnée dans Missive.

Ci-dessous, nous appelons la requête getCurrentConversation, mais vous pouvez la renommer si vous le souhaitez. Le champ Resource doit être réglé sur ParentWindow et le champ Selector sur conversation.

La deuxième requête connecte notre feuille Google Sheets à Retool. Pour la créer, ajoutez une nouvelle requête comme précédemment. Dans Resource, sélectionnez + Create a new resource. Choisissez ensuite Google Sheets et suivez les instructions.

De là, vous pouvez sélectionner la feuille de calcul à connecter.

Vous pouvez faire un test avec une feuille qui a les mêmes colonnes que celle-ci :

Enfin, nous devons créer la requête qui fusionne les données de Missive avec la feuille de calcul. Nous l’appellerons simplement query. Pour celle-ci, sélectionnez Query JSON with SQL comme Resource.

La requête doit être la suivante :

select * from {{ googleSheet.data }} where Email = ANY({{getCurrentConversation.data.email_addresses.map(x => x.address.toLowerCase())}})

En résumé, elle trouve toutes les lignes de la feuille de calcul dont l’adresse e-mail correspond à au moins une des adresses de la conversation sélectionnée dans Missive.

2. Créer une interface pour Missive

Maintenant que nous avons les bonnes données, nous pouvons créer une interface simple pour les afficher. Dans le panneau de droite de l’éditeur Retool, sélectionnez l’onglet Create, puis glissez-déposez le composant Key Value dans votre application.

Sélectionnez ensuite le composant ajouté puis, dans l’onglet Inspect du panneau de droite, collez {{ query.data[0] }} dans le champ Data.

Et voilà ! Nous avons une application simple, mais fonctionnelle.

Avant de l’essayer dans Missive, apportons quelques retouches de style à l’application Retool pour qu’elle s’affiche mieux dans la barre latérale droite de Missive.

Pour cela, ouvrez le menu More en haut à droite, puis sélectionnez l’option Scripts and styles.

Collez ensuite ce code CSS :

._retool-container-table1 {
   width: 100% !important;
}

._retool-container-keyValue1 {
   width: 100% !important;
}

Le nom de classe ._retool-container-keyValue1 dépend du nom de votre composant. Pensez à l’adapter au nom de votre composant.

Ce CSS permet au composant de s’adapter dynamiquement à la largeur de la barre latérale de Missive.

3. Ajouter notre application Retool dans Missive

Place à l’essai dans Missive ! Copiez le lien View de votre application :

Dans Missive, ouvrez Paramètres > Intégrations, ajoutez une intégration Retool et collez le lien copié dans le champ URL publique Retool :

Enfin, ajoutez ?_embed=true à la fin de l’URL collée. L’en-tête Retool disparaît alors de l’intégration, pour un rendu bien plus propre.

Veillez aussi à désactiver l’option Enable mobile layout dans les paramètres de votre application Retool :

Et voici le résultat final !

‍

Utiliser l’API JS de Missive depuis Retool

Vous pouvez aussi tirer parti de l’API JS de Missive depuis votre application Retool. Voici comment faire :

1. Activer la communication avec la fenêtre parente

Par défaut, Retool bloque toute communication entre l’application et sa fenêtre parente (Missive). Vous pouvez l’activer dans vos paramètres Beta :

2. Ajouter la bibliothèque missive-retool.js à votre application Retool

Ajoutez ce script dans la section Scripts and styles de votre application Retool :

https://integrations.missiveapp.com/retool/missive-retool.js

3. Utiliser l’API JS de Missive

Vous pouvez désormais utiliser l’API JS de Missive depuis votre application Retool. Vous pouvez par exemple ajouter un lien qui ajoute de nouveaux commentaires et de nouvelles tâches à la conversation sélectionnée :

Tout logiciel a besoin de limites. Presque chaque partie d’un logiciel a besoin d’une limite stricte. Du moins, chaque partie qui manipule des listes. Dans la plupart des langages et des bases de données, cela veut dire des tableaux et des chaînes de caractères.

Cela paraît évident, mais je suggère à chaque ingénieur qui lit ces lignes d’ouvrir sa base de code et de jeter un œil. Vous avez sûrement des validations de longueur ici et là, mais si vous n’avez jamais consacré une demi-journée à passer en revue toutes vos listes pour fixer une limite à chacune, il vous reste probablement plusieurs failles.

Je ne parle pas des limites évidentes, visibles par les utilisateurs, comme le plafond de 5 utilisateurs du forfait Starter ou de 25 utilisateurs de notre essai gratuit. Je parle des limites que 99 % des utilisateurs n’atteindront jamais. Par exemple, coller plusieurs paragraphes dans l’objet d’un e-mail au lieu du corps. Ou, de la même façon, saisir les « Notes » d’un contact dans le champ « Prénom ». Ou encore ces boucles infinies qui vous tomberont dessus dès que vous lancerez une API publique.

Le seul cas où vous n’avez pas besoin de limite stricte, c’est quand une liste est toujours lue avec une pagination. Après tout, qui dit pagination dit LIMIT déjà en place.

Adoptez les limites strictes

J’adore les limites strictes. J’adore savoir qu’elles sont là. J’adore en ajouter de nouvelles à chaque nouvelle fonctionnalité. Les limites strictes sont la clé pour que je dorme sur mes deux oreilles.

Elles demandent aussi peu d’efforts : pas besoin de documentation publique. Vous prévoyez naturellement des messages d’erreur corrects pour les rares cas extrêmes qui les atteindront, mais personne n’a besoin de les garder en tête pour savoir si elles vont affecter son activité.

Vous devriez même vous imposer de ne pas avoir à les communiquer. Si vous commencez à voir un nombre significatif d’exceptions, c’est sûrement que la limite est trop basse. Le but n’est pas d’agacer ou de brider les utilisateurs, mais d’éviter les plantages. Passer une limite de 500 à 1 000 ne fera pas planter votre app, mais cela peut faire la différence entre un utilisateur qui l’atteint une fois par mois et un utilisateur qui l’atteint tous les jours.

C’est aussi l’occasion de se rappeler que le monde est divers. Restez humble, acceptez et embrassez le fait que certains de vos clients auront des usages que vous n’aviez jamais imaginés. Ne tombez pas dans le piège d’accuser les gens de mal utiliser votre logiciel.

Un jour, une organisation s’est heurtée à une limite et nous a écrit. Elle avait besoin de plus de 25 champs personnalisés sur un contact. Lui avons-nous demandé d’expliquer sa situation et de voir comment adapter son usage ? Bien sûr que non. Nous avions fixé cette limite de 25 arbitrairement au départ, nous pouvions donc tout aussi bien la passer à 50. Problème réglé !

Évitez les débats futiles

Je vous suggère de vous limiter à une courte liste de nombres pour toutes vos limites :

1 • 5 • 10 • 50 • 100 • 500 • 1000 • 5000

Ce sont les plus faciles à retenir pour tout le monde. L’écart entre chacun est aussi assez grand pour que la décision soit facile. Inutile de perdre du temps à se demander si 100, 200 ou 300 convient. Un doute sur 100 ? Prenez 500, c’est largement suffisant !

Le « 1 » sert pour les Ko ou les Mo. Quelle doit être la taille maximale du corps HTML d’un e-mail ? Vous conviendrez sûrement que 1 Mo suffit, sachant que c’est à peu près la taille d’un tome de Harry Potter.

Quelle taille de charge utile JSON notre serveur web doit-il refuser d’analyser ? 5 Mo ou 10 Mo, les deux nous vont très bien. La seconde est la limite qu’utilise Amazon API Gateway.

Quand vous répondez à un fil d’e-mails et que nous le citons sous votre réponse, où nous arrêtons-nous ? 10 Ko de texte cité, et le tour est joué.

Combien de libellés allez-vous appliquer à cette seule conversation ? J’espère que 100 vous suffiront.

Au-delà de combien de sessions simultanées commence-t-on à flairer plusieurs utilisateurs qui rechignent à payer un prix juste par siège ? Je n’ai jamais vu personne en avoir besoin de plus de 10.

Et la liste est encore longue.

J’espère que cet article vous a plu et que vous passerez votre prochaine matinée à ajouter de jolies limites partout dans votre code. Allez-y, c’est amusant ! ✌️

Note: Deferred end of support date"In response to the unprecedented situation we are in and knowing that priorities have changed for many of our customers we have decided to postpone retiring Basic Authentication in Exchange Online (MC204828) for those tenants still actively using it until the second half of 2021. We will provide a more precise date when we have a better understanding of the impact of the situation." - Microsoft

No worries, Missive still supports Office 365, Outlook and IMAP. 😅

On October 13th, 2020, Microsoft will stop supporting username & password authentication for the IMAP and POP3 protocols.

In layman terms, any email application out there that connects to Microsoft email servers using IMAP or POP3 (Basic Authentication) will stop working.

Basic Authentication is a term used to explain how an application passes the username and password of a user. It can, in many scenarios, be an insecure method to handle credentials. Especially when a third-party is involved and has to store the user credentials to authenticate itself in the name of the user (cloud email application).

As an alternative Microsoft developed Modern Authentication (a Microsoft term), which is based on an authentication method called OAuth 2.0. This method doesn’t share passwords but instead uses authorization tokens (think of them as temporary passwords) to prove the identity between users and service providers.

The apps that connect to your Microsoft account will never receive the real password. You also get the possibility to revoke access to those apps from your Microsoft account. That in itself is a good thing!

The temporary death of IMAP

The problem is Microsoft deprecating Basic Authentication is the kiss of death for a lot of email clients out there supporting only the IMAP/POP3 protocols. On October 13th, 2020, the only way for email clients to sync emails with Microsoft accounts will be to implement the proprietary Outlook REST API or the Exchange protocol.

Technically, the IMAP protocol supports OAuth 2.0 authentication via an extension; it’s how Gmail works. However, it is unlikely that Microsoft will support this on time. Incoming support has been recently announced, but no ETA was provided:

To make it easier to migrate your existing applications to use OAuth 2.0, we are making significant investments to our service that include OAuth 2.0 support for POP, IMAP, and background application support for Remote PowerShell MFA module. We will be sharing more information on these new features over the coming months.

For our users, this is not a problem; our syncing engine now supports Modern Authentication via Outlook REST API. As a cloud-based email client, not having to store and encrypt user passwords is a massive improvement. It’s just sad and unproductive Microsoft didn’t, out of the gate, offer IMAP connections with the OAuth 2.0 extension.