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éterminer qui est le propriétaire du module complémentaire avant de commencer
Les modules complémentaires sont définis par des projets Apps Script, qui doivent être la propriété d'un compte spécifique ou placés dans un drive partagé. Avant de coder un module complémentaire, déterminez le compte qui doit en être le propriétaire et celui qui en est l'éditeur. Déterminez également les comptes qui doivent jouer le rôle de collaborateurs et assurez-vous qu'ils ont accès au projet de script et au projet de plate-forme Cloud associé.
Étendre Google Workspace, pas le dupliquer
Les modules complémentaires sont destinés à fournir de nouvelles fonctionnalités aux applications Google Workspace qu'ils étendent ou à automatiser des tâches complexes. Les modules complémentaires qui ne font que 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 la publication.
Limitez 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, ne demandez pas à votre module complémentaire d'accéder entièrement à 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.
Éviter de trop dépendre des bibliothèques
L'utilisation de bibliothèques Apps Script peut entraîner l'exécution plus lente de votre module complémentaire que 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 envisagez de réduire la dépendance de votre module complémentaire à ces bibliothèques.
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 de carte.
Utiliser seulement quelques cartes
Si le module complémentaire utilise trop de cartes, la configuration de la navigation devient complexe et difficile à gérer.
Évitez l'envie de créer plus de fiches que nécessaire.
Utiliser des 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 créer l'objet et le renvoyer. Vous pouvez ainsi regé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 compilateur dans le service de carte.
Faites simple
Si une carte donnée comporte trop de widgets, elle peut occuper trop de l'écran et devenir moins utile. Bien que les grandes sections de cartes s'affichent en tant qu'é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 pas plus.
Utiliser des fiches 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 et des instructions pour la corriger, le cas échéant. Par exemple, si votre module complémentaire ne parvient pas à se connecter à un service autre que Google en raison d'un échec de l'autorisation, affichez une fiche indiquant ce fait et demandez à l'utilisateur de vérifier les informations de compte utilisées.
Écrire des tests et des messages de test
Vous devez tester en détail 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 celles-ci pour vérifier que les réponses sont correctement créées:
Logger.log(response.printJson());
Exécutez les fonctions de test que vous créez directement depuis l'éditeur Apps Script à l'aide du menu Run (Exécuter). Lorsque vous avez un module complémentaire fonctionnel, veillez à installer la version non publiée pour pouvoir le 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 avec 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 Users.messages.list de l'API Gmail ou en utilisant le service Gmail d'Apps Script.
Bonnes pratiques pour les visioconférences Agenda
Si votre module complémentaire intègre des options de visioconférence dans l'agenda tiers à Google Agenda, suivez ces bonnes pratiques supplémentaires:
Gardez votre onCreateFunction allumée
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 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 ralentie.
Utiliser les champs ConferenceData appropriés pour les données de conférence
Lorsque vous créez des objets ConferenceData, vous pouvez les renseigner avec des informations sur la conférence (codes d'accès, numéros de téléphone, épingles, 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 Google 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 Google Agenda. Google Agenda le fait automatiquement si nécessaire.