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 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 les comptes qui doivent agir en tant que collaborateurs et assurez-vous qu'ils ont accès au projet de script et au projet Google Cloud associé .
Étendre Google Workspace, ne pas 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 ne font que répliquer 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 d'être approuvés pour publication après examen.
Limiter les champs d'application
Lorsque vous définissez explicitement vos champs d'application, choisissez toujours l'ensemble de champs d'application le
moins permissif possible. Par exemple, ne demandez pas à votre module complémentaire d'accéder en lecture/écriture à 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 seule. Pour un accès en lecture seule, utilisez le champ d'application https://www.googleapis.com/auth/calendar.readonly.
Éviter de trop dépendre des bibliothèques
L'utilisation de bibliothèques Apps Script peut ralentir l'exécution de votre module complémentaire par rapport à 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 pour 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 de cartes.
Utiliser seulement 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 des fonctions de création de widgets
Lorsque vous écrivez du code qui crée un
Card ou d'autres objets d'interface utilisateur complexes,
envisagez de placer ce code dans sa propre fonction. Cette fonction de création ne doit que créer l'objet et le renvoyer. Cela vous permet de régé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 cartes.
Simplifier les cartes
Si une carte donnée comporte trop de widgets, elle peut occuper une trop grande partie de l'écran et devenir moins utile. Bien que les grandes sections de carte soient affichées en tant qu'éléments d'interface utilisateur pliables, 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 cartes pour les conditions d'erreur. Si votre module complémentaire génère une erreur, il doit afficher une carte 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, car l'autorisation a échoué, affichez une carte indiquant cela 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 cartes 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 créer un objet de réponse. Vous pouvez utiliser des instructions comme les suivantes 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 à partir de 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 afin de pouvoir la tester.
Utilisez des données de test appropriées pour 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 afin de 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 de message d'un message donné en listant
les messages à l'aide de la méthode Gmail API
users.messages.list
ou en utilisant le service Gmail
d'Apps Script.
Bonnes pratiques pour les conférences dans Agenda
Si votre module complémentaire intègre des options de conférence tierces dans Google Agenda, suivez ces bonnes pratiques supplémentaires :
Limiter la taille 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 travail minimal nécessaire pour créer la conférence. Si vous en faites trop dans ces fonctions, l'expérience utilisateur de votre module complémentaire peut être lente.
Utiliser les champs ConferenceData appropriés pour les données de conférence
Lorsque vous créez
ConferenceData
objets, 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 placez pas ces informations dans le champ de notes ConferenceData.
Ne pas ajouter les 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.