Best Practices

Wenn Sie diese Anleitungen zum Design von Google Meet-Add-ons befolgen, können Sie die allgemeine Nutzerfreundlichkeit verbessern.

Best Practices für die Autorisierung

Wir empfehlen Ihnen, die folgenden Best Practices für alle Google Meet-Add-ons zu verwenden, die eine Authentifizierung oder Autorisierung erfordern.

Google Log-in verwenden

Viele Nutzer von Google Workspace-Add-ons sind bereits in Google angemeldet, bevor sie der Videokonferenz beitreten. Wenn Google One Tap als Option verfügbar ist, können Ihre Nutzer beim Anmeldevorgang mehrere Klicks sparen. Weitere Informationen finden Sie unter Anmeldemethoden für Ihr Add-on verwalten.

 Anmeldeseite des Drittanbieters in einem neuen Fenster öffnen

Zusätzlich zum Google-Log-in kann Ihre Anwendung weitere Anmeldemechanismen anbieten. Verwenden Sie in diesem Fall ein Dialogfeld, anstatt eine Anmeldeseite in einem neuen Tab zu öffnen. So kann der Nutzer den Meet-Anruf weiterhin sehen und zu ihm zurückkehren. Außerdem sind insgesamt weniger Klicks erforderlich.

Berechtigungen für Google APIs richtig anfordern

Wenn Ihr Meet-Add-on Google-APIs aufruft, müssen Sie eine vollständige Liste der OAuth-Bereiche angeben, die für Ihr Add-on erforderlich sind. Dies erfolgt auf der Seite „Google Workspace Marketplace-App-Konfiguration“. Nachdem Sie diese Bereiche hinzugefügt haben, wird Ihren Nutzern bei der Installation Ihres Meet-Add-ons eine Aufforderung angezeigt, in der sie darüber informiert werden, auf welche Art von Daten sie Ihrer App Zugriff gewähren.

Bevor Sie Ihr Add-on veröffentlichen, müssen Sie auch den OAuth-Zustimmungsbildschirm einrichten. Dazu müssen Sie genau dieselben Autorisierungsbereiche aus der Konfiguration Ihrer Google Workspace Marketplace-App hinzufügen. Für die Konfiguration des OAuth-Zustimmungsbildschirms müssen auch die Branding-Informationen, die Datenschutzerklärung und die Nutzungsbedingungen festgelegt werden, die angezeigt werden, wenn Bereiche angefordert werden. Damit Sie öffentlich veröffentlichen können, müssen alle diese Informationen zur Überprüfung eingereicht werden.

Wenn Sie Code zum Aufrufen der Google Workspace APIs schreiben, ist der JavaScript-Schnellstart die einfachste Möglichkeit, um loszulegen. Diese Vorgehensweise entspricht den Best Practices für die Verwendung von Google Sign-In und Dialogfeldern. Beachten Sie, dass für die Initialisierung des Token-Clients in JavaScript die Bereiche, die die Anwendung tatsächlich zur Laufzeit verwendet, separat angefordert werden müssen. Für eine optimale Nutzererfahrung sollten die angeforderten Bereiche mit denen auf der Seite „App-Konfiguration“ im Google Workspace Marketplace übereinstimmen. Diese Redundanz bietet einen Fallback für den Fall, dass ein Nutzer Bereiche widerrufen hat.

Best Practices für die Wartung

Die folgenden Best Practices beziehen sich auf das Schreiben wartungsfreundlicher Webanwendungen, sind aber besonders wichtig, wenn Sie Meet-Add-ons schreiben.

 Neueste Version des Google Meet Add-ons SDK verwenden

Das Meet Add-ons SDK wird regelmäßig aktualisiert. Das SDK unterliegt der semantischen Versionsverwaltung. So finden Sie die aktuelle Version:

  • Bei Verwendung von gstatic: Die neueste SDK-Version ist in der gstatic-URL enthalten, die in der Anleitung zur Verwendung des SDK zu finden ist.
  • Bei Verwendung von npm: Führen Sie npm update @googleworkspace/meet-add-ons im Verzeichnis mit der package.json für die Website aus, auf der Ihr Meet-Add-on gehostet wird.

 Google Cloud-Staging-Projekt erstellen

Sobald Ihr Google Meet-Add-on im Google Workspace Marketplace veröffentlicht wurde, sind alle neuen Bereitstellungen Ihres Google Meet-Add-ons sofort für Meet-Nutzer verfügbar. Nutzer sehen diese Aktualisierungen, sobald sie ihren Cache leeren oder der Cache abläuft. Wir empfehlen daher, Änderungen erst dann auf Ihre Produktionswebsite zu übertragen, wenn sie gründlich getestet wurden.

Damit Sie nicht direkt in der Produktion bereitstellen, empfehlen wir, ein separates Google Cloud-Projekt zu erstellen, das privat für Ihre Organisation veröffentlicht wird. In diesem Cloud-Projekt werden sowohl die Staging- als auch die Entwicklungsumgebung für Ihr Meet-Add-on gehostet. Der Zugriff auf dieses Cloud-Projekt sollte auf ein kleines Team beschränkt sein, das direkt an der Entwicklung Ihres Add-ons arbeitet.

Wenn Sie diese alternativen Umgebungen für Ihr Add-on erstellen möchten, müssen Sie zuerst alternative Umgebungen Ihrer Webanwendung, die Ihr Add-on enthält, auf einer Domain hosten, die Ihnen gehört. Anschließend können Sie alternative Umgebungen für Ihr Meet-Add-on erstellen, indem Sie Ihrem Staging-Google Cloud-Projekt zusätzliche Bereitstellungen hinzufügen. Diese neuen Bereitstellungen sollten Manifeste haben, die auf die alternativen Umgebungen Ihrer Webanwendung verweisen. Wir empfehlen, jede Add-on-Umgebung so zu installieren:

  • Staging: Veröffentlichen Sie die Staging-Version privat, damit alle Personen in Ihrer Organisation beim Testen helfen können.
  • Entwicklung: Klicken Sie in der Spalte Aktionen auf Installieren, um die Entwicklerversion des Meet-Add-ons nur in Ihrem Konto zu installieren.

Tests schreiben

Bevor Sie Ihr Meet-Add-on in einer Entwicklungsumgebung bereitstellen, empfehlen wir, Unit-Tests zu schreiben. Ihre Unittests sollten Folgendes enthalten:

  • Das Meet-Add-on-SDK simulieren und dann prüfen, ob das Meet-Add-on die SDK-Funktionen wie erwartet aufruft.
  • Unittests für alle nicht SDK-bezogenen Funktionen Ihres Add-ons mit Ihrem bevorzugten Webtest-Framework.

Best Practices für die Nutzerfreundlichkeit

Die folgenden Best Practices helfen Ihnen dabei, ein Meet-Add-on intuitiver und raffinierter zu gestalten.

 Alle Startzustände in der Seitenleiste verwalten

Wir empfehlen dringend, das Add‑on basierend auf Nutzeraktionen in der Seitenleiste einzurichten. Dazu wird der Startstatus der Aktivität in JavaScript festgelegt. Alle Daten, die in ActivityStartingState eingegeben werden, sollten vom Initiator des Add-ons (in der Regel dem Organisator der Videokonferenz) in der Seitenleiste festgelegt werden. Die erste Ansicht der Seitenleiste ist wie ein Formular, mit dem Sie die Einrichtung Ihres Add-ons steuern.

 Seitenleiste bei Nichtverwendung schließen

Nachdem Sie die Aktivität mit der Methode startActivity() gestartet haben, sollten Sie die Seitenleiste nur geöffnet lassen, wenn sie ein wesentlicher Bestandteil der Nutzererfahrung für Ihr Google Meet-Add-on ist. Sie können die Seitenleiste schließen, sobald die Hauptbühne geöffnet ist, indem Sie die Methode unloadSidePanel() aufrufen.

Meet-Add-on über die Bildschirmfreigabe bewerben

Meet-Add-ons bieten ein besseres Nutzererlebnis als die Bildschirmfreigabe. Viele Nutzer sind jedoch daran gewöhnt, die Bildschirmfreigabe von Meet zu verwenden. Wenn ein Nutzer einen Tab freigibt, auf dem die Website gehostet wird, auf der Ihr Meet-Add-on gehostet wird, kann Meet so konfiguriert werden, dass allen Anrufteilnehmern ein Banner angezeigt wird, in dem sie aufgefordert werden, das entsprechende Meet-Add-on zu installieren oder zu verwenden. Weitere Informationen finden Sie unter Add-on über Bildschirmfreigabe bewerben.

Richtlinien für das Logodesign

Beachten Sie beim Entwerfen Ihres Meet-spezifischen Logos die folgenden Richtlinien, damit es jetzt und in Zukunft optimal aussieht:

Verwenden Sie das PNG-Dateiformat mit einer Größe von 256 × 256 Pixel.

Transparenz verwenden:

Prüfen Sie mit den Entwicklertools für Meet-Add-ons, ob Ihr Logo im dunklen Modus gut aussieht.

Prüfen Sie, ob Ihr Logo (und andere Grafikinhalte) im Modus mit hohem Kontrast gut aussieht. Verwenden Sie dazu eine Kontrastprüfung wie Contrast Checker von Web Accessibility In Mind (WebAIM).

Halten Sie die Anforderungen an Grafiken für bestimmte App-Integrationen ein.

Fügen Sie keinen Abstand in Ihr Bild ein. Erweitern Sie das Bild stattdessen bis an die Grenzen Ihrer Datei.