Best Practices

Verbessern Sie die Nutzererfahrung Ihrer Nutzer, indem Sie diese Leitfäden zum Design von Google Meet-Add‑ons befolgen.

Best Practices für die Autorisierung

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

Google Log-in verwenden

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

Anmeldeseite von Drittanbietern in einem neuen Fenster öffnen

Neben der Google-Anmeldung bietet Ihre Anwendung möglicherweise zusätzliche Anmeldemechanismen. Verwenden Sie in diesem Fall ein Dialogfenster, anstatt eine Anmeldeseite in einem neuen Tab zu öffnen. So kann der Nutzer die Meet-Videokonferenz weiterhin sehen und zu ihr zurückkehren und muss insgesamt weniger Klicks ausführen.

Bereiche für Google APIs ordnungsgemäß anfordern

Wenn Ihr Meet-Add‑on Google APIs aufruft, dann müssen Sie eine vollständige Liste der OAuth Bereiche angeben, die für Ihr Add‑on erforderlich sind. Dies erfolgt auf der Seite „App-Konfiguration“ des Google Workspace Marketplace. 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 Daten Ihre App zugreifen darf.

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

Wenn Sie Code schreiben, um die Google Workspace APIs aufzurufen, ist die JavaScript Schnellstartanleitung der einfachste Weg, um zu beginnen. Dieser Ansatz entspricht den Best Practices für die Verwendung von Google Log-in und Dialogfenstern. Beachten Sie, dass für die Initialisierung des Token Clients in JavaScript die Bereiche, die die Anwendung zur Laufzeit tatsächlich verwendet, separat angefordert werden müssen. Für eine optimale Nutzererfahrung sollten diese angeforderten Bereiche mit den Bereichen auf der Seite „App-Konfiguration“ des Google Workspace Marketplace übereinstimmen. Diese Redundanz bietet eine Fallback-Lösung für den Fall, dass ein Nutzer Bereiche widerrufen hat.

Best Practices für die Wartung

Die folgenden Best Practices gelten für das Schreiben wartungsfreundlicher Webanwendungen, sind aber besonders wichtig, wenn Sie Meet-Add‑ons schreiben.

Aktuelle Version des Google Meet-Add‑ons SDK verwenden

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

  • Bei Verwendung von gstatic: Die aktuelle 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 Datei 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 Updates, sobald sie ihre Caches leeren oder der Cache abläuft. Wir empfehlen daher, Änderungen erst dann auf Ihre Produktionswebsite zu übertragen, wenn sie gründlich getestet wurden.

Um eine Bereitstellung direkt in der Produktion zu vermeiden, 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 kleineres 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 Google Cloud-Staging-Projekt zusätzliche Bereitstellungen hinzufügen. Diese neuen Bereitstellungen sollten Manifeste haben, die auf die alternativen Umgebungen Ihrer Webanwendung verweisen. Wir empfehlen dann, jede Add‑on-Umgebung so zu installieren:

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

Tests schreiben

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

  • Mocking des Meet-Add‑ons SDK und anschließende Überprüfung, ob das Meet-Add‑on die SDK-Funktionen wie erwartet aufruft.
  • Unittests aller nicht SDK-bezogenen Funktionen Ihres Add‑ons mit Ihrem bevorzugten Webtest-Framework.

Best Practices für die Nutzererfahrung

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

Alle Startzustände in der Seitenleiste verwalten

Wir empfehlen dringend, Ihr Add‑on basierend auf Nutzeraktionen in der Seitenleiste einzurichten. Dazu wird der Start zustand der Aktivität in JavaScript festgelegt. Alle Daten, die in das ActivityStartingState eingegeben werden, sollten vom Initiator des Add‑ons (in der Regel der Organisator der Besprechung) in der Seitenleiste festgelegt werden. Sie können sich die erste Ansicht der Seitenleiste als Formular vorstellen, mit dem die Einrichtung Ihres Add‑ons gesteuert wird.

Seitenleiste schließen, wenn sie nicht verwendet wird

Nachdem Sie die Aktivität mit der startActivity() Methode 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 unloadSidePanel() Methode aufrufen.

Meet-Add‑on durch Bildschirmfreigabe bewerben

Meet-Add‑ons bieten eine umfassendere Erfahrung als die Bildschirmfreigabe. Viele Nutzer sind jedoch an die Bildschirmfreigabefunktion von Meet gewöhnt. 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 Teilnehmern der Videokonferenz 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 durch 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.

Verwenden Sie Transparenz.

Prüfen Sie, ob Ihr Logo für den Dark-Mode im Dark-Mode gut aussieht. Verwenden Sie dazu die Entwicklertools für Meet-Add‑ons.

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

Beachten Sie die Grafikanforderungen für bestimmte App-Integrationen.

Fügen Sie Ihrem Bild keinen Abstand hinzu. Erweitern Sie das Bild stattdessen bis an die Grenzen Ihrer Datei.