Best Practices

Mit diesen Anleitungen für das Design von Google Meet-Add-ons können Sie die Nutzerfreundlichkeit insgesamt verbessern.

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 vor der Teilnahme an der Videokonferenz bei Google angemeldet. Wenn Sie Google One Tap als Option anbieten, können Ihre Nutzer bei der Anmeldung mehrere Klicks sparen. Weitere Informationen finden Sie unter Anmeldemethoden für Ihr Add-on verwalten.

Anmeldeseite des Drittanbieters in einem neuen Fenster öffnen

Ihre App kann neben der Google-Anmeldung auch zusätzliche 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 muss er insgesamt weniger klicken.

 Bereiche 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 geschieht auf der Seite „Konfiguration von Google Workspace Marketplace-Apps“. Nachdem Sie diese Zugriffsbereiche hinzugefügt haben, werden Nutzer beim Installieren Ihres Meet-Add-ons aufgefordert, anzugeben, auf welche Daten Ihre App zugreifen darf.

Bevor Sie Ihr Add-on veröffentlichen, müssen Sie auch den OAuth-Zustimmungsbildschirm einrichten. Dazu müssen Sie genau dieselben Autorisierungsbereiche aus der Google Workspace Marketplace-App-Konfiguration hinzufügen. Wenn Sie den OAuth-Zustimmungsbildschirm konfigurieren, müssen Sie auch die Markeninformationen, die Datenschutzerklärung und die Nutzungsbedingungen festlegen, die angezeigt werden, wenn Bereiche angefordert werden. Damit sie öffentlich veröffentlicht werden 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, loszulegen. Dieser Ansatz entspricht den Best Practices für die Verwendung von Google Sign-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“ im Google Workspace Marketplace übereinstimmen. Diese Redundanz dient als Fallback für den Fall, dass ein Nutzer die Berechtigungen widerrufen hat.

Best Practices für die Wartung

Die folgenden Best Practices gelten für die Entwicklung wartungsfreundlicher Webanwendungen, sind aber besonders wichtig, wenn Sie Meet-Add-ons entwickeln.

 Neueste Version des Google Meet Add-ons SDK verwenden

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

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

 Google Cloud-Stagingprojekt 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 Änderungen, sobald sie ihren Cache leeren oder der Cache abläuft. Wir empfehlen daher, Änderungen erst dann auf Ihre Produktionswebsite anzuwenden, wenn sie gründlich getestet wurden.

Um eine direkte Bereitstellung 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, deren Inhaber Sie sind. 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 Ihnen, jede Add-on-Umgebung so zu installieren:

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

Tests schreiben

Wir empfehlen, vor dem Bereitstellen Ihres Meet-Add-ons in einer Entwicklungsumgebung Unit-Tests zu schreiben. Ihre Unit-Tests sollten Folgendes enthalten:

  • Mocking des Meet-Add-on-SDKs und anschließende Überprüfung, ob das Meet-Add-on die SDK-Funktionen wie erwartet aufruft.
  • Führen Sie Unittests für alle nicht SDK-bezogenen Funktionen Ihres Add-ons mit Ihrem bevorzugten Web-Testframework durch.

Best Practices für die Nutzererfahrung

Mit den folgenden Best Practices können Sie ein Meet-Add-on intuitiver und ausgefeilter gestalten.

 Alle Startstatus in der Seitenleiste verwalten

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

 Seitenleiste bei Nichtgebrauch schließen

Nachdem Sie die Aktivität durch Aufrufen 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. Wenn die Hauptbühne geöffnet ist, können Sie die Seitenleiste schließen, indem Sie die Methode unloadSidePanel() aufrufen.

 Meet-Add-on über die Bildschirmfreigabe bewerben

Meet-Add-ons bieten mehr Funktionen als die Bildschirmfreigabe. Viele Nutzer sind jedoch mit der Bildschirmfreigabefunktion von Meet vertraut. Wenn ein Nutzer einen Tab freigibt, auf dem die Website angezeigt 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 x 256 Pixeln.

Verwenden Sie Transparenz.

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

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

Fügen Sie Ihrem Bild keinen Abstand hinzu. Erweitern Sie das Bild stattdessen bis zum Rand der Datei.