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 vor der Teilnahme an der Videokonferenz bereits 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

Zusätzlich zu Google Log-in bietet Ihre Anwendung möglicherweise weitere Anmeldemechanismen. 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.

 Richtige Bereiche für Google APIs anfordern

Wenn das Meet-Add-on Google APIs aufruft, müssen Sie eine vollständige Liste der für das Add-on erforderlichen OAuth-Bereiche bereitstellen. 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 bietet ein Fallback für den Fall, dass ein Nutzer Bereiche widerrufen hat.

Best Practices für die Wartung

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

 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:

  • Mit gstatic: Die neueste SDK-Version ist in der gstatic-URL enthalten, die Sie in der SDK-Anleitung finden.
  • Bei Verwendung von npm: Führen Sie npm update @googleworkspace/meet-add-ons aus dem Verzeichnis aus, 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 der Webanwendung, die das Add-on enthält, in 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, 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

Bevor Sie das Meet-Add-on in einer Entwicklungsumgebung bereitstellen, sollten Sie Einheitentests schreiben. Ihre Unit-Tests sollten Folgendes enthalten:

  • Mocken Sie das Meet Add-ons SDK und prüfen Sie dann, ob das Meet Add-on die SDK-Funktionen wie erwartet aufruft.
  • Führen Sie einen Unittest aller nicht SDK-bezogenen Funktionen Ihres Add-ons mit Ihrem bevorzugten Web-Test-Framework 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 die ActivityStartingState eingegeben werden, sollten vom Initiator des Add-ons (in der Regel der Organisator der Videokonferenz) in der Seitenleiste festgelegt werden. Die erste Ansicht der Seitenleiste ist ein Formular, mit dem die Einrichtung Ihres Add-ons gesteuert wird.

Seitenleiste schließen, wenn sie nicht verwendet wird

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 daran gewöhnt, die Bildschirmfreigabefunktion von Meet zu verwenden. Wenn ein Nutzer einen Tab freigibt, auf dem die Website zu sehen ist, 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 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.