Best practice

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

Best practice per l'autorizzazione

Ti consigliamo di utilizzare le seguenti best practice per tutti i <x0A>componenti aggiuntivi 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, la disponibilità dell'accesso One Tap di Google come opzione può far risparmiare diversi clic agli utenti durante il flusso di accesso. Per saperne di più, consulta Gestire i metodi di accesso per il componente aggiuntivo.

Apri 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à effettuare meno clic in totale.

Richiedere correttamente gli ambiti per le API di Google

Se il componente aggiuntivo di Meet chiama le API di Google, devi fornire un elenco completo degli ambiti OAuth richiesti dal componente aggiuntivo. Questa operazione viene eseguita nella pagina Configurazione app di Google Workspace Marketplace. Dopo aver aggiunto questi ambiti, gli utenti visualizzano un prompt quando installano il componente aggiuntivo di Meet che indica agli utenti a quali tipi di dati stanno consentendo l'accesso alla tua app.

Prima di pubblicare il componente aggiuntivo, devi anche configurare la schermata per il consenso OAuth. Per farlo, devi aggiungere esattamente gli 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 visualizzati quando vengono richiesti gli ambiti. Per pubblicare pubblicamente, tutte queste informazioni devono essere inviate per la verifica.

Quando scrivi codice per chiamare le API Google Workspace, seguire la guida rapida JavaScript è il modo più semplice per iniziare. Questo approccio rispetta le best practice per l'utilizzo di Google Sign-In e delle finestre di dialogo. Tieni presente che l'inizializzazione del client token in JavaScript richiede di richiedere separatamente gli ambiti che l'applicazione utilizza effettivamente in fase di runtime. Per una migliore esperienza utente, questi ambiti richiesti devono corrispondere a quelli nella pagina di configurazione dell'app Google Workspace Marketplace. Questa ridondanza fornisce un fallback per gestire il caso in cui un utente ha revocato gli ambiti.

Best practice per la manutenzione

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

Utilizzare l'ultima versione dell'SDK per i componenti aggiuntivi di Google Meet

L'SDK per i componenti aggiuntivi di Meet viene aggiornato regolarmente. L'SDK rispetta il controllo delle versioni semantico. Per trovare l'ultima versione:

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

Crea un progetto Google Cloud di staging

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

Per evitare il deployment direttamente in produzione, ti consigliamo di creare un progetto Google Cloud separato pubblicato privatamente per la tua organizzazione. Questo progetto cloud ospiterà gli ambienti di staging e di sviluppo per il tuo componente aggiuntivo di Meet. L'accesso a questo progetto Cloud deve essere limitato a un team più piccolo che lavora direttamente allo 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à. Poi, puoi creare ambienti alternativi per il tuo componente aggiuntivo Meet aggiungendo ulteriori deployment al tuo progetto Google Cloud di staging. Questi nuovi deployment devono avere manifest che puntano agli ambienti alternativi della tua applicazione web. Poi, ti consigliamo di installare ogni ambiente componente aggiuntivo nel seguente modo:

  • Staging: pubblica privatamente la versione di staging 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.

Scrivi test

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

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

Best practice per l'esperienza utente

Le seguenti best practice contribuiscono a rendere un componente aggiuntivo 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 intraprese dall'utente nel riquadro laterale. Questa operazione viene eseguita 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) all'interno del riquadro laterale. Puoi considerare la prima visualizzazione del riquadro laterale come un modulo che controlla la configurazione del componente aggiuntivo.

Chiudi il riquadro laterale quando non lo utilizzi

Dopo aver avviato l'attività chiamando il metodo startActivity(), devi tenere aperto il pannello laterale solo se è una parte essenziale dell'esperienza utente per il tuo componente aggiuntivo Google Meet. Puoi chiudere il riquadro laterale una volta aperta la scena 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ù ricca rispetto alla condivisione schermo. Tuttavia, molti utenti sono abituati a utilizzare la funzionalità di condivisione dello schermo di Meet. Se un utente condivide una scheda che mostra il sito web che ospita il tuo componente aggiuntivo Meet, Meet può essere configurato per mostrare un banner a tutti i partecipanti alla chiamata che li invita a installare o utilizzare il componente aggiuntivo Meet corrispondente. Per ulteriori informazioni, vedi Promuovere il componente aggiuntivo tramite la condivisione dello schermo.

Linee guida per la progettazione del logo

Segui queste linee guida quando progetti il logo specifico di Meet per farlo apparire al meglio 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 abbia un bell'aspetto in questa modalità utilizzando gli strumenti per sviluppatori per i componenti aggiuntivi di Meet.

Verifica che il logo (e le altre risorse grafiche) abbia un bell'aspetto in modalità ad alto contrasto utilizzando un controllo del contrasto come Contrast Checker di Web Accessibility In Mind (WebAIM).

Rispetta i requisiti grafici per integrazioni di app specifiche.

Non includere spaziature interne nell'immagine. Estendi invece l'immagine ai limiti del file.