HTML

ePub

PDF

1. Introducción

El World Wide Web Consortium (W3C), es un consorcio internacional que establece estándares para la Web. Esos estándares, llamados recomendaciones, son tomados e implementados por los navegadores Web, permitiendo que los desarrolladores los utilicen. Estas recomendaciones son muy importantes para la portabilidad ya que permiten que cualquier usuario utilice una aplicación Web con todas sus características sin importar el navegador que posea. Este artículo presenta un relevamiento de las recomendaciones del W3C realizando una clasificación de acuerdo con el grado de madurez alcanzado dentro de las categorías propuestas por la misma organización. Sin perder de vista la importancia de la estandarización llevada a cabo por el W3C, se presenta un caso de estudio que evidencia problemas en la evolución entre las diferentes etapas. Las nuevas funcionalidades son implementadas en los navegadores antes de estandarizarse, por lo tanto, surgen las siguientes dudas: ¿Es confiable tomar como base e implementar una tecnología que aún no se ha convertido en recomendación, pero está cerca de serlo? ¿Cuánto tiempo debe un desarrollador esperar para poder usar una nueva tecnología en sus desarrollos? El caso de estudio propuesto dará respuesta a estas preguntas.

La disponibilidad de los dispositivos móviles es alta, principalmente los teléfonos celulares han sido los dispositivos con mayor inserción en el mercado. “Tanto los desarrollos de estándares tecnológicos como la fuerte implantación social en relación al uso cotidiano, la portabilidad y la identidad individual han hecho del teléfono móvil el dispositivo idóneo para aglutinar buena parte de los usos que caracterizan a la Sociedad de la Información” [1].

Es por ello que resulta indispensable tener en cuenta a los dispositivos móviles al momento de diseñar una aplicación. Las pantallas y teclados reducidos son algunas de las limitaciones a las que se deben enfrentar los diseñadores. Así también es importante tomar en cuenta que el usuario móvil no tiene su atención puesta completamente en el dispositivo. Es por ello por lo que las interfaces deben ser simples y directas, para que permitan al usuario alcanzar los principales contenidos/servicios con la mayor facilidad y rapidez posible.

Pero los smartphones incluyen características muy interesantes en cuanto a hardware, como por ejemplo una gran cantidad de sensores que pueden ser aprovechados en el desarrollo de las aplicaciones. Por lo tanto, no se trata tan sólo de pensar en la interfaz que se le presentará al usuario, sino también en el caso de los smartphones como aprovechar el hardware disponible en las soluciones presentadas.

No hace falta que sea puntualmente una solución que requiera hardware para poder funcionar sino simplemente aprovechar el hardware que está disponible para brindar una experiencia de uso más completa al usuario.

Un simple ejemplo es utilizar el motor de vibración presente en los smarthpones para dar una alerta al usuario o dar un feedback de una acción realizada. En el trabajo [2] se presenta un análisis del uso del sensor de proximidad que permite utilizar un teléfono celular por medio de gestos aéreos, esto es un ejemplo de cómo el hardware puede ser integrado a todo tipo de aplicaciones.

Al mencionar integración de hardware es posible presuponer que la aplicación debe ser nativa. Las aplicaciones nativas son aquellas que se desarrollan para un sistema operativo particular, permitiendo el completo acceso al hardware, además tienen la ventaja de que su interfaz tendrá el mismo aspecto al que el usuario está acostumbrado en el resto de las pantallas provistas en el sistema operativo.

Sin embargo, actualmente las aplicaciones Web permiten emular los controles nativos, de esta forma es posible visualmente obtener una interfaz uniforme. ¿Pero qué sucede en cuanto al acceso al hardware? ¿Es necesario desarrollar una aplicación nativa para poder utilizarlo? La respuesta es no, ya que las aplicaciones Web incorporan cada vez más posibilidades de acceso al hardware, achicando la brecha que existía entre aplicaciones Web y nativas [3]. “Las nuevas mejoras realizadas en las tecnologías web permitieron más características y capacidades que antes solo eran posibles en aplicaciones que fueron desarrolladas en forma nativa.” [4]

La principal ventaja de una aplicación Web frente a una aplicación nativa es su portabilidad. Al desarrollar una aplicación web, esta será funcional independientemente del sistema operativo en el cual sea utilizada. “Una de las principales dificultades al desarrollar aplicaciones para móviles es la diversidad de dispositivos y sistemas operativos, teniéndose que construir una versión diferente para cada caso en un lenguaje y una herramienta diferente” [5]. “Si se desea cubrir varias plataformas, se deberá generar una aplicación para cada una de ellas.

Esto conlleva a mayores costos de actualización y distribución de nuevas versiones” [6]. Por lo que algunos desarrolladores recurren a soluciones híbridas usando frameworks tales como PhoneGap [7], encontrando una solución a la portabilidad, teniendo algunas limitaciones propias de la Web como el acceso completo al hardware. Entonces ¿por qué buscar una solución alternativa y no realizar directamente una aplicación Web que aproveche la web a su máximo potencial?

Los Smartphones gracias a HTML 5 [8] cuentan con la posibilidad de ejecutar aplicaciones Web enriquecidas, en las cuales el acceso a la información propia del dispositivo y al hardware es una realidad. “HTML5 se ha concebido con el propósito de simplificar el trabajo de los diseñadores de Web y mejorar el rendimiento de las páginas, especialmente en dispositivos móviles” [9].

2. Estándares del W3C

El W3C es un consorcio web a nivel internacional que establece estándares para la Web en general e incluye a la web móvil [10]. “Los estándares Web son las respuestas más eficaces a la rápida y continua evolución tecnológica que experimenta la red. Adecuarse a ellos hace posible que el trabajo de hoy constituya una base efectiva en el futuro y ayude a evolucionar tecnológicamente con el medio” [11]. “Los estándares Web ofrecen un grupo de posibilidades y sus ventajas clave están en la posibilidad de llegar a un mayor número de usuarios, al expandir el acceso a la información del sistema a un amplio número de navegadores y dispositivos” [11].

El W3C publica periódicamente actualizaciones de un documento al que denominan “Roadmap”, este documento “resume las diversas tecnologías desarrolladas en W3C que aumentan las capacidades de las aplicaciones Web y cómo se aplican más específicamente al contexto móvil” [12].

El documento se encuentra dividido en 12 categorías, que abarcan diversos aspectos, que van desde cuestiones de visualización del sitio Web hasta cuestiones internas que permitan mejorar el funcionamiento e incorporar el uso de hardware en las aplicaciones. Las categorías son:

1. Gráficos y Layout: dedicada a los gráficos y a la distribución de los elementos de la página. Las tecnologías que se analizan en esta categoría son: CSS (Cascading Style Sheets), WOFF (Web Open Font Format), SVG (Scalable Vector Graphics).

2. Adaptación al Dispositivo: Las principales tecnologías de base analizadas en esta categoría son: CSS Media Queries y SVG.

3. Formularios: En esta categoría básicamente se trabaja con los controles propios de formularios que provee HTML, en su actual versión.

4. Almacenamiento de Datos: Trabaja con APIs (Application Programming Interface – Interfaz de Programación de Aplicaciones) que permiten desde el almacenamiento de información hasta la indexación y almacenamiento encriptado.

5. Media: HTML 5 incorpora los tags video y audio, los cuales facilitan todo el trabajo multimedia, no obstante, hay APIs en progreso que tienen que ver con captura de audio/video, streaming desde la Web usando conectividad P2P (punto a punto) en otras tecnologías.

6. Interacción del Usuario: Esta categoría se basa en la interacción y la accesibilidad analizando eventos táctiles, vibración, Notificaciones Web que abren paso a futuros desarrollos como: Método para ingresar texto, Scroll suave, Despertar la pantalla…

7. Sensores e Interacciones Locales: En esta categoría se ubica la API de Geolocalización, junto a otras APIs en progreso como la de sensor de proximidad, estado de la batería…

8. Redes y Comunicaciones: En esta categoría se utilizan tecnologías de AJAX, WebSocket, Eventos iniciados por el servidor…

9. Ciclo de Vida de la Aplicación: Las aplicaciones Web se acercan a las nativas, en el sentido que ya se considera que estas pueden funcionar incluso sin conexión a internet y la importancia de optimizar recursos. Por ello, una de las APIs principales de esta categoría está enfocada en poder detectar si la aplicación está en primer plano o no lo está, para poder optimizar el consumo de recursos.

10. Pagos y Servicios: HTML proporciona ayuda específica para completar automáticamente los detalles de la tarjeta de crédito, lo que facilita el pago una vez que estos datos fueron ingresaron previamente. Distintos grupos del W3C se encuentran trabajando en diversos métodos para solicitar pagos, identificar método de pago, etc.

11. Performance y Ajustes: En esta categoría se analizan mecanismos para supervisar o mejorar el rendimiento de una aplicación Web. Se presentan distintas APIs para poder realizar mediciones tomando tiempos de carga, navegación, etc.

12. Seguridad y Privacidad: Un claro ejemplo de esta categorías el atributo sandbox de HTML5 que permite restringir el tipo de interacciones que pueden realizarse con contenidos incrustados de terceros. También en esta categoría están asociadas las APIs de encriptación de datos (mencionada previamente en la categoría almacenamiento de datos) que permitirán enviar información encriptada desde el sitio Web.

Cada una de estas categorías reúne trabajos que atraviesan diferentes grados de madurez hasta poder convertirse finalmente en estándares. Los estándares para poder consolidarse siguen determinados pasos, los cuales se sintetizan en la tabla 1 (ver paso 1 al paso 6). Los 6 primeros pasos representan las etapas de estandarización del W3C, en donde el grado de madurez va avanzando hasta finalmente convertirse en una Recomendación (paso 6).

Todo comienza con los borradores de trabajo (pasos 1 y 2) y la convocatoria de participación abierta a la comunidad (paso 3) que permitirá reunir expertos y colaboradores en una determinada categoría y dentro de ella una característica particular a desarrollar. A modo de ejemplo, se presenta el caso del “Cascading Style Sheets Working Group”, este grupo de trabajo tiene actualmente 126 colaboradores [12], los cuales pertenecen a distintas empresas y organismos.

Es de esperarse que al proponerse como recomendación candidata (paso 4), se comience a enviar la propuesta de implementación a los distintos navegadores. No obstante, los grupos de trabajo envían en etapas tempranas los avances para poder ser implementados en los distintos navegadores. A modo de ejemplo, la figura 1 representa una característica particular de la categoría 4 (almacenamiento de datos), que el W3C la ha catalogado como tecnología en proceso.

Puede observarse que su etapa de estandarización es WD (es decir un borrador del grupo de trabajo que según el estado de madurez del W3C, está en el paso 2), no obstante, ha sido enviado para una posible implementación en distintos navegadores.

Las Recomendaciones Candidatas (paso 4) se someten a pruebas de implementación las cuales están disponibles en el W3C para su consulta y revisión, tal como puede verse a modo de ejemplo en la figura 2.

En el paso 5 el W3C hace una última revisión en la que puede dictaminar si finalmente el desarrollo en cuestión será una recomendación (alcanzando el paso 6).

Existen durante el proceso de estandarización tres estados adicionales (representados por las tres últimas filas de la tabla 1), que son excepcionales, pero pueden observarse como símbolo del grado de madurez en alguna de las características en las que se está trabajando: (1) “Retired” con esto se indica que se ha dado de baja lo realizado (esto puede ocurrir mayormente en etapas tempranas del desarrollo), el ícono mostrado en la tabla 1 alertará que dicho documento ha sido desconsiderado.

(2) “LS” esta sigla junto con el ícono gráfico presentado en la tabla 1 indicará que el estándar si bien es estable puede sufrir actualizaciones constantes. (3) “Note” tiene que ver con material adicional que puede incluir buenas prácticas, casos de uso, etc.

Las especificaciones se consideran establecidas cuando llegan a la etapa 6, por lo tanto en cada categoría pueden haber trabajos establecidos, trabajos en progreso, trabajos que recién están comenzando a desarrollarse para analizar su factibilidad (exploratorios) y trabajos que ya fueron abandonados o discontinuados. Tomando en cuenta estos 4 estados en la Fig. 3 se presenta una gráfica que presenta la cantidad de especificaciones por categoría.

la figura 3 se desprende que:

· La categoría con mayor cantidad de especificaciones establecidas es la 1 (Gráficos y Layout).

· La categoría 11 (Performance y Ajustes) es la que tiene mayor cantidad de especificaciones en total.

· La categoría 4 (Almacenamiento de Datos) es aquella que tiene más especificaciones que han sido discontinuadas. En muchos casos esto se debe a que dichas características serán abarcadas de forma distinta por nuevos trabajos.

· Las categorías 1, 2 y 10 (que corresponden respectivamente a: Gráficos y Layout; Adaptación del Dispositivo; Pagos y Servicios), no tienen especificaciones discontinuadas.

· La categoría con menos especificaciones es la 10 (Pagos y Servicios), que a su vez tiene la mayor parte de sus especificaciones en progreso.

En todas las categorías hay especificaciones ya establecidas y un trabajo continuo que se encuentra en proceso para poder generar nuevas especificaciones.

3. Utilización de los estándares

El W3C pone a disposición estándares que pueden ser utilizados, no obstante, no son siempre implementados por los navegadores o incluso cuando están disponibles en los mismos, los desarrolladores por desconocimiento no los utilizan. “El World Wide Web Consortium (W3C) promulga los estándares…, pero no tiene autoridad para hacer cumplir la adopción de una norma a favor de otra” [14].

Por otra parte, aquellas especificaciones que aún no están establecidas tendrán diversos cambios que harán que las aplicaciones que se generen utilizando dichas funcionalidades queden obsoletas. También en diversas ocasiones las especificaciones están en progreso durante mucho tiempo sin saber si efectivamente serán discontinuadas o bien podrán avanzar para madurar y consolidarse como estándar.

4. Caso de estudio - Evolución en etapas de estandarización

Se toma como caso de estudio la especificación relacionada con el uso del Sensor de Proximidad, la cual está contenida en la categoría 7 (denominada “Sensores e Interacciones Locales”). En el año 2013 el uso del sensor de proximidad se encontraba bajo la especificación de “Eventos de Proximidad” cuyo estado era Recomendación Candidata como puede observarse en la captura de pantalla presentada en la figura 4.

Volviendo a la tabla 1 puede observarse que estando en la etapa 4 (recomendación candidata) faltan tan sólo 2 etapas para convertirse en una recomendación final del W3C. Lo que se analiza con este caso de estudio es ¿Cuánto tiempo llevarán dichas etapas? ¿En qué etapa estará actualmente, habrá llegado a la etapa 6?

Cada documento permite ver el anterior y el siguiente (tal como puede observarse en los links que presenta la figura 4). De este modo se ha hecho un seguimiento del estándar pudiéndose ver que en el 2015 (dos años después) había regresado a ser un borrador de trabajo, es decir a la etapa 2 (ver figura 5), en el 2016 si bien el estado seguía siendo el mismo había cambiado de nombre y pasó a denominarse “Proximity Sensor” (ver figura 6).

Para dar respuesta a la pregunta ¿En qué etapa estará actualmente, habrá llegado a la etapa 6?, basta con mirar la siguiente captura presentada en la figura 7, el último documento corresponde al año 2019, en donde puede observarse que aparece en la etapa 2 (WD - Working Draft) [15], habiendo el año anterior involucionado hacia la etapa 1 (ED - Editor Draft) (ver figura 8).

En cuanto al otro interrogante planteado ¿Cuánto tiempo llevarán dichas etapas? No hay una respuesta precisa, depende de cada caso en particular, en este caso de análisis han pasado en total 9 años y habiendo estado esta funcionalidad como recomendación candidata en el paso 4 de la estandarización, muy cercano al paso final numerado como 6, ha regresado al paso 1 y actualmente ha vuelto al paso 2. Esto es decepcionante para los desarrolladores que han construido soluciones basadas en la recomendación candidata y ahora se encuentran con que eso ha cambiado y hay un destino incierto.

Se desconoce cómo será la implementación final para poder utilizar el sensor de proximidad y cuánto tiempo más demande tener finalmente la recomendación del W3C (es decir alcanzar el paso 6). Esto debe plantear un nuevo interrogante: ¿Es confiable tomar como base e implementar una tecnología que aún no se ha convertido en recomendación pero que está cerca de estarlo?, dado los importantes cambios que ocurren en los mismos dejando soluciones que se apoyan en estas especificaciones obsoletas, la recomendación es esperar que las especificaciones se asienten y se transformen en recomendaciones (paso 6 del proceso) lo cual no quita que la espera para esto pueda ser verdaderamente larga.

Realizando el seguimiento entre documentos se construye el diagrama de la figura 9, puede observarse que el primer documento accesible data del 2012 y que en un solo año había avanzado de Etapa 2 a Etapa 4. A pesar de este prometedor avance, dos años después vuelve la especificación a etapa 2, tres años después retrocede a la etapa 1 y finalmente se encuentra nuevamente en etapa 2.

Este caso de análisis muestra la dificultad para realizar el seguimiento de una especificación y además deja en evidencia que los pasos a seguir para el proceso de estandarización no siempre avanzan, sino que también pueden implicar un retroceso.

5. Relevamiento por categoría

Habiendo tomado una especificación, como caso de estudio en la sección anterior, se pudo advertir estancamiento en los pasos e involución en los mismos. Entonces surge el interrogante ¿Es este un caso aislado u ocurre en forma general en las especificaciones del W3C? Para dar respuesta a esta pregunta, de las 12 categorías existentes se analizan cuatro (categorías 1, 4 y 10) es decir se considera una muestra del 33%.

A modo de resultados la tabla 2 presenta la cantidad de especificaciones comprendidas en la muestra tomada, clasificadas según su estado actual, en uno de 6 pasos, a lo que se agrega las que fueron retiradas (R), las que están en constante actualización (LS) y las que poseen una nota (N). A continuación, la columna documentos representa la cantidad de documentos que debieron seguirse para poder tener la trazabilidad de las especificaciones de dicha categoría y la columna final muestra el promedio de años de progreso de cada especificación tomando la fecha del primero y el último documento publicado (exceptuándose las especificaciones en estado LS dado que ellas no cuentan con trazabilidad, se muestra sólo la última especificación sin links a las anteriores).

En la última fila se presentan los totales, en donde se ha sumado entre todas las categorías la cantidad de especificaciones por paso, más las tres columnas de estados adicionales, del mismo modo se obtiene el total de documentos analizados y finalmente la última columna representa el promedio de los tiempos de cada categoría. Este relevamiento origino seguir la trazabilidad de 49 especificaciones dando por resultado el análisis de 526 documentos publicados por el W3C. Como puede observarse la mayor cantidad de especificaciones se encuentran en estado 2 (31%), siendo el tiempo promedio en años desde el primer documento hasta el último generado por la especificación es de 7.

De las especificaciones que aún no llegaron a ser una recomendación, se analiza cuantos años estuvieron en el estado actual alcanzado (fecha de la última especificación publicada con respecto a la fecha actual). Puede observarse en la Figura 10 que los tiempos se enmarcan a partir de los 2 años hasta los 9 años, el 27% llevan 2 años sin evolución y el 13% 4 años, llama la atención que incluso un 7% de estas especificaciones quedaron estancadas durante 9 años.

En todas las categorías analizadas se ha encontrado especificaciones que han involucionado, siendo los porcentajes: Categoría 1: 60%, Categoría 4: 50%, Categoría 7: 50%, Categoría 10: 40%. Del total hay un 37% de especificaciones que han involucionado.

Puede observarse en este análisis dos problemas significativos por un lado el estancamiento de las especificaciones que no cambian de estado incluso por 9 años y otras que involucionan retrocediendo de estados.

6. Conclusiones

Es clara la importante actividad que realiza el W3C mediante sus recomendaciones que brindan pautas y consideraciones indispensables para la buena implementación tanto de la Web en general como la Web móvil. El hardware de los dispositivos permite realizar un amplio abanico de aplicaciones que no requieren ser nativas dado que con la llegada de HTML 5 es posible hacer uso del hardware desde la Web mediante el uso de las API.

Pero los tiempos de estandarización del W3C, dificultan esta tarea. No podemos negar que debe existir un proceso que cuente con pasos precisos abiertos a la colaboración de la comunidad para poder tener recomendaciones consolidadas y lo suficientemente probadas. Es de esperarse que en 6 pasos establecidos puedan estancarse algunos trabajos y no logren estandarizarse, también es posible que el avance sea lento.

Pero la dificultad se presenta cuando no sólo las propuestas pueden ser retiradas o actualizadas, sino que estas pueden tener un retroceso tan marcado como el presentado en este artículo con el caso de estudio, en donde habiendo estado en el paso 4, actualmente esté en el paso 2. Solo tomando estas etapas los años van del 2013 al 2021, unos 8 años de involución. Esto es algo completamente desalentador para todo desarrollador que espera utilizar el estándar para su aplicación Web. Creemos que debería haber limitaciones de tiempo para cada uno de los pasos de estandarización y un seguimiento más fácil del grado de madurez, evitando sobre todo retrocesos. El relevamiento presentado en este artículo, que consideró las 49 especificaciones contenidas en 4 de las 12 categorías, permitió evidenciar que el caso de estudio no era un caso aislado, siendo 7 años el promedio de trabajo por especificación para alcanzar el estado actual, pese a que 35% de ellas se encuentra en el paso 1 o paso 2.

Los tiempos extensos son una complicación clara para el proceso de madurez de las especificaciones.No siendo miembros del W3C, nuestro objetivo fue presentar un relevamiento representativo que permita visibilizar la problemática y alertar a los desarrolladores de software que deben esperar (a pesar de los tiempos) a que las tecnologías estén maduras para trabajar con ellas. Por otra parte, visibilizando la problemática esperamos que el W3C pueda establecer tiempos máximos para el cambio de estado de cada especificación y de este modo alentar a los grupos de trabajo a ser más activos y disminuir el promedio de tiempos.

REFERENCIAS

[1] Aguado, Juan Miguel, and Inmaculada J. Martínez. "El proceso de mediatización de la telefonía móvil: de la interacción al consumo cultural." Zer-Revista de Estudios de Comunicación11.20 (2006).

[2] Rodríguez, R. A., Vera, P. M., Martínez, M. R., Parra Beltrán, F. A., & Alcidor, J. Análisis e implementación de nuevas tecnologías para la web móvil. In XIX Workshop de Investigadores en Ciencias de la Computación (WICC 2017, ITBA, Buenos Aires). 2017

[3] Fortunato, David, and Jorge Bernardino. "Progressive web apps: An alternative to the native mobile Apps." 2018 13th Iberian Conference on Information Systems and Technologies (CISTI). IEEE, 2018.

[4] Charland, A., & Leroux, B. Mobile application development: web vs. native. Communications of the ACM, 54(5), 49-53. 2011

[5] Rodríguez, Camilo, and Héctor Enríquez. "Características del desarrollo en Frameworks multiplataforma para móviles." Ingenium Revista de la facultad de ingeniería 15.30 (2014): 101- 117.

[6] Delía, L. N., Galdamez, N., Thomas, P., & Pesado, P. M. (2013). Un análisis experimental de tipo de aplicaciones para dispositivos móviles. In Congreso Argentino de Ciencias de la Computación (CACIC) (Vol. 18).

[7] Adobe PhoneGap, Disponible en: https://phonegap.com/

[8] W3C, HTML 5.[Online]. Disponible en: https://www.w3.org/TR/html52/

[9] Franganillo, Jorge. Htmle: el nuevo estándar básico de la Web. Anuario ThinkEPI, 2011, no 1, p. 261-265. [Online]. Disponible en: https://www.w3.org/standards/webdesign/mobilweb

[10] Claro, Rosendo l. Hernández; Navarro, Deibys Greguas. estándares de diseño web. ciencias de la información, 2010, vol. 41, no 2, p. 69-71.

[11] W3C, Roadmap of Web Applications on Mobile, July 2018. [Online] Disponible en: https://www.w3.org/2018/04/web-roadmaps/mobile/

[12] Cascading Style Sheetsworking group. [Online] Disponible en: https://www.w3.org/Style/CSS/members

[13] Beatty, Patricia; Dick, Scott; Miller, James. Is HTML in a race to the bottom? A large-scale survey and analysis of conformance to W3C standards.IEEE Internet Computing, 2008, vol. 12, no 2.

[14] W3C, Sensors and Local Interactions. January 2018. [Online]. Disponible en: https://www.w3.org/2018/01/web-roadmaps/mobile/sensors.html

[15] W3C, Proximity Sensor - Working Draft, 19 July 2019. [Online]. Disponible en: https://www.w3.org/TR/proximity/

IR