Mi espacio

En los últimos años he visto como desde universidades hasta empresas, pasando por administración pública, han elegido Plone para gestionar sus contenidos y modelar sus servicios a partir de los productos con los que Plone trabaja. Dejando a un lado cuestiones técnicas del core y la filosofía que esta solución fomenta (durante la versión 2.x), los acabados de la interfaz de usuario no eran muy buenos. Evidentemente, he visto acabados muy buenos, sin embargo, la tónica habitual no era esa. Inicialmente pensaba que la forma en la que Plone trabajaba y las herramientas que proporciona dificultaban mucho la implementación de buenos interfaces web. Veía con cierta frecuencia una mala semántica del marcado, los layouts o bien fijos o anchos al 100%, el aumento de las fuentes en la mayoría de los casos destrozaban el layout, etc. Esta fue mi primera impresión sin conocer Plone con mucha profundidad (sigo sin conocerlo todo lo que me gustaría), sin embargo creo que aunque Plone tenga cosas que mejorar con respecto a la forma de trabajar en la interfaz de usuario, se puede hacer cosas bastante aceptables.

Recientemente se ha publicado el sitio web del Ayuntamiento de Lepe. Este proyecto ha sido realizado por la empresa en la que actualmente trabajo y tengo que reconocer el excelente trabajo que mis compañeros han realizado. Evidentemente hay cosas que se pueden mejorar, pero bueno, ahora por fin sé que no era una cuestión de Plone. Hoy por hoy estoy convencido de que se pueden conseguir buenos interfaces de usuario haciendo uso de estándares web y buenas prácticas en accesibilidad web. En esta ocasión se ha comprobado la interfaz de usuario en multitud de agentes de usuario y con distintas configuraciones (versiones, sistemas operativos, etc) y el escalado de la fuente es uno de sus puntos fuertes.

Hace unos días escribía un post en el que comentaba que se había liberado Stractistics, un plugin para obtener reportes de actividad en TRAC. Pues bien, intenté instalarlo en el servidor donde está el gestor de proyectos de Opina y me encontré con algunos problemas. Todo se debía a las versiones instaladas de SQLite y PySQLite. Aproveché para actualizar a SQLite 3.5.6 y PySQLite 2.4.1. Tras compilar y migrar las bases de datos que usan los proyectos de TRAC, pude instalar Stractistics sin problemas.

Ahora el gestor de proyectos de Opina cuenta con este plugin que irá midiendo la actividad del proyecto.

Recientemente la legislación española ha revisado su marco legal en cuanto a servicios de la sociedad de la información, comercio electrónico, acceso universal de las personas con discapacidad, y otro montón de buenos propósitos. Con la documentación sobre mi mesa y tras varias consultas legales llego a unas conclusiones que expongo a continuación.

Para los que no estamos acostumbrados a trabajar con leyes, normas o reales decretos ayuda bastante que alguien nos guíe y nos diga exactamente en que se resume esto de la accesibilidad web desde un punto de vista legal. Para ello, lo más conveniente es que accedáis a la norma UNE 139803:2004 donde se explica que usan como referencia las pautas de accesibilidad publicadas por el grupo de trabajo WCAG-WG del W3C y se indica el objeto y campo de aplicación de dicha norma. Sin avanzar más, comentar los siguientes puntos:

1. La norma trabaja sobre unas pautas cuya última revisión se realizó el 5 de mayo de 1999. Sólo tenéis que hacer un esfuerzo de imaginación y recordar qué era y cómo era la web, y por extesión internet, en aquella época y compararlo con la actualidad.
2. La norma aplica a cualquier contenido disponible en redes informáticas con especial énfasis en los contenidos web que son accedidos mediante aplicaciones de usuario. Si no me equivoco, entiendo que aquí entran tanto aplicaciones web (RIA o no) como sitio web con contenidos de carácter informativo, divulgativo, docente, institucional, etc. Es decir, lo que muchos denominados sitios web (portales). Por ser más explícito, esta norma debe aplicarse tanto a una aplicación RIA para un sistema GIS como al sitio web de una consejería.

Teniendo en cuenta que la ley dice lo que dice, os expongo algunas situaciones que esto viendo. Si un organismo público licita la creación de un sitio web me parece estupendo que se indique de forma clara que es de obligado cumplimiento la legislación española en cuanto a accesibilidad se refiere. En el caso de un sitio web, ¿Qué implicaciones tiene esto para la empresa adjudicataria? Básicamente, el que exista una ley que oblige a que se cumplan una serie de pautas puede garantizar un cierto nivel de accesibilidad web. En este sentido, la empresa si tiene experiencia y profesionales correctamente formandos en la materia, no tendrá el más mínimo problema. Hoy por hoy, los estándares web y unas buenas prácticas en el desarrollo web, garantizan niveles optimos de accesibilidad. Esta claro que el hecho de que existan leyes al respecto es un paso, pero, ¿Es el paso correcto?. Algunas de las situaciones que he vivido:

1. Si la página valida según no sé qué herramienta mi sitio web es accesible. Hay que recordar que los validadores sólo son una herramienta de ayuda, pero luego hay mucho trabajo por hacer.
2. Antes de poner el sitio web en producción hay más preocupación porque se vea bien el logotipo del W3C que de comprobar que el lenguaje de marcado modela una semantica correcta, que se han realizado pruebas de renderizado en los navegadores descritos en el catálogo de requisitos no funcionales, el peso de las página, etc.
3. Como hay una ley y ésta aplica a todo contenido web, incluye también a aplicaciones del tipo visores GIS, herramientas colaborativas, webmail, calendarios, etc. Y es aquí donde desde mi punto de vista se comete el principal error. Por regla general el conjunto de usuarios para el que se desarrolla un sitio web es mucho más amplio y variado que el conjunto de usuarios que van a usar por ejemplo una herramienta corporativa como por ejemplo un webmail o un calendario corporativo. Entiendo además que los requisitos que se pueden establecer para ambos tipos de contenidos web pudieran ser los mismos, sin embargo, determinados requisitos en el caso de las aplicaciones web pueden ayudar a mejorar mucho las experiencias de usuario y la usabilidad de las mismas. Ahora bien, ¿Qué pasa si intentamos aplicar la legislación vigente al desarrollo de un visor GIS o un calendario corporativo? Está claro que técnicamente se puede definir alternativas que faciliten el acceso a la información, pero en el caso de las aplicaciones web eso tiene un coste importante. Sin embargo, en los sitio web no tiene por qué.
4. Tengo la sensación de que la accesibilidad web se percibe como una propiedad de los proyectos web, es decir, una propiedad total que establece si algo es o no es accesible. Desde siempre he creído que resulta complejo medir el grado de accesibilidad y que es algo en lo que siempre se puede seguir trabajando y mejorando. Es como medir la calidad del software, es cierto que existen unos indicadores para medir ciertas cuestiones, sin embargo, sólo son eso, indicadores. En la accesibilidad eso indicadores podrían ser la semántica del marcado (eliminando capa de representación y comportamiento), peso de la página, compatibilidad con agentes de usuarios, etc.
5. Después de meses desarrollando una aplicación RIA donde se han solicitado comportamientos de arrastrar y soltar, actualización de contenidos en tiempo real, etc. te dicen, “todo esto funcionará si desactivamos javascript, ¿no?” “Y se podrá usar desde un dispositivo móvil, ¿no?” Es importantísimo fijar este tipo de requisitos desde el principio, y cuando surjan esas cuestiones hacer ver que su implementación requiere usar otro de soluciones más propias de las aplicaciones web tradicionales y que eso conlleva un coste importante. Sino, que les pregunten a los de Google, cuando les ha costrado hacer la versión dual de GMail. Y si me apuras, una tercera versión para móviles.

A continuación algunas cuestiones que considero interesantes para debatir:

1. Si una administración publica necesita hacer un visor GIS, ¿Qué tiene que hacer para cumplir la ley en vigor? ¿Cómo se proporciona alternativa a un visor de esas características? Y en caso de hacerlo, ¿A qué coste?
2. Entiendo que si el W3C WAI distingue entre contenido web y aplicaciones web será porque a ambas cosas, aunque compartan cosas y tengan similutides, no se les pueden aplicar las mismas pautas y buenas prácticas. Copio literalmente de la página del W3C WAI:
   1. WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.
3. Al igual que se pretenden concienciar a la gente de que no todos somos iguales, de que accedemos a la información de formas distintas, de que tenemos necesidades diferentes y de que existe gente que por circunstancias posee una discapacidad (puntual o de por vida) veo también necesario concienciar a las administraciones públicas sobre las implicaciones que tienen las leyes que están desarrollando. Las implicaciones afectan a los tiempo de entrega de los proyectos, a los costes, la calidad de los mismos, etc.
4. Los requisitos técnicos que requiere un sitio web son muy distintos de los que requiere una aplicación web, y máxime si se quieren emplear soluciones que potencien las bondades de los agentes de usuario modernos.

Creo que son cuestiones importantes y que mucho tienen que ver con los resultados que nos encontramos, algunos muy buenos y otros muy malos. Yo entiendo que para la administración pública sea difícil redactar un pliego de prescripciones técnicas donde todas estas cuestiones queden recogidas, pero también hay que pensar que igual de difícil es para aquellas empresas que quieren preprarar una buena oferta y que en muchos casos se ven abocados a cruzar los dedos y esperar a ver como se desarrolla el proyecto.

Ayer por la tarde se publicó la versión 0.1.0beta de STractistics, un plugin para TRAC. El plugin ha sido desarrollado por gente del área de desarrollo de la empresa en la que trabajo, GMV. El objetivo principal del plugin es obtener una representación gráfica de la actividad de un proyecto en TRAC. Inicialmente, y por ser su primera versión, únicamente tiene disponibles tres reportes de carácter general:

1. Actividad en el repositorio (commits por semana)
2. Actividad en los tickets (en los 30 últimos días, cuántos tickets son nuevos, están cerrados y abiertos).
3. Actividad en las páginas wiki (modificaciones por semana)

En nuestros objetivos está el ir aumentando el número y tipo de reportes. A continuación una captura de pantalla del plugin:

Aunque aun queda algo de tiempo, el comité organizador ya tiene gran parte de los deberes hechos. Recientemente se inauguraba el sitio web de las jornadas. El año pasado asistí a las que se celebraron en Zaragoza y eché en falta gente que contase experiencias en proyectos reales y una mayor presencia de planteamientos y soluciones abiertas. Para conocer las soluciones comerciales ya tengo los eventos que las propias empresas organizan.

Personalmente lo que me atre es que se cuente cómo se acompaña a un cliente que no tiene ninguna implantación de servicios web, no conoce REST, no conoce qué es un bus empresarial, a que poco a poco su perspectiva cambie. Evidentemente, hay otras muchas más cosas que me atraen de unas jornadas de estas características. Y máxime cuando este año se celebran en Sevilla y tantos nombres de los distinto comités, son conocidos míos, y otros tantos, amigos.

Poco a poco las cosas van avanzando. Mi gran amigo Paulo me ha sorprendido esta mañana con dos propuestas de logotipos para dos proyectos. Una de ellas es para Opina y la otra, por ahora me lo reservo. Me gusta. Es simple, limpio y da mucho juego. A ver si dentro de poco puedo yo sorprenderlo a él diciendo que tenemos lista una beta de la versión 2.