eMartos

El sábado 1 de mayo estuve con @spesgmd en el Encuentro Gnome Sevilla, organizado por Yaco y Emergya. No había escrito nada hasta ahora porque he tenido una semana de perros, y sábado y domingo los he usado para un merecido descanso. Hecho el inciso de justificación, prosigo.

Las oficinas de Yaco son realmente atractivas; creo que no hay dos paredes del mismo color, casi todos los espacios son abiertos y tienen una mesa de billar. Como llegamos para la charla de las 12:30 sobre accesibilidad, y había gente desde primera hora, nos tuvimos que conformar con participar desde los laterales del aula, pero con las ventanas abiertas se escuchaba bien.

Gracias a los comentarios de los compañeros que participaron, me puse al día en lo que a accesibilidad open source se refiere. Se habló de aplicaciones y utilidades como at-spi2 (hook entre los lectores de pantalla y el sistema operativo), Orca (el lector de pantalla OS por excelencia), Evince (un lector PDF accesible en cuanto a menús y controles, pero no muy maduro en lo que a los propios documentos se refiere) un lector de PDF que no parece estar muy maduro (creo que se llama Lince, pero no he encontrado referencias al respecto), OCR Reader (un lector OCR para ciegos) y Caribou (teclado virtual para personas con movilidad reducidas). También se trató la diferencia entre Gnome y KDE en lo que a accesibilidad se refiere (al fondo, en una pizarra, se leía: "The world is blue like KDE"), aunque desde mi humilde punto de vista, sería interesante coordinar desarrollos comunes para que la opción de usar un escritorio, para personas con problemas de accesibilidad, fuera tan libre como para cualquiera. Por último, se expusieron las necesidades actuales, que se pueden resumir en lectores de braille, software de reconocimiento de voz y comunicadores pictográficos, así como en centros interesados tanto en consumir estas soluciones como en asesorarlas para que sean realmente útiles (ONCE, centros de parálisis cerebral, etc.).

La segunda charla versaba sobre CouchDB y vino de la mano de Rodrigo Moya. Se trata de un servidor de documentos almacenados en base de datos que son servidos mediante REST. Forma parte de los sistemas NoSQL, es decir, bases de datos no relacionales. Entre sus características más notables está el hecho de ser distribuido, con soporte para sincronización entre distintas instancias, y de poseer un sistema de detección y gestión de conflictos, lo que lo convierte en un sistema ciertamente robusto y fiable.

Los documentos se almacenan en formato JSON. Soportan tipos de datos básicos, listas y estructuras, objetos, estructuras libres y ficheros adjuntos. Cada documento tiene un identificador único (_id) y un número de revisión (_rev).

Una base de datos contiene una colección de documentos, y su número no está restringido, así como tampoco su tamaño ni el número de documentos que puede almacenar. CouchDB está escrito en Erlang, lo que, al parecer, garantiza que los datos no se corromperán aunque el sistema se caiga.

Las consultas se canalizan a través de las vistas, que se escriben en JavaScript y devuelven resultados formateados. Se definen dentro de un documento de la base de datos con un nombre especial y conteniendo una función en JavaScript. Como las vistas tradicionales de cualquier SGBD, cachean los resultados.

Otro aspecto interesante, y en el que se basaba realmente la charla, es la sincronización, que permite replicar datos entre cuantas instancias se desee de manera bidireccional. Se copian sólo los documentos y campos que han sido modificados, lo que según Rodrigo es muy eficiente, pero que un compañero discutió arguyendo haber realizado pruebas de rendimiento con CouchDB, las cuales demostraban un descenso del mismo con un volumen alto de documentos. El algoritmo de generación de revisiones es idéntico en todas las instancias, lo que asegura la detección de las últimas versiones reales y permite detectar y gestionar los conflictos, actualmente de manera manual, y en el futuro, esperan, de forma automática.

CouchDB se integra con C (a través de la librería couchdb-glib, con bindings en desarrollo para Mono, Vala y Python), Python (a través de python-couchdb) y Java (a través de jcouchdb).

Se quedó en el tintero una explicación más detallada del descubrimiento de instancias y publicación de servicios a través de Avahi.

La última parte de la charla versó acerca de DesktopCouch, una integración de CouchDB en aplicaciones de escritorio para la replicación y sincronización automática de información entre ordenadores. Forma parte de la integración de Ubuntu One en el escritorio. La idea central consiste en mantener sincronizados nuestros contactos, notas y marcadores (y en el futuro, otro tipo de datos) con servidores distribuidos para acceder a nuestra información desde cualquier lugar y con nuestras aplicaciones favoritas. La integración ya es un hecho con Tomboy, Convoy y Tomdroid para las notas; Evolution, Akonadi y Thunderbird para los contactos; y Firefox para los marcadores.

Claro que no todo el trabajo está hecho. Una de los problemas que están intentando resolver es la estandarización de formatos, algo imprescindible para que las aplicaciones puedan trabajar entre sí, y que tiene mucha relación con la web semántica. Uno de los objetivos más ambiciosos es que aplicaciones en principio incompatibles, como las de KDE y Gnome, puedan por fin entenderse.

A corto plazo, la intención es integrar las tareas en Evolution y sincronizar la configuración de Gsettings, lo que significaría que puedes sentarte frente a un ordenador de un desconocido y tener tu configuración personal replicada. A medio plazo, se proponen integrar calendario y tareas en Evolution y Akonadi, así como los metadatos de Tracker. A largo plazo, que todos nuestros datos estén replicados en nuestras máquinas y dispositivos móviles, y por qué no, dominar el mundo.

Mi impresión de las dos charlas, además de mi profundo desconocimiento de los temas que se trataron, fue que el panorama open source se está consolidando en nuestra región, pero son pocas las empresas que apuestan realmente por esta filosofía. Es de esperar que este movimiento acabe cuajando y se convierta en lo habitual.

Actualización 11/05/2010. Agradezco a @spesgmd que me haya sacado de la confusión entre Lince (que no existe) y Evince.

Hoy, en la recta final de los desarrollos evolutivos de la web de las Jornadas Salud Investiga desde Fundación Progreso y Salud, he intentado aproximar las necesidades del cliente al problema de la accesibilidad. Se trata de un proyecto de carácter interno y tenemos un mayor control sobre las decisiones técnicas, o dicho de otro modo, tenemos un control más granular.

La web parte de un antiguo desarrollo manual en PHP, que se ha ido actualizando, año tras año, a nivel de contenidos y estructura. A causa de la escasez de tiempo y de la pobre difusión de los beneficios de usar frameworks de desarrollo, o mejor aún, de los gestores de contenido, el proceso de modificación es todavía manual. Pero dentro de los recursos que se disponen, siempre se puede hacer algo más por los usuarios sin un coste adicional en tiempo ni en esfuerzo.

Pasando a lo concreto, los menús de la aplicación cargaban el contenido en un iframe central que, para colmo, ni siquiera tenía dimensionada la altura, por lo que la página mostraba dos barras de desplazamiento: la del navegador y la del iframe. Este aspecto no era del agrado de los responsables de la web, y por supuesto, tampoco cumplía con unos mínimos criterios de accesibilidad, seguridad y estética. Además, un JavaScript intrusivo se dedicaba a desplegar los submenús en función de la opción seleccionada.

En vista de la situación, he propuesto los siguientes cambios de estructura:

1. El iframe desaparece, salvo en tres casos especiales en los que se incrustan formularios alojados en otro servidor.
2. En lugar del iframe, un dispatcher implementado en PHP decide, en función de un parámetro HTTP GET, qué contenido debe cargar con un require().
3. El JavaScript desaparece en favor de una comprobación, en cada elemento principal de menú, para determinar si dicho elemento o alguno de sus hijos coincide con la opción seleccionada, en cuyo caso se despliega el submenú. No es la mejor opción porque la verificación es redundante, pero no existe otra alternativa dado que la generación del menú no es dinámica, sino totalmente estática.

Sinceramente, hay otros aspectos mejorables en cuanto a accesibilidad, pero con estos cambios mínimos, que de paso mejora usabilidad, seguridad y estética del sitio, la navegación no se ve obstaculizada por un método de programación incorrecto.

Todavía nos queda mucho por avanzar hacia una web totalmente accesible y bien construida, pero cada pequeño paso que se da es importante para alcanzar esa meta.

Tras analizar las primeras impresiones sobre el portal, que apenas he empezado a difundir, creo que he acertado en lo esencial. Todos los comentarios han ido en la misma línea: Sencillo, limpio y bien estructurado. Me alegra saberlo porque se trata de la confirmación de un trabajo basado en estándares y en procedimientos bien definidos. En último término, esto es lo que ofrezco a mis clientes, a quienes les gustará saber que lo que adquieren va a tener utilidad y aceptación.

Pero de todos los comentarios que he recibido, hay uno que me ha resultado especialmente alentador. Mi amiga Rocío Muñoz, co-propietaria de Espiral Calipso, una editorial argentina de la que hablaré largo y tendido, me escribe lo siguiente:

Ah, lo que es leeerse, se lee perfectamente, cristalino

No me estoy echando flores, como se comprobará más adelante. Rocío es ciega, lo cual no la ha disuadido de irse a vivir al otro lado del mundo, ni de vivir aventuras en la selva que bien podría haber narrado Rudyard Kipling. Sin embargo, a pesar de su tesón y habilidad en el manejo de los ordenadores, todavía tiene muchas dificultades al navegar por la red. La accesibilidad, por desgracia, se considera un añadido poco necesario a la hora de construir un sitio web, lo que perjudica a millones de usuarios que ven sus posibilidades reducidas a la mínima expresión.

Desde que este portal web era sólo un concepto, la accesibilidad estaba presente como un requisito esencial. Me niego a que una persona con limitaciones visuales o de movilidad se vea obligada a incluir mi portal en una lista negra. Como decía antes, no me estoy echando flores al reproducir el comentario de mi amiga, pero me alegra inmensamente saber que se ha sentido cómoda y ha encontrado la información sin dificultades. Sé que todavía puedo mejorar muchos aspectos que reforzarán estas garantías, pero creo que no es un mal punto de partida.

Oficialmente, la fase de pruebas está terminada. Las validaciones han sido exhaustivas, pero se resumen en los siguientes puntos:

• Conformidad con XHTML Transitional 1.0 y CSS.
• Compatibilidad con cualquier resolución de pantalla (con las limitaciones intrínsecas a las más bajas).
• Compatibilidad con los siguientes navegadores: Google Chrome 5.0 (Linux), Opera 9.64 (Linux), Mozilla Firefox 3.5.8 (Linux), Safari, Internet Explorer 8 y Konqueror 4.3.2.
• Estudio de usabilidad.
• Estudio de accesibilidad.
• SEO.
• Verificación de enlaces rotos.

Esto sólo significa que estoy dedicando un gran esfuerzo a que este portal sea una herramienta cómoda y eficaz, pero en ningún caso perfecta. Por ello, si detecta algún error o cree que podría mejorar algún aspecto, le agradecería que me lo comunicara a través del formulario de contacto.