Le Web est une plate-forme incroyable qui touche des utilisateurs dans le monde entier, sur presque n'importe quel appareil. Elle est facile à utiliser et à partager. Il n'y a rien à installer. Mais surtout, il s'agit d'un écosystème ouvert que tout le monde peut utiliser ou s'appuyer.
Certaines applications ne peuvent pas être créées ni diffusées sur le Web ouvert aujourd'hui. C'est ce que nous appelons l'écart d'application. le fossé entre les possibilités sans frais sur le Web et les annonces natives. Nous voulons combler cet écart. Nous pensons que les applications Web doivent pouvoir faire tout ce que les applications natives peuvent faire.
.Comment allons-nous concevoir et implémenter ces nouvelles fonctionnalités ?
Nous avons mis au point ce processus pour permettre la conception et le développement de nouvelles fonctionnalités de plate-forme Web qui répondent aux besoins des développeurs rapidement, de façon ouverte et, surtout, dans le cadre du processus de normalisation existant. Il s'agit de la même façon que nous développons toutes les autres fonctionnalités de la plate-forme Web, mais il met l'accent sur les commentaires des développeurs.
Les commentaires des développeurs sont essentiels pour nous assurer que nous proposons les bonnes fonctionnalités, mais lorsqu'ils arrivent tard dans le processus, il peut être difficile de changer de cap. C'est pourquoi nous commençons à demander votre avis plus tôt. Lorsque des commentaires exploitables sur des aspects techniques et des cas d'utilisation arrivent tôt, il est plus facile de corriger ou même d'arrêter le développement, sans avoir à déployer de fonctionnalités mal conçues ou mal implémentées. Les caractéristiques développées par les WICG ne sont pas figées, et votre contribution peut faire une grande différence dans leur évolution.
Il est intéressant de noter que de nombreuses idées ne dépassent jamais les phases d'explication ou d'évaluation. L'objectif du processus est de proposer la bonne caractéristique. Nous devons donc apprendre et itérer rapidement. Ne pas proposer une fonctionnalité parce qu'elle ne répond pas au besoin du développeur est acceptable. Pour permettre cet apprentissage, nous avons utilisé le processus suivant (bien que les étapes suivantes soient fréquemment réorganisées en raison des commentaires):
Identifier les besoins des développeurs
La première étape consiste à identifier et à comprendre les besoins des développeurs. Qu'essaie-t-il d'accomplir ? À qui s'adresse cet outil ? Comment procède-t-on actuellement ? et les problèmes ou frustrations qui sont résolus grâce à cette nouvelle fonctionnalité. Il s'agit généralement de demandes de fonctionnalités émanant de développeurs, souvent liées à des bugs signalés sur bugs.chromium.org.
Créer une vidéo explicative
Après avoir déterminé que vous avez besoin d'une nouvelle fonctionnalité, créez une explication, essentiellement un document de conception destiné à expliquer le problème, ainsi qu'un exemple de code montrant le fonctionnement de l'API. L'explication est un document de conception évolutif qui fera l'objet d'itérations intensives à mesure que la nouvelle fonctionnalité évolue.
Obtenir des commentaires et itérer sur le contenu explicatif
Une fois que l'explication a un niveau de clarté raisonnable, il est temps de la promouvoir, de solliciter des commentaires et d'itérer la conception. C'est l'occasion de vérifier que la nouvelle fonctionnalité répond aux besoins des développeurs et fonctionne de la manière qu'ils attendent. C'est également l'occasion d'obtenir le soutien du public et de vérifier que cette fonctionnalité est réellement nécessaire.
Déplacer la conception vers une spécification et l'itérer
Une fois que l'explication est en bon état, le travail de conception devient une spécification formelle, en travaillant avec les développeurs et d'autres fournisseurs de navigateurs pour itérer et améliorer la conception.
Ensuite, une fois que la conception commence à se stabiliser, nous utilisons généralement une phase d'évaluation pour tester la mise en œuvre. Les phases d'évaluation vous permettent de tester de nouvelles fonctionnalités avec des utilisateurs réels et de donner votre avis sur l'implémentation. Ces commentaires concrets nous aident à façonner et à valider la conception, ce qui nous permet de bien faire les choses avant qu'elles ne deviennent une norme.
Expédier le colis
Enfin, une fois la phase d'évaluation terminée, les spécifications ont été finalisées et toutes les autres étapes de lancement sont terminées, il est temps d'envoyer la version en version stable.
Concevoir des solutions axées sur la sécurité, la confidentialité et la confiance des utilisateurs
Certaines de ces fonctionnalités peuvent être effrayantes au premier abord, surtout compte tenu de la façon dont elles sont implémentées en natif. Mais le Web est intrinsèquement plus sûr que le format natif. Ouvrir une page Web ne doit pas faire peur.
L'accès ne doit jamais être accordé par défaut. Toutefois, l'accès doit être basé sur un modèle d'autorisation qui donne à l'utilisateur un contrôle total et peut être facilement révoqué. Il doit être clair quand et comment ces API sont utilisées. Nous avons décrit certaines de nos réflexions sur la page Contrôler l'accès aux fonctionnalités puissantes de plates-formes Web.