Bonnes pratiques

Améliorez l'expérience globale de vos utilisateurs en suivant ces guides de conception de modules complémentaires.

Bonnes pratiques générales

Nous vous encourageons à suivre les bonnes pratiques suivantes pour tous les modules complémentaires que vous développez.

Déterminez la propriété du module complémentaire avant de commencer

Les modules complémentaires sont définis par des projets Apps Script, qui doivent appartenir à un compte spécifique ou être placés dans un Drive partagé. Avant de coder un module complémentaire, déterminez quel compte doit être propriétaire du projet et quel compte agit en tant qu'éditeur. Déterminez également les comptes qui agiront en tant que collaborateurs, et assurez-vous que ces comptes ont accès au projet de script et au projet Cloud Platform associé.

Étendre les fonctionnalités de Google Workspace, sans les dupliquer

Ils sont destinés à fournir de nouvelles fonctionnalités aux applications Google Workspace qu'ils étendent ou à automatiser des tâches complexes. Ceux qui se contentent de répliquer les fonctionnalités déjà présentes dans l'application ou ceux qui n'apportent pas d'améliorations significatives à un workflow ne seront probablement pas soumis à l'examen complémentaire pour la publication.

Limiter les champs d'application

Lorsque vous définissez vos champs d'application explicitement, choisissez toujours l'ensemble de champs d'application le moins permissif possible. Par exemple, n'accordez pas à votre demande de module complémentaire un accès complet à l'agenda de l'utilisateur avec le champ d'application https://www.googleapis.com/auth/calendar s'il n'a besoin que d'un accès en lecture. Pour l'accès en lecture seule, utilisez le champ d'application https://www.googleapis.com/auth/calendar.readonly.

Éviter de trop vous appuyer sur les bibliothèques

Si vous utilisez des bibliothèques Apps Script, votre module complémentaire risque de s'exécuter plus lentement que si tout le code Apps Script était contenu dans un seul projet de script. Bien que les bibliothèques Apps Script fonctionnent dans des modules complémentaires, vous risquez de réduire les performances si vous les utilisez. Évitez d'inclure des bibliothèques inutiles dans votre projet et réfléchissez à des moyens de réduire la dépendance de votre module complémentaire à celles-ci.

La latence décrite ci-dessus ne s'applique qu'aux projets Apps Script utilisés en tant que bibliothèques côté serveur. Vous pouvez utiliser librement les bibliothèques JavaScript côté client telles que jQuery, sans vous soucier de cette latence.

Bonnes pratiques concernant les modules complémentaires Google Workspace

Les bonnes pratiques suivantes s'appliquent uniquement aux modules complémentaires Google Workspace et à l'utilisation du service de cartes.

Utiliser seulement quelques fiches

Si le module complémentaire utilise trop de cartes, la configuration de navigation devient complexe et difficile à gérer.

Évitez d'avoir à créer plus de cartes que nécessaire.

Utiliser les fonctions de création de widgets

Lorsque vous écrivez du code qui crée des Card ou d'autres objets d'interface utilisateur complexes, envisagez de placer ce code dans sa propre fonction. Cette fonction de création doit simplement compiler l'objet et le renvoyer. Cela vous permet de regénérer rapidement cet objet chaque fois que l'interface utilisateur doit être actualisée. N'oubliez pas d'appeler build() après avoir utilisé les classes de compilateur dans le service de carte.

Optez pour des fiches simples

Si une carte donnée comporte trop de widgets, elle peut remplir trop d'écran et devenir moins utile. Bien que les grandes sections de fiches soient affichées sous la forme d'éléments d'interface utilisateur réductibles, cela masque des informations à l'utilisateur. Essayez de simplifier votre module complémentaire et de fournir exactement ce dont l'utilisateur a besoin, et rien de plus.

Utiliser des cartes d'erreur

Créez des fiches pour les conditions d'erreur. Si votre module complémentaire génère une erreur, il doit afficher une fiche contenant des informations sur l'erreur, ainsi que des instructions pour la corriger, si possible. Par exemple, si votre module complémentaire n'a pas pu se connecter à un service autre que Google en raison de l'échec de l'autorisation, affichez une fiche indiquant cela et demandez à l'utilisateur de vérifier les informations de compte utilisées.

Écrire des tests et tester des messages

Nous vous recommandons de tester minutieusement tous les modules complémentaires que vous créez. Créez des fonctions de test qui créent des fiches et des widgets à l'aide de données de test, puis vérifiez que les objets sont créés comme prévu.

Lorsque vous utilisez des fonctions de rappel d'action, vous devez généralement construire un objet de réponse. Vous pouvez utiliser des instructions comme les suivantes pour vérifier que les réponses sont créées correctement:

    Logger.log(response.printJson());

Exécutez les fonctions de test que vous avez créées directement depuis l'éditeur Apps Script à l'aide du menu Exécuter. Lorsqu'un module complémentaire opérationnel est opérationnel, veillez à installer la version non publiée pour pouvoir la tester.

Utilisez des données de test adaptées à chaque application hôte étendue par le module complémentaire. Par exemple, si le module complémentaire étend Gmail, vous aurez probablement besoin de quelques e-mails de test et de leurs ID de message pour vous assurer que le module complémentaire fonctionne comme prévu lorsque le contenu des messages est différent. Pour obtenir l'ID d'un message donné, répertoriez les messages à l'aide de la méthode Users.messages.list de l'API Gmail, ou utilisez le service Gmail d'Apps Script.

Bonnes pratiques pour les conférences Agenda

Si votre module complémentaire intègre des options de visioconférences d'agenda tierces dans Google Agenda, suivez ces bonnes pratiques supplémentaires:

Conserver la lumière de votre onCreateFunction

Chaque onCreateFunction que vous définissez dans votre fichier manifeste est appelée de manière synchrone lorsqu'un utilisateur tente de créer une solution de conférence de ce type. Assurez-vous que ces fonctions n'effectuent que le minimum de travail nécessaire à la création de la conférence. Si vous en utilisez trop avec ces fonctions, vous risquez de ralentir l'expérience utilisateur de votre module complémentaire.

Utiliser les champs ConferenceData appropriés pour les données de conférence

Lorsque vous créez des objets ConferenceData, vous pouvez y ajouter des informations sur la conférence (codes d'accès, numéros de téléphone, codes, URI, etc.). Veillez à utiliser le champ EntryPoint correspondant pour ces informations. Ne placez pas ces informations dans le champ ConferenceData "notes".

Ne pas ajouter les informations concernant la conférence à l'événement Google Agenda

Votre module complémentaire n'a pas besoin d'ajouter d'informations sur les conférences tierces créées dans la description d'un événement Google Agenda. Google Agenda le fait automatiquement si nécessaire.