Best practice

Migliora l'esperienza complessiva dei tuoi utenti seguendo queste guide per il design dei componenti aggiuntivi di Google Meet.

Best practice per l'autorizzazione

Ti invitiamo a utilizzare le seguenti best practice per tutti i plug-in di Google Meet che richiedono autenticazione o autorizzazione.

Utilizzare Accedi con Google

Molti utenti dei componenti aggiuntivi di Google Workspace avranno già eseguito l'accesso a Google prima di partecipare alla riunione. Pertanto, avere Google One Tap come opzione può far risparmiare agli utenti diversi clic durante il flusso di accesso. Per saperne di più, consulta Gestire i metodi di accesso per il tuo componente aggiuntivo.

Aprire la pagina di accesso di terze parti in una nuova finestra

Oltre all'accesso con Google, la tua applicazione potrebbe offrire meccanismi di accesso aggiuntivi. In questo caso, utilizza una finestra di dialogo anziché aprire una pagina di accesso in una nuova scheda. In questo modo, l'utente può comunque vedere e tornare alla chiamata di Meet e dovrà eseguire meno clic complessivi.

Richiedi correttamente gli ambiti per le API di Google

Se il componente aggiuntivo di Meet chiama le API Google, devi fornire un elenco completo degli scopi OAuth richiesti dal componente aggiuntivo. Questa operazione viene eseguita nella pagina Configurazione app di Google Workspace Marketplace. Dopo aver aggiunto questi ambiti, quando installano il componente aggiuntivo Meet, gli utenti visualizzano un messaggio che indica il tipo di dati a cui consentono alla tua app di accedere.

Prima di pubblicare il componente aggiuntivo, devi anche configurare la schermata per il consenso OAuth. Ciò richiede l'aggiunta esatta degli stessi ambiti di autorizzazione dalla configurazione dell'app Google Workspace Marketplace. La configurazione della schermata per il consenso OAuth richiede anche l'impostazione delle informazioni sul branding, delle norme sulla privacy e dei Termini di servizio che vengono visualizzati quando vengono richiesti gli ambiti. Per la pubblicazione pubblica, tutte queste informazioni devono essere inviate per la verifica.

Quando scrivi codice per chiamare le API Google Workspace, il modo più semplice per iniziare è seguire la guida rapida su JavaScript. Questo approccio rispetta le best practice per l'utilizzo di Accedi con Google e delle finestre di dialogo. Tieni presente che l'inizializzazione del client di token in JavaScript richiede la richiesta separata degli ambiti effettivamente utilizzati dall'applicazione in fase di esecuzione. Per una migliore esperienza utente, questi ambiti richiesti devono corrispondere a quelli indicati nella pagina Configurazione app di Google Workspace Marketplace. Questa ridondanza fornisce un piano di riserva per gestire il caso in cui un utente abbia revocato gli scopi.

Best practice per la manutenzione

Le seguenti best practice sono per la scrittura di applicazioni web manutenibili, ma sono particolarmente importanti quando si scrivono componenti aggiuntivi di Meet.

Utilizzare la versione più recente dell'SDK dei componenti aggiuntivi di Google Meet

L'SDK dei componenti aggiuntivi di Meet viene aggiornato regolarmente. L'SDK è conforme al versionamento semantico. Per trovare la versione più recente:

  • Quando utilizzi gstatic: la versione più recente dell'SDK è contenuta nell'URL gstatic riportato nelle istruzioni per l'utilizzo dell'SDK.
  • Quando utilizzi npm: esegui npm update @googleworkspace/meet-add-ons dalla directory contenente il file package.json per il sito web che ospita il tuo componente aggiuntivo Meet.

Crea un progetto Google Cloud di staging

Una volta pubblicato il componente aggiuntivo Google Meet su Google Workspace Marketplace, tutti i nuovi implementamenti del componente aggiuntivo Google Meet sono immediatamente disponibili per gli utenti di Meet. Gli utenti vedranno questi aggiornamenti non appena svuotano la cache o quando questa scade. Pertanto, ti consigliamo di non spingere le modifiche al sito di produzione finché non sono state testate a fondo.

Per evitare di eseguire il deployment direttamente in produzione, ti consigliamo di creare un progetto Google Cloud distinto pubblicato privatamente per la tua organizzazione. Questo progetto cloud ospiterà sia gli ambienti di staging sia quelli di sviluppo per il tuo componente aggiuntivo Meet. L'accesso a questo progetto cloud deve essere limitato a un team più piccolo che si occupa direttamente dello sviluppo del componente aggiuntivo.

Per creare questi ambienti alternativi per il tuo componente aggiuntivo, devi prima ospitare ambienti alternativi della tua applicazione web che contiene il componente aggiuntivo su un dominio di tua proprietà. Quindi, puoi creare ambienti alternativi per il plug-in Meet aggiungendo implementazioni aggiuntive al progetto Google Cloud di staging. Questi nuovi deployment devono avere manifest che rimandino agli ambienti alternativi della tua applicazione web. Ti consigliamo quindi di installare ogni ambiente del componente aggiuntivo come segue:

  • Staging: pubblica la versione di staging in privato in modo che chiunque nella tua organizzazione possa aiutarti con i test.
  • Sviluppo: fai clic su Installa nella colonna Azioni per installare la versione di sviluppo del componente aggiuntivo Meet solo sul tuo account.

Scrivere i test

Prima di eseguire il deployment del componente aggiuntivo Meet in un ambiente di sviluppo, ti consigliamo di scrivere test di unità. I test di unità devono includere:

  • Simulazione dell'SDK dei componenti aggiuntivi di Meet e verifica che il componente aggiuntivo di Meet chiami le funzioni dell'SDK come previsto.
  • Esegui test di unità per tutte le funzionalità non correlate all'SDK del tuo plug-in con il framework di test web che preferisci.

Best practice per l'esperienza utente

Le seguenti best practice ti aiutano a rendere un componente aggiuntivo di Meet più intuitivo e raffinato.

Gestire tutto lo stato iniziale nel riquadro laterale

Ti consigliamo vivamente di configurare il componente aggiuntivo in base alle azioni dell'utente intraprese nel riquadro laterale. Questo viene fatto impostando lo stato iniziale dell'attività in JavaScript. Tutti i dati inseriti in ActivityStartingState devono essere impostati dall'iniziatore del componente aggiuntivo (in genere l'organizzatore della riunione) nel riquadro laterale. Puoi considerare la prima visualizzazione del riquadro laterale come un modulo che controlla la configurazione del componente aggiuntivo.

Chiudere il riquadro laterale quando non è in uso

Dopo aver avviato l'attività chiamando il metodo startActivity(), devi mantenere aperto il pannello laterale solo se è un componente essenziale dell'esperienza utente per il tuo componente aggiuntivo Google Meet. Puoi chiudere il riquadro laterale dopo aver aperto il livello principale chiamando il metodo unloadSidePanel().

Promuovere il tuo componente aggiuntivo di Meet tramite la condivisione schermo

I componenti aggiuntivi di Meet offrono un'esperienza più completa rispetto alla condivisione schermo. Tuttavia, molti utenti sono abituati a utilizzare la funzionalità di condivisione schermo di Meet. Se un utente condivide una scheda che mostra il sito web che ospita il tuo plug-in Meet, Meet può essere configurato in modo da mostrare un banner a tutti i partecipanti alla chiamata chiedendo di installare o utilizzare il plug-in Meet corrispondente. Per ulteriori informazioni, consulta la sezione sulla promozione del componente aggiuntivo tramite la condivisione schermo.

Linee guida per la progettazione del logo

Segui queste linee guida durante la progettazione del logo specifico di Meet per far sì che abbia un aspetto ottimale ora e in futuro:

Utilizza il formato file PNG con dimensioni di 256 x 256 pixel.

Utilizza la trasparenza.

Verifica che il logo in modalità Buio sia ben visibile utilizzando gli strumenti per sviluppatori per i componenti aggiuntivi di Meet.

Rispetta i requisiti grafici per integrazioni di app specifiche.

Non includere spaziature interne nell'immagine. Estendi l'immagine fino ai confini del file.