Archivo de Categoría «Estándares Web»

Normativas y Estándares para el Web: el Objetivo es la Gente

— Accesibilidad, Estándares Web, Gobierno Digital —

Leo en el blog de John Allsopp una reflexión que coincide mucho con comentarios que he escuchado repetidas veces por estos lados. John escribe un post titulado Accessibility is about people, not compliance, o La accesibilidad es acerca de la gente, no del cumplimiento, donde habla sobre el cumplimiento de las normativas y estándares y el objetivo de fondo para hacerlo.

Sucede que desde agosto de este año está vigente en Chile el Decreto Supremo 100 (D100), que establece una serie de normas para los sitios web del Gobierno, fundamentalmente sobre disponibilidad, estándares y accesibilidad básica. Por su carácter normativo, los sitios de Gobierno deben acatar y cumplir la norma, a diferencia de iniciativas anteriores como la Guía Web para los Sitios de Gobierno, que establecía recomendaciones y buenas prácticas.

Lo que me hace notar el post de John Allsopp es que he observado que se enfrenta el tema del D100 como el cumplir con la norma sin entender el alcance de ella. Un ejemplo, y tal vez el más notorio, es el del uso y la validación de HTML y CSS. El D100 indica que se debe utilizar HTML estándar y válido, el objetivo es que exista mejor interoperatividad, separar contenido de presentación, estructurar mejor el contenido. Pero algunos funcionarios, e incluso proveedores, lo perciben como que hay que validar, sin importar la calidad del HTML, porque es lo que pide la ley, por desconocimiento de la naturaleza de lo que se está normando.

Yo no digo que se deba descuidar la validación, pero es importante tener en cuenta que el objetivo es generar sitios de mejor calidad, no sólo aprobar formalmente los estándares. Y eso finalmente significa validar HTML porque se hizo un buen trabajo separando el contenido de la presentación, estructurando el contenido apropiadamente y no porque el objetivo fuera sólo validar.

Resolución de Pantallas: Marzo de 2007

— Estándares Web —

Hay bastante consenso en que la buena práctica es, comúnmente, no diseñar para resoluciones de pantallas específicas. Lo ideal es considerar un rango de entre las más usadas en un momento determinado y procurar que el despliegue del contenido se adapte lo mejor posible a esas condiciones.

La tendencia a la fecha, es que los monitores, o más precisamente, la resolución de los monitores, aumente. Según las estadísticas de thecounter.com, en febrero de este año la resolución más común es 1024×768 píxeles, con un 58%. Le sigue otra resolución mayor,1280×1024 con un 22% y en tercer lugar 800×600 con 13%. La tendencia ha ido en aumento hacia el uso de resoluciones mayores. Veamos los siguientes datos comparando el mes de febrero desde 2005 al 2007:

Febrero de 2007

Resolución Uso (%)
1024×768 53%
1280×1024 22%
800×600 13%

Febrero de 2006

Resolución Uso (%)
1024×768 59%
800×600 20%
1280×1024 12%

Febrero de 2005

Resolución Uso (%)
1024×768 53%
800×600 31%
1280×1024 8%

Claramente la resolución dominante es 1024×768, aunque está cediendo ante la aún mayor 1280×1024. La vieja resolución de 800×600, añorada en los tiempos de 640×480, va en retirada.

Por otro lado, los móviles y dispositivos pequeños como handhelds tienden a utilizar pantallas muy pequeñas, lo que claramente habla en contra de la convergencia entre dispositivos.

De momento, veo que esto me lleva a las siguientes conclusiones:

  • No podemos diseñar un solo sitio para condiciones tan radicalmente diferentes como los dispositivos móviles y las pantallas de notebooks y computadoras de escritorio.
  • No podemos diseñar sitios que se ajusten a sólo una resolución, debemos optimizar para un rango entre los tamaños más comunes y asegurar que los menos usados tengan acceso apropiado a la información.
  • Un sitio debe ser monitoreado permanente para observar las tendencias de uso de resoluciones particulares. No todos los sitios son iguales. El ciclo de evaluación de esta condición no puede pasar de más allá de dos años.
  • Si la tendencia se mantiene, en dos años más, en 2009, la resolución más común debería ser 1280×1024 o algo equivalente.
  • No hay que olvidar los formatos alargados como los de muchos notebooks (escribo esto en un monitor de 1280×800) y tampoco la aparición de monitores de más alta resolución (más puntos por pulgada, dpi), además del tamaño (más sobre esto en High DPI Web Sites y High DPI (Part 2)).

WYSIWYG y Contenido Estructurado

— Contenido, Estándares Web —

Mientras leía el artículo Writing documents with OpenOffice.org Writer me encontré con la siguiente frase:

With WYSIWIG word processors people get interested in the final layout of the document too soon

Con los procesadores de texto WYSIWYG la gente se interesa en la diagramación final del documento demasiado pronto (nota: en el original WYSIWYG aparece mal escrito)

Me hizo pensar inmediatamente en dos cosas:

  • Es cierto que las interfaces visuales facilitan el despreocuparse por la estructura del contenido y permiten que nos centremos más en el resultado visual, la presentación. Esto ayuda a que la edición de contenido sea más simple y no requiera de demasiados conocimientos técnicos. Aquí estoy pensando en web más que en procesadores de texto, pero se aplica igual.
  • También es cierto que el contenido debería tener una estructura semántica que lo sostenga y lo defina.

El problema está en: ¿hasta qué punto las interfaces de usuarios deberían ser tan simples que permitan que el resultado se empobrezca? Un contenido no estructurado, como el que podemos ver en gran parte del web, tiene menor calidad que uno estructurado, en que cada una de sus partes está identificada según su función o significado. Un título está identificado como tal, lo mismo una lista o una tabla, por ejemplo.

Hemos generado interfaces fáciles para permitir la generación de contenido empobrecido.

¿Pero cómo debería ser una interfaz que promueva la creación de contenido estructurado? ¿Debería estar llena de campos y definiciones técnicas complejas? ¿Debería estar toda la responsabilidad en el usuario?

Claramente no estoy promoviendo un esquema elitista para la creación de contenido sólo para iniciados. Mi punto es: es necesario crear interfaces que facilien la creación de contenido estructurado y que no agreguen una carga adicional al proceso de creación.

¿Qué tal si un editor de contenido tradicional reconociera ciertos aspectos que solemos utilizar visualmente como títulos y ofreciera automáticamente formas estructurales para ello? Se podría crear mediante inteligencia artificial.

Por ejemplo, si marco un texto con negrita y en un tamaño mayor que el resto, debería ser un indicio de que estoy escribiendo un título. Ya muchos editores de texto reconocen automáticamente que si agrego números al inicio de un párrafo estoy creando una lista numerada. Lo mismo con el uso de guiones para crear listas no numeradas.

¿No se podría explotar el modelo más allá y enriquecer el contenido con una estructura apropiada?