Améliorez l'expérience globale de vos utilisateurs en suivant ces guides de conception des modules complémentaires.
Bonnes pratiques générales
Nous vous encourageons à suivre les bonnes pratiques ci-dessous pour tous les modules complémentaires que vous développez.
Déterminer 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 le compte qui doit être propriétaire du projet et celui qui doit agir en tant qu'éditeur. Déterminez également quels comptes doivent agir en tant que collaborateurs et assurez-vous qu'ils ont accès au projet de script et à son projet Google Cloud associé.
Étendre Google Workspace, et non le répliquer
Les modules complémentaires sont conçus pour fournir de nouvelles fonctionnalités aux applications Google Workspace qu'ils étendent ou pour automatiser des tâches complexes. Les modules complémentaires qui se contentent de reproduire des fonctionnalités déjà présentes dans l'application ou qui n'apportent pas d'améliorations significatives à un workflow ne sont pas susceptibles de passer l'examen des modules complémentaires pour publication.
Limitez les champs d'application
Lorsque vous définissez vos champs d'application de manière explicite, choisissez toujours l'ensemble de champs d'application le moins permissif possible. Par exemple, ne demandez pas à votre 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 un accès en lecture seule, utilisez le champ d'application https://www.googleapis.com/auth/calendar.readonly.
Évitez de trop vous appuyer sur les bibliothèques
L'utilisation de bibliothèques Apps Script peut ralentir l'exécution de votre module complémentaire par rapport à ce qui se passerait si tout le code Apps Script était contenu dans un seul projet de script. Bien que les bibliothèques Apps Script fonctionnent dans les modules complémentaires, vous risquez de constater une baisse des 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 à leur égard.
La latence décrite ci-dessus ne s'applique qu'aux projets Apps Script utilisés comme bibliothèques côté serveur. Vous pouvez utiliser librement des bibliothèques JavaScript côté client comme jQuery sans rencontrer cette latence.
Bonnes pratiques concernant les modules complémentaires Google Workspace
Les bonnes pratiques suivantes ne s'appliquent qu'aux modules complémentaires Google Workspace et à l'utilisation du service Card.
Utiliser quelques cartes
Si le module complémentaire utilise trop de cartes, la configuration de navigation devient complexe et difficile à gérer.
Évitez de créer plus de cartes que nécessaire.
Utiliser les fonctions de création de widgets
Lorsque vous écrivez du code qui crée un Card ou d'autres objets d'UI complexes, envisagez de placer ce code dans sa propre fonction. Cette fonction de création doit simplement créer l'objet et le renvoyer. Cela vous permet de régénérer rapidement cet objet chaque fois que l'UI doit être actualisée. N'oubliez pas d'appeler build() après avoir utilisé les classes de création dans le service Card.
Simplifiez les cartes
Si une carte donnée comporte trop de widgets, elle peut occuper trop d'espace à l'écran et devenir moins utile. Bien que les grandes sections de cartes s'affichent sous 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 les 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 les informations sur l'erreur et des instructions sur la façon de la corriger, si possible. Par exemple, si votre module complémentaire n'a pas pu se connecter à un service non Google parce que l'autorisation a échoué, affichez une fiche indiquant ce problème et demandez à l'utilisateur de vérifier les informations de compte utilisées.
Écrire des tests et des messages de test
Vous devez 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 celles ci-dessous pour vérifier que les réponses sont construites correctement :
Logger.log(response.printJson());
Exécutez les fonctions de test que vous créez directement depuis l'éditeur Apps Script à l'aide du menu Exécuter. Lorsque vous disposez d'un module complémentaire viable, veillez à installer la version non publiée pour pouvoir la tester.
Utilisez des données de test adaptées à chaque application hôte que le module complémentaire étend. 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 lorsqu'il reçoit différents contenus de message. Vous pouvez obtenir l'ID d'un message donné en listant les messages à l'aide de la méthode Gmail APIusers.messages.list ou en utilisant le service Gmail d'Apps Script.
Bonnes pratiques pour les visioconférences dans Agenda
Si votre module complémentaire intègre des options de visioconférence dans un agenda tiers à Google Agenda, suivez ces bonnes pratiques supplémentaires :
Gardez le voyant onCreateFunction allumé
Chaque onCreateFunction que vous définissez dans votre fichier manifeste est appelé 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 pour créer la conférence. Si vous effectuez trop d'opérations dans ces fonctions, l'expérience utilisateur de votre module complémentaire peut être ralentie.
Utiliser les champs ConferenceData appropriés pour les données de conférence
Lorsque vous créez des objets ConferenceData, vous pouvez les remplir avec des informations sur la conférence (codes d'accès, numéros de téléphone, codes secrets, URI, etc.). Veillez à utiliser le champ EntryPoint correspondant pour ces informations. Ne saisissez pas ces informations dans le champ de notes ConferenceData.
Ne pas ajouter d'informations de conférence à l'événement Agenda
Votre module complémentaire n'a pas besoin d'ajouter d'informations sur les conférences tierces créées à la description de l'événement Agenda. Agenda le fait automatiquement si nécessaire.