Aplicaciones web progresivas de escritorio

Una nota sobre trabajar sin conexión

Hay muchas ventajas de de descubrimiento, usabilidad y capacidades simplemente haciendo que su aplicación sea instalable. Hacer que su PWA sea instalable no significa que toda su experiencia deba funcionar sin conexión. Sin embargo, para que una aplicación instalada se sienta nativa, debe tener alguna forma de funcionalidad fuera de línea. Una página básica sin conexión personalizada es suficiente para comenzar; los usuarios esperan que las aplicaciones instaladas no se bloqueen cuando cambia el estado de la conexión. Del mismo modo que una aplicación nativa nunca muestra una página en blanco cuando está fuera de línea, las PWAs nunca deben mostrar la página fuera de línea predeterminada del navegador. Las páginas sin conexión personalizadas pueden variar desde un mensaje que le informa al usuario que necesita una conexión a un juego para que pueda pasar el tiempo hasta que se vuelvan a conectar. Brindar esta experiencia fuera de línea personalizada para páginas no almacenadas en caché o características que requieren una conexión ayuda a cerrar la brecha de la aplicación de experiencia de usuario nativa de la web.

Puede crear una página simple fuera de línea durante el evento de install del trabajador de servicio (service worker) al precachear la página deseada para su uso posterior y responder con ella si un usuario está fuera de línea. Puede seguir nuestro ejemplo de página sin conexión personalizada⁠ para ver un ejemplo de esto en acción y aprender cómo implementarlo usted mismo.

Si desea proporcionar una experiencia más sólida, además de la API de almacenamiento en caché⁠ , puede usar funciones como IndexedDB⁠ para el almacenamiento NoSQL en el navegador y la sincronización de fondo⁠ para permitir a los usuarios realizar acciones mientras están fuera de línea y diferir la comunicación del servidor hasta que el usuario tenga conexión estable de nuevo. También puede implementar patrones como sesiones seguras y duraderas⁠ para mantener a los usuarios autenticados y plantillas de pantallas (skeleton screens)⁠ para que los usuarios sepan rápidamente que está cargando contenido que puede recurrir al contenido en caché o un indicador fuera de línea si es necesario.

Dibujo fluido en la web

Si está creando una aplicación que hace que los usuarios dibujen con los dedos o con lápices, mantener la latencia entre su entrada y su salida lo suficientemente rápido como para sentir fluidez históricamente ha sido difícil. Al compilar este tipo de aplicaciones de Canvas API⁠ para ChromeOS, recomendamos utilizar la sugerencia desynchronized para canvas.getContext() para proporcionar una representación de baja latencia⁠ . Para usar la sugerencia desynchronized para un lienzo, haga lo siguiente:

const canvas = document.createElement('canvas'); // or select one from the DOM
const ctx = canvas.getContext('2d', {
  desynchronized: true,
  // Other options here…
});

if (ctx.getContextAttributes().desynchronized) {
  // Low-latency supported! Do something awesome with it.
} else {
  // Low-latency not supported! Fall back to less awesome stuff
}

Consideraciones de diseño para tacto

Es importante tener en cuenta el soporte táctil y el lápiz al diseñar sus aplicaciones web. Las interacciones que puede dar por sentado, como el desplazamiento, no funcionan bien, si es que lo hacen, para otros métodos de entrada. Estas son algunas de las mejores prácticas a tener en cuenta al diseñar interfaces táctiles y compatibles con el lápiz:

• No haga suposiciones de entrada basadas en el tamaño de la pantalla. En su lugar, utilice la detección de funciones⁠ , idealmente en el momento de entrada, para determinar cómo responder. Recuerde, en ChromeOS, los usuarios pueden y sin problemas cambiar entre mouse, tacto y stylus, todo en una sola sesión.
• Asegúrese de que los elementos que espera que toque un usuario tengan un tamaño de objetivo mínimo⁠ lo suficientemente grande como para que los elementos circundantes no sean golpeados accidentalmente.
• Considere el desplazamiento como mejora progresiva⁠ y asegúrese de que la interacción se pueda lograr a través de otros medios para el tacto y el lápiz (una pulsación larga o un toque, por ejemplo).
• Los usuarios táctiles esperan poder interactuar directamente con los elementos en pantalla, por ejemplo, pellizcar para hacer zoom en los mapas en lugar de usar los botones para acercar / alejar. Agregar gestos táctiles comunes⁠ , cuando corresponda, puede hacer mucho para que su aplicación se sienta natural.

Cerrar la brecha con la aplicación nativa

La mayoría de estas capacidades se construyen para cerrar la brecha entre las aplicaciones nativas y las aplicaciones web, con las primeras capacidades principales que se envían, permitiendo que las aplicaciones web accedan a los recolectores de contactos⁠ nativos y compartan capacidades⁠ , e instalaron PWA para registrarse como un objetivo compartido nativo⁠ y mostrar insignias de íconos⁠ , por nombrar algunos⁠ .

Cada capacidad pasa por un extenso proceso de estandarización⁠ para solicitar comentarios de la comunidad para ayudar a dar forma a la API y garantizar que el diseño final sea seguro, privado y confiable. Las nuevas capacidades se rastrean en un rastreador abierto⁠ y se pueden dividir en una de cinco categorías:

Enviado: Disponible para usar en la última versión estable de Chrome. Se puede usar de manera confiable siempre que su uso se detecte correctamente.

En prueba de origen: disponible como prueba de origen⁠ (OT) de Chrome, lo que permite que las características experimentales y las API sean validadas por el equipo de Chrome en el uso en el mundo real y le permite proporcionar comentarios sobre la usabilidad y eficacia de la API. Los OT son opcionales y le permiten probar beta esta funcionalidad con sus usuarios sin necesidad de que activen ningún indicador especial en su navegador. Las API pueden cambiar después de un OT, y se garantiza que los OT no estarán disponibles por un período de tiempo antes del lanzamiento, por lo que no deben tratarse como un mecanismo de inicio temprano para las nuevas API.

En Pruebas de desarrollador: disponible detrás de una bandera en Chrome. Estas API son experimentales y aún están en desarrollo activo. Ellos no están listos para su uso en producción, con una buena probabilidad de que haya errores y que las API van a cambiar. Se recomienda encarecidamente no alentar a los usuarios a cambiar los indicadores para habilitar las funciones. Los desarrolladores pueden usar este tiempo para experimentar con características experimentales por su cuenta.

Iniciado: El desarrollo ha comenzado, pero actualmente no existe una API utilizable.

En consideración: API en las que los usuarios han expresado interés, pero la implementación aún no ha comenzado. Si aún no se ha iniciado una API, agréguela a la estrella o agregue sus casos de uso a su problema para ayudar al equipo de Chromium a priorizarla.

Qué esperar

Con tantas capacidades nuevas que se avecinan, es difícil reducir una lista de lo que tendrá el mayor impacto en la creación de aplicaciones web en ChromeOS. Estas son algunas API clave que ampliarán qué tipos de aplicaciones se pueden construir en la web y, a su vez, para ChromeOS.