Serakesi

El otro d?a escrib?a sobre la accesibilidad y las validaciones Web. Hoy escribir?, como est?n cambiando las cosas y “por fin” adaptando la documentaci?n a los nuevos tiempos.

Hablemos de las pautas de accesibilidad. Parece ser que el mismo d?a 23 de noviembre, cuando dec?a que estas eran caducas, la W3C lanzaba la nueva versi?n WCAG 2.0. Esto define la accesibilidad al contenido Web y las t?cnicas del HTML. La nueva versi?n, parece ser, que es m?s accesible a una mayor parte de usuarios, incluyendo personas con discapacidades y a los mayores. Esto se pretende conseguir incluyendo una amplia variedad de tecnolog?a assistive.

La nueva versi?n, nos define, que pautas fallaban en la anterior definici?n, como tambi?n t?cnicas que nos har? de la accesibilidad m?s f?cil de entender y con un margen de beneficio accesible m?s f?cil de construir.

Parece que podemos interpretar estas nuevas definiciones como algo positivo, mientras las utilicemos como referencia y como soporte para ayudarnos a crear entornos accesibles y no seamos inflexibles, aceptando ?nicamente una interpretaci?n de las pautas, ya que solo son eso, pautas.
Fuente de informaci?n:http://www.zeldman.com/

En un ejercicio muy interesante: dos personas evaluaron una web determinada.

La primera persona era un invidente que usaba sus herramientas de navegación habitual. La segunda era un consultor de accesibilidad. El objetivo era conocer los problemas de accesibilidad para invidentes que la web planteaba.

Los resultados del ejercicio eran sorprendentes: las listas de problemas no coincid?an en absoluto. Mientras que el consultor hab?a encontrado problemas de validaci?n m?s o menos esperables (6 errores de prioridad 1 y 8 de prioridad 2), el invidente tuvo una experiencia muy positiva con la web, aunque encontró algunos problemas que el consultor no había siquiera notado.

Del ejercicio, podemos extraer dos conclusiones:

• la mayoría de "expertos" en accesibilidad se limitan a restregarte en la cara un montón de guías y pautas, pero no tienen mucho conocimiento de los medios ni de los usuarios con discapacidades.
• No hay diseño accesible a discapacitados sin discapacitados. Deben ser parte de nuestro grupo de usuarios si de verdad queremos hacer diseños adaptados a sus circunstancias.

Enlace de referencia: http://www.guuui.com/issues/01_04.php

El tema de la accesibilidad esté de moda, y se est? enfocando verdaderamente mal. La actitud generalizada es integrista: interpretaciones inflexibles, sesgadas y caducas. Inflexibles: porque solo aceptan una interpretación de las pautas; incluso las dejan de llamar pautas y las elevan a la categoría de "normas".

Sesgadas: porque no tienen en cuenta la verdadera experiencia de uso de los discapacitados. De todos los utilizamos las pautas del W3C ¿cuántos hemos testeado alguna vez con discapacitados? Se construyen Webs que validan al 100%, pero luego resultan ser verdaderos fiascos de usabilidad y adaptaci?n a discapacitados.

Caducas: porque las pautas son originariamente de 1999. Ceñirse a ellas al 100% supone hacer Webs de esa época. Y, ¿cuántos hablaban de accesibilidad en aquel entonces?

Las validaciones se realizan para intentar realizar Webs que faciliten las cosas a los usuarios. Este es el fin verdadero, pero el medio se convierte en el fin y el fin es validar.

Los que intentan acercarse a la accesibilidad con esa actitud, no se pueden considerar profesionales.

Nuestro fin debe ser asegurar una experiencia de uso positiva, basándonos en el conocimiento de nuestros usuarios y no únicamente en los conocimientos técnicos.

En los últimos meses se han visto muchos mensajes, artículos y posts sobre temas de accesibilidad. Pero nadie ha hablado de testear con discapacitados. Sin embargo, todos queremos el logo de validación W3C en nuestras Webs.

A ver, ¿por donde empiezo? He leído mucho sobre este tema y encontrado cantidad de artículos a favor y en contra de esta nueva forma de ver la Web. Hay algunos que dicen que es el futuro, que es una maravilla y revolucionará Internet. Otros se muestran escépticos e irritados ante el asunto. Ya que creen que es una moda publicitaria, destinada a vender productos ya existentes. Yo personalmente me decanto por el segundo grupo, ya que las "tecnologías" que se utilizan ya existían, aunque nunca se había hablado de las posibilidades que daban. Pero, ¿Qué es la Web 2.0? El término Web 2.0, no es un concepto real, no tiene significado. Se utiliza para definir un conjunto de tecnologías o formas de comunicación, que esta cambiando y evolucionando Internet. Para entender este concepto, solo hay que pensar en Google, Flickr, Wikipedia, RRS, Blogs, Ajax, etc, todo junto. Cada vez mas, todas las aplicaciones, el software tal y como lo conocemos, deja de existir como producto y pasa a ser un servicio. Tanto los modelos de negocio como los de desarrollo deben adaptarse a una realidad en que los ciclos pasan a ser un continuo. ¿Cuántos servicios Web, como Gmail, Google Maps, Flickr, etc, se mantienen en un estado beta? Algo impensable en aplicaciones vendidas en tiendas. En muchos casos los mismos usuarios pasan a ser co-desarrolladores, sobre todo en proyectos open-source. La Web también adopta, cada vez con más fuerza, est?ndares sencillos como la sindicación RSS o compatibilidad con XML. Siguiendo estos estándares, Internet deja de estar ligado únicamente a un PC y amplia sus horizontes a otros dispositivos como PDAs, móviles, TV, reproductores de música, etc. Dado que la barrera del acceso es cada vez menor, las aplicaciones y los servicios de la Web 2.0 deberían estar preparadas para funcionar, con independencia de la plataforma utilizada. También existe una mayor experiencia por parte del usuario. En este momento, de lo que mas se habla, es de Ajax, ya que es capaz de crear experiencias interactivas e instantáneas para los usuarios. Como se puede ver, la Web 2.0, engloba un conjunto de perspectivas de desarrollo, una forma de pensar distinta frente a Internet.

La programaci?n extrema (eXtreme Programming) o XP, es una disciplina de desarrollo basada en la simplicidad. XP aparece para, que equipos peque?os que necesitan desarrollar software r?pidamente, puedan realizarlo en un ambiente donde los requisitos cambian r?pidamente.

La metodolog?a de Desarrollo de Software, siempre necesitar? ser modificada para adaptarla a los requisitos particulares del cliente y de las circunstancias. XP no es ninguna excepci?n.

Hay doce pr?cticas para aplicar XP:El proceso de planteamiento o juego de la planificaci?n

Permite que el XP cliente defina el valor de negocio y las caracter?sticas deseadas, y utiliza las valoraciones de coste proporcionadas por los programadores, para elegir si necesita ser desarrollado o dejar aparcado. Con este proceso es f?cil llevar el proyecto a ?buen puerto?.

Entregas peque?as

La idea es producir r?pidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad, pero constituyan un resultado de valor para el negocio.

Met?fora

Una met?fora, es una historia compartida que describe c?mo deber?a funcionar el sistema. El sistema es definido por una met?fora o un conjunto de met?foras compartidas por el cliente y el equipo de desarrollo. La met?fora consiste en formar un conjunto de nombres que act?en como vocabulario para hablar sobre el dominio del problema.

Dise?o simple

Se debe dise?ar la soluci?n m?s simple que puede funcionar y ser implementada en un momento determinado del proyecto. La complejidad innecesaria y el c?digo extra debe ser removido inmediatamente.

Pruebas

La producci?n de c?digo est? dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el c?digo y son ejecutadas constantemente ante cada modificaci?n del sistema. En este desarrollo y pruebas constantes, la automatizaci?n para apoyar esta actividad es crucial.

Refactorizaci?n (Refactoring)

La refactorizaci?n es una actividad constante de reestructuraci?n del c?digo con el fin de remover duplicaci?n de c?digo, mejorar legibilidad, simplificarlo y hacerlo m?s flexible para facilitar los posteriores cambios. Para mantener un dise?o apropiado, es necesario realizar actividades de cuidado continuo durante el ciclo de vida del proyecto.

Programaci?n en parejas

Toda la producci?n de c?digo debe realizarse en parejas de programadores. Muchos errores son detectados conforme son introducidos y la tasa de errores del producto final son mucho menores, los dise?os son mejores y el tama?o del c?digo menor, los problemas de programaci?n se resuelven m?s r?pido, se transfieren los conocimientos de programaci?n entre los miembros del equipo, varias personas entienden las diferentes partes del sistema, mejora el flujo de informaci?n y la din?mica del equipo.

Propiedad colectiva

Cualquier programador puede cambiar cualquier parte del c?digo en cualquier momento. Esta pr?ctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la vez que alg?n programador sea imprescindible para realizar cambios en alguna porci?n de c?digo.

Integraci?n contin?a

Cada pieza de c?digo es integrada en el sistema una vez que est? lista. As?, el sistema puede llegar a ser integrado y construido varias veces en un mismo d?a. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo c?digo sea incorporado definitivamente. La integraci?n continua a menudo reduce la fragmentaci?n de los esfuerzos de los desarrolladores por falta de comunicaci?n sobre lo que puede ser reutilizado o compartido. Esto es esencial para un proyecto controlado.

40 horas por semana

Se debe trabajar un m?ximo de 40 horas por semana. No se trabajo horas extras en dos semanas seguidas. Si esto ocurre, probablemente est? ocurriendo un problema que debe corregirse. El trabajo extra desmotiva el equipo. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificaci?n para cambiar el ?mbito del proyecto o la fecha de entrega.

Cliente in-situ

El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte del ?xito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportar? mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. Algunas recomendaciones propuestas para dicha situaci?n son las siguientes: intentar conseguir un representante que pueda estar siempre disponible y que act?e de interlocutor del cliente, contar con el cliente al menos en las reuniones de planificaci?n, establecer visitaqs frecuentes de los programadores al cliente para validar el sistema, anticiparse a los problemas aosociados estableciendo llamadas telef?nicas frecuentes y conferencias, reforzando el compromiso de trabajo en equipo.

Est?ndares de programaci?n

Es indispensable que se sigan ciertos est?ndares de programaci?n. Estos mantienen el c?digo legible para los miembros del equipo, facilitando los cambios.

Todas estas pr?cticas, se refuerzan entre s?.

Fuente de informaci?n

Cada vez encuentro mayor informaci?n sobre esta nueva forma de programar. La verdad, que con el tiempo, uno se da cuenta de lo que puede llegar a enganchar Ruby On Rails. Si todav?a no lo hab?is visto, echarle un vistazo. A nadie le amargar?a acostumbrarse a trabajar con un Framework que hace que entiendas lo que es XTreme Programing: resultados desde las primeras l?neas de c?digo. Ruby fue creado en 1993 por un japon?s llamado Yukihiro Matsumoto, y como bien dijo: Ruby es la combinaci?n de la elegancia conceptual de SmallTalk, la facilidad de uso y aprendizaje de Python, y el pragmatismo de Perl. Es capaz de realizar en un par de l?neas, tareas, que otros lenguajes necesitar?an el triple de c?digo Este lenguaje pas? desapercibido para el mundo occidental, hasta que alguien se percato de sus ventajas a principios de los a?os 90, y se publicaron varios libros. Pero su m?xima explosi?n fue cuando apareci? Rails, un Framework creado por David Heinemeier Hansson. Su fusi?n se denomin? Ruby On Rails. Ruby On Rails, es algo m?s que un t?rmino de moda, ha puesto en el mapa, t?rminos como: Patr?n MVC, Programaci?n ?gil, Convenci?n sobre configuraci?n(no quiero decir con esto que sea la primera vez que se utilizan, m?rese struts, etc.) adem?s de voltear los ojos del mundo a un lenguaje de programaci?n que casi nadie conoc?a. Hay un video (50MB, 10 min.), que demuestra como en pocos minutos, poco c?digo y mucha virguer?a, se puede construir un rudimentario blog. Una excelente introducci?n a Rails que seguramente hace despertar el gusanillo a m?s de uno. A mi personalmente me tienta, sobre todo la capa de abstracci?n que han hecho para gestionar la bases de datos. Como sab?is, ?ltimamente tambi?n se est? hablando mucho de AJAX, en art?culos anteriores (AJAX, AJAX, Segunda parte) explicaba con detalle las ventajas de esta metodolog?a. Pues bien, Rails tambi?n permite el uso de AJAX a trav?s de Ruby. Adem?s consigue convertir esta tarea en algo muy sencillo.Bueno, ya veremos como va evolucionando esta nueva tecnolog?a y si podr? hacer frente a lo existente hoy d?a como PHP5 y JAVA.

Vamos a profundizar un poco m?s en esta tecnolog?a y comprender porque es tan interesante.
AJAX es algo como: Asynchronous JavaScript + XML. Como su nombre bien dice, la principal virtud de AJAX est? en la potencia que se le puede extraer al trabajo as?ncrono de peticiones al servidor. Hasta ahora solo hemos trabajado con un modelo de interacci?n sincr?nica basada en clic-petici?n-presentaci?n. Con AJAX la interacci?n pasa a ser as?ncrona. Cada vez que se hace clic no necesariamente se establece una conexi?n con el servidor.

AJAX hace de intermediario entre el servidor y el usuario, anticipando peticiones de datos al servidor, de modo que cuando el usuario hace un clic determinado,AJAX ya tiene listos esos datos y los muestra directamente, sin tener que volver a hacer una nueva petici?n.

En ciertos procesos se muestran en la p?gina sin retardo alguno, y mientras el usuario miraba unos datos en la pantalla, AJAX le estaba preparando los siguientes que iba a necesitar.

El siguiente gr?fico explica la diferencia de funcionamiento (sincr?nica vs. as?ncrona) respecto del modelo tradicional comparado con AJAX:

Un buen ejemplo de una aplicaci?n realizada en AJAX, ser?a Gmail. Si he entendido bien el mecanismo de funcionamiento as?ncrono de AJAX, cuando leemos el correo en Gmail y abrimos un mensaje, s?lo se nos muestra el ?ltimo mensaje recibido del emisor. Mientras leemos ese mensaje Gmail va cargando el resto de mensajes de esa conversaci?n, de forma que cuando pulsamos en la opci?n de Expandir los mensajes, nos muestra inmediatamente los siguientes y que la url no var?a.