Il Web è una piattaforma fantastica e raggiunge utenti di tutto il mondo, essenzialmente su qualsiasi dispositivo. È facile da usare e da condividere. Non devi installare nulla. Ma soprattutto, si tratta di un ecosistema aperto che chiunque può utilizzare o utilizzare come base.
Al giorno d'oggi non è possibile creare e distribuire app sul Web aperto. È quello che chiamiamo gap tra le app. Il divario tra ciò che è possibile sul Web e ciò che è possibile sullo stile nativo. Vogliamo colmare questa lacuna. Riteniamo che le app web dovrebbero essere in grado di fare tutto ciò che è possibile fare con le app native.
Come progetteremo e implementeremo queste nuove funzionalità?
Abbiamo sviluppato questo processo per consentire la progettazione e lo sviluppo di nuove funzionalità delle piattaforme web che soddisfino le esigenze degli sviluppatori in modo rapido e aperto e, soprattutto, nel rispetto del processo degli standard esistenti. Non è diverso dal modo in cui sviluppiamo ogni altra funzionalità della piattaforma web, ma mette un'enfasi sul feedback degli sviluppatori.
Il feedback degli sviluppatori è fondamentale per consentirci di distribuire le funzionalità giuste, ma quando arriva nella fase finale del processo, può essere difficile cambiare corso. Ecco perché iniziamo a chiedere feedback prima. Quando arrivano feedback tecnici e sui casi d'uso utili, è più facile correggerli o addirittura interrompere lo sviluppo, senza dover fornire funzionalità ben studiate o implementate in modo errato. Le funzionalità in fase di sviluppo in WICG non sono stabili e il tuo input può fare una grande differenza nel modo in cui si evolve.
Vale la pena notare che molte idee non superano mai la fase esplicativa o di prova dell'origine. L'obiettivo del processo è fornire la funzionalità giusta. Significa che dobbiamo imparare e iterare rapidamente. Non inviare una funzionalità perché non soddisfa le esigenze degli sviluppatori. Per consentire questo apprendimento, abbiamo adottato il seguente processo (anche se spesso viene riordinato i passaggi successivi in seguito ai feedback):
Identificare le esigenze degli sviluppatori
Il primo passaggio consiste nell'identificare e comprendere le esigenze degli sviluppatori. Che cosa sta cercando di ottenere lo sviluppatore? Chi lo userebbe? Come stanno facendo oggi? e quali problemi o frustrazioni vengono risolti da questa nuova funzionalità. In genere, queste vengono richieste sotto forma di richieste di funzionalità da parte degli sviluppatori, spesso tramite bug segnalati su bugs.chromium.org.
Crea un messaggio esplicativo
Dopo aver identificato la necessità di una nuova funzionalità, crea un spiegazione, ovvero un documento di progettazione finalizzato a spiegare il problema, insieme a un codice campione che mostra come potrebbe funzionare l'API. Il testo esplicativo è un documento di progettazione vivente che subirà una forte iterazione man mano che la nuova funzionalità si evolve.
Ricevere un feedback e ripetere il testo esplicativo
Una volta che il testo esplicativo è stato fornito a un ragionevole livello di chiarezza, è il momento di pubblicizzarlo, richiedere un feedback e ripetere il progetto. Questa è un'opportunità per verificare che la nuova funzionalità soddisfi le esigenze degli sviluppatori e funzioni nel modo che si aspettano. È anche un'opportunità per raccogliere supporto pubblico e verificare che questa funzionalità sia davvero necessaria.
Adatta il design alle specifiche e ottimizzalo
Una volta che il testo esplicativo è in buone condizioni, il lavoro di progettazione passa a una specifica formale, collaborando con sviluppatori e altri fornitori di browser per eseguire l'iterazione e migliorare il design.
Poi, una volta che la progettazione inizia a stabilizzarsi, generalmente utilizziamo una prova dell'origine per sperimentare l'implementazione. Le prove dell'origine ti consentono di provare nuove funzionalità con utenti reali e di fornire feedback sull'implementazione. Questo feedback reale aiuta a modellare e convalidare il design, assicurandoci che sia corretto prima che diventi uno standard.
Spedisci
Infine, una volta completata la prova dell'origine, finalizzate le specifiche e completati tutti gli altri passaggi di lancio, sarà il momento di spedirlo in un ambiente stabile.
Progetta tenendo a mente la sicurezza, la privacy e la fiducia degli utenti
All'inizio, alcune di queste funzionalità possono fare paura, soprattutto alla luce di come sono implementate sul formato nativo. Ma il web è intrinsecamente più sicuro del nativo, aprire una pagina web non dovrebbe essere un problema.
L'accesso non dovrebbe mai essere concesso per impostazione predefinita, ma affidati a un modello di autorizzazione che dà all'utente il controllo totale e può essere facilmente revocata. Deve essere chiaro quando e come queste API vengono utilizzate. Abbiamo descritto alcune delle nostre materie in Controllo dell'accesso a potenti funzionalità della piattaforma web.