La Web es una plataforma increíble que llega a usuarios de todo el mundo, básicamente en cualquier dispositivo. Es fácil de usar y fácil de compartir. No es necesario instalar nada. Pero, lo más importante, es un ecosistema abierto en el que cualquiera puede usar o desarrollar.
Hay algunas apps que actualmente no se pueden compilar ni publicar en la Web abierta. Esto se conoce como brecha de la app. La brecha entre lo que se puede hacer en la Web y lo que se puede lograr en los anuncios nativos. Queremos cerrar esa brecha. Creemos que las apps web deberían poder hacer todo lo que hacen las apps nativas.
¿Cómo diseñaremos e implementaremos estas nuevas capacidades?
Desarrollamos este proceso para que sea posible diseñar y desarrollar nuevas capacidades de plataforma web que satisfagan las necesidades de los desarrolladores con rapidez, de forma abierta y, lo más importante, para trabajar dentro del proceso de estándares existente. No difiere de la forma en que desarrollamos todas las demás funciones de las plataformas web, pero pone énfasis en los comentarios de los desarrolladores.
Los comentarios de los desarrolladores son fundamentales para ayudarnos a asegurarnos de ofrecer las funciones correctas, pero cuando llegan más tarde en el proceso, puede ser difícil cambiar de rumbo. Por eso comenzamos a pedir comentarios. Cuando los comentarios técnicos y prácticos sobre casos de uso llegan con anticipación, es más fácil corregir el curso o incluso detener el desarrollo, sin tener que enviar funciones mal pensadas o implementadas incorrectamente. Las funciones que se desarrollan en WICG no son inamovibles, y tu información puede marcar una gran diferencia en la forma en que evolucionan.
Vale la pena señalar que muchas ideas nunca pasan de la etapa de explicación o de prueba de origen. El objetivo del proceso es enviar el atributo correcto. Eso significa que debemos aprender e iterar rápidamente. No enviar una función porque no resuelve las necesidades del desarrollador está bien. Para permitir este aprendizaje, implementamos el siguiente proceso (aunque con frecuencia se cambia el orden de los pasos posteriores debido a los comentarios):
Identifica la necesidad del desarrollador
El primer paso es identificar y comprender la necesidad del desarrollador. ¿Qué está tratando de lograr el desarrollador? ¿Quién la usaría? ¿Cómo lo hacen hoy en día? y qué problemas o frustraciones solucionan esta nueva capacidad. Por lo general, se presentan como solicitudes de funciones que realizan los desarrolladores, con frecuencia, a través de errores presentados en errors.chromium.org.
Crear una explicación
Después de identificar la necesidad de una función nueva, crea una explicación, básicamente un documento de diseño destinado a explicar el problema, junto con un código de muestra que muestre cómo podría funcionar la API. La explicación es un documento de diseño activo que pasará por una gran cantidad de iteraciones a medida que evolucione la nueva capacidad.
Obtén comentarios y, luego, itera en la explicación
Una vez que la explicación tiene un nivel razonable de claridad, es hora de publicitarla, solicitar comentarios e iterar el diseño. Esta es una oportunidad para verificar que la nueva capacidad satisfaga las necesidades de los desarrolladores y funcione de la manera esperada. Esta también es una oportunidad para obtener apoyo del público y verificar que realmente se necesite esta función.
Mover el diseño a una especificación e iterar
Una vez que la explicación esté en buen estado, el trabajo de diseño pasa a una especificación formal, en la que se trabaja con los desarrolladores y otros proveedores de navegadores para iterar y mejorar el diseño.
Luego, una vez que el diseño comienza a estabilizarse, por lo general, usamos una prueba de origen para experimentar con la implementación. Las pruebas de origen te permiten probar funciones nuevas con usuarios reales y enviar comentarios sobre la implementación. Estos comentarios del mundo real ayudan a dar forma y validar el diseño, lo que garantiza que sea correcto, antes de que se convierta en un estándar.
Enviar
Por último, una vez que se completa la prueba de origen, se completa la especificación y se completan todos los demás pasos del lanzamiento, es hora de enviarlos al estado estable.
Diseña para la seguridad, la privacidad y la confianza del usuario
Algunas de estas funciones pueden parecer aterradoras al principio, especialmente si se tienen en cuenta la forma en que se implementan en anuncios nativos. Pero la Web es intrínsecamente más segura que la nativa, abrir una página web no debería ser aterrador.
No se debería otorgar acceso a ningún elemento de forma predeterminada, sino que debe depender de un modelo de permisos que otorgue al usuario el control total y que se pueda revocar fácilmente. Debe ser muy claro cuándo y cómo se usan estas APIs. Describimos parte de nuestro proceso de pensamiento en el artículo sobre el control de acceso a funciones potentes de plataformas web.