Best practice

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

Best practice per l'autorizzazione

Ti invitiamo a utilizzare le seguenti best practice per tutti i componenti aggiuntivi di Google Meet che richiedono l'autenticazione o l'autorizzazione.

Utilizzare l'accesso 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 disponibile come opzione può far risparmiare agli utenti diversi clic durante la procedura di accesso. Per saperne di più, vedi Gestire i metodi di accesso per il 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à fare meno clic in totale.

Richiedere correttamente gli ambiti per le API di Google

Se il componente aggiuntivo di Meet chiama le API di Google, allora devi fornire un elenco completo degli ambiti OAuth richiesti dal componente aggientivo. Questa operazione viene eseguita nella pagina Configurazione dell'app di Google Workspace Marketplace. Dopo aver aggiunto questi ambiti, agli utenti viene mostrato un messaggio quando installano il componente aggiuntivo di Meet che indica il tipo di dati a cui l'app può accedere.

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 di 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 la pubblicazione pubblica, tutte queste informazioni devono essere inviate per la verifica.

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

Best practice per la manutenzione

Le seguenti best practice riguardano la scrittura di applicazioni web gestibili, ma sono particolarmente importanti quando scrivi 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 rispetta il controllo delle versioni semantico. Per trovare la versione più recente:

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

Creare un progetto Google Cloud di staging

Una volta pubblicato il componente aggiuntivo di Google Meet su Google Workspace Marketplace, tutti i nuovi deployment del componente aggiuntivo di 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 eseguire il push delle 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 separato pubblicato privatamente per la tua organizzazione. Questo progetto cloud ospiterà gli ambienti di staging e di sviluppo per il 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 componente aggiuntivo, devi prima ospitare ambienti alternativi dell'applicazione web che contiene il componente aggiuntivo su un dominio di tua proprietà. Poi, puoi creare ambienti alternativi per il tuo componente aggiuntivo di Meet aggiungendo altri deployment al progetto Google Cloud di staging. Questi nuovi deployment devono avere manifest che rimandano agli ambienti alternativi dell'applicazione web. Ti consigliamo quindi di installare ogni ambiente del componente aggiuntivo nel seguente modo:

  • 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 di Meet solo sul tuo account.

Scrivere test

Prima di eseguire il deployment del componente aggiuntivo di Meet in un ambiente di sviluppo, ti consigliamo di scrivere test delle unità. I test delle 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.
  • Test delle unità di tutte le funzionalità non correlate all'SDK del 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 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 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.

Chiudere il riquadro laterale quando non è in uso

Dopo aver avviato l'attività chiamando il startActivity() metodo, devi mantenere aperto il riquadro laterale solo se è una parte essenziale dell'esperienza utente del componente aggiuntivo di Google Meet. Puoi chiudere il riquadro laterale una volta aperta la fase principale chiamando il unloadSidePanel() metodo.

Promuovere il 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 schermo di Meet. Se un utente condivide una scheda che mostra il sito web che ospita il componente aggiuntivo di Meet, Meet può essere configurato per visualizzare un banner per tutti i partecipanti alla chiamata che li invita a installare o utilizzare il componente aggiuntivo di Meet corrispondente. Per saperne di più, vedi Promuovere il componente aggiuntivo tramite la condivisione 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 di file PNG, con dimensioni di 256 x 256 pixel.

Utilizza la trasparenza.

Verifica che il logo in modalità scura abbia un aspetto ottimale in modalità scura utilizzando gli strumenti per sviluppatori per i componenti aggiuntivi di Meet.

Verifica che il logo (e le altre risorse grafiche) abbiano un aspetto ottimale in modalità a contrasto elevato utilizzando un controllo del contrasto come Contrast Checker di Web Accessibility In Mind (WebAIM).

Rispetta i requisiti grafici per le integrazioni di app specifiche.

Non includere il padding nell'immagine. Estendi invece l'immagine ai limiti del file.