Het web is een fantastisch platform; het bereikt gebruikers over de hele wereld – op vrijwel elk apparaat. Het is gebruiksvriendelijk en makkelijk te delen. Er hoeft niets geïnstalleerd te worden. Maar het allerbelangrijkste is dat het een open ecosysteem is dat iedereen kan gebruiken of waarop iedereen kan voortbouwen.
Er zijn bepaalde apps die momenteel niet ontwikkeld en beschikbaar gesteld kunnen worden op het open web. We noemen dit de app-kloof : het verschil tussen wat mogelijk is op het web en wat mogelijk is met native apps. Wij willen die kloof dichten. Wij vinden dat webapps alles moeten kunnen wat native apps kunnen.
Hoe gaan we deze nieuwe mogelijkheden ontwerpen en implementeren?
We hebben dit proces ontwikkeld om het mogelijk te maken snel, open en vooral binnen de bestaande standaarden nieuwe functionaliteiten voor het webplatform te ontwerpen en te ontwikkelen die aansluiten op de behoeften van ontwikkelaars. Het is in principe hetzelfde als de manier waarop we alle andere functies van het webplatform ontwikkelen, maar het legt de nadruk op feedback van ontwikkelaars.
Feedback van ontwikkelaars is cruciaal om ervoor te zorgen dat we de juiste functionaliteiten leveren, maar als die feedback laat in het proces binnenkomt, kan het lastig zijn om van koers te veranderen. Daarom vragen we nu eerder om feedback. Wanneer we vroegtijdig bruikbare technische feedback en feedback over gebruiksscenario's ontvangen, is het gemakkelijker om bij te sturen of zelfs de ontwikkeling stop te zetten, zonder dat we slecht doordachte of slecht geïmplementeerde functionaliteiten hebben uitgebracht. De functionaliteiten die bij WICG worden ontwikkeld, staan niet vast en uw input kan een groot verschil maken in hoe ze zich ontwikkelen.
Het is belangrijk om te weten dat veel ideeën nooit verder komen dan de uitleg- of testfase . Het doel van het proces is om de juiste functionaliteit te leveren. Dat betekent dat we snel moeten leren en itereren. Het is prima om een functionaliteit niet te leveren omdat deze niet voldoet aan de behoeften van de ontwikkelaar. Om dit leerproces mogelijk te maken, hanteren we het volgende proces (hoewel latere stappen vaak in een andere volgorde worden geplaatst op basis van feedback):
Identificeer de behoefte van de ontwikkelaar
De eerste stap is het identificeren en begrijpen van de behoefte van de ontwikkelaar. Wat probeert de ontwikkelaar te bereiken? Wie zou het gebruiken? Hoe doen ze het momenteel? En welke problemen of frustraties worden opgelost door deze nieuwe functionaliteit? Meestal komen deze verzoeken binnen als functieverzoeken van ontwikkelaars, vaak via bugrapporten op bugs.chromium.org .
Maak een uitleg
Nadat de behoefte aan een nieuwe functionaliteit is vastgesteld, maak je een uitlegdocument , in feite een ontwerpdocument dat het probleem uitlegt, samen met voorbeeldcode die laat zien hoe de API zou kunnen werken. Het uitlegdocument is een dynamisch ontwerpdocument dat voortdurend wordt aangepast naarmate de nieuwe functionaliteit zich ontwikkelt.
Verzamel feedback en verbeter de uitleg.
Zodra de uitleg voldoende duidelijk is, is het tijd om deze te publiceren, feedback te verzamelen en het ontwerp te verbeteren. Dit is een kans om te controleren of de nieuwe functionaliteit voldoet aan de behoeften van ontwikkelaars en werkt zoals zij verwachten. Het is ook een gelegenheid om publieke steun te verwerven en te verifiëren of er daadwerkelijk behoefte is aan deze functionaliteit.
Zet het ontwerp om in een specificatie en herhaal het proces.
Zodra de uitleg in een goede staat verkeert, gaat het ontwerpproces over in een formele specificatie. Daarbij wordt samengewerkt met ontwikkelaars en andere browserleveranciers om het ontwerp te verfijnen en te verbeteren.
Zodra het ontwerp stabiel begint te worden, gebruiken we doorgaans een testfase om te experimenteren met de implementatie. Testfasen stellen je in staat om nieuwe functionaliteiten met echte gebruikers uit te proberen en feedback te geven op de implementatie. Deze feedback uit de praktijk helpt bij het vormgeven en valideren van het ontwerp, zodat we er zeker van zijn dat het goed is voordat het een standaard wordt.
Verzend het
Zodra de testfase is afgerond, de specificaties definitief zijn vastgesteld en alle andere lanceringsstappen zijn voltooid, is het tijd om de stabiele versie uit te brengen.
Ontwerp gericht op gebruikersveiligheid, privacy en vertrouwen.
Sommige van deze functies lijken misschien in eerste instantie eng, vooral gezien de manier waarop ze in native apps worden geïmplementeerd. Maar het web is inherent veiliger dan native apps, dus het openen van een webpagina zou geen angst moeten opwekken.
Niets mag standaard toegang krijgen, maar in plaats daarvan moet er een permissiemodel worden gehanteerd dat de gebruiker volledige controle geeft en dat gemakkelijk ingetrokken kan worden. Het moet glashelder zijn wanneer en hoe deze API's worden gebruikt. We hebben een deel van onze denkwijze uiteengezet in 'Toegang tot krachtige webplatformfuncties beheren' .