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?

Guías de Estilo en Castellano

Contenido

Voy directo al grano: ¿conocen buenas guías de estilo para sitios web en castellano? Me refiero a la documentación de la estructura de un sitio, de sus plantillas, hojas de estilo, detalles de diseño, paletas de color o incluso estilos de escritura y comunicación. Hay ejemplos muy interesantes en inglés, pero no conozco guías de estilo en castellano.

En otros idiomas hay muchos ejemplos interesantes, algunos aparecen listados en el sitio de Molly Holzschlag, otros los he ido recolectando:

Si conoces alguna guía de estilo interesante en castellano, o has creado alguna que sea accesible públicamente, por favor pon el vínculo en los comentarios. Gracias.

Registro de Clics y Comportamiento de los Usuarios

Experiencia de Usuario, Métricas

Desde hace un tiempo he estado evaluando y considerando usar herramientas o servicios de registro de clics o click log para medir el comportamiento de los usuarios en algunos sitios. El registro de los clics es un dato interesante para determinar dónde efectivamente los usuarios están pinchando. Por ejemplo, una página puede contener varios vínculos a otra página. El registro estándar del servidor almacenará la página de origen y la de destino, pero no dónde se hizo clic dentro de la página. Aquí es donde el registro de clics puede entregar información complementaria para medir la visibilidad de los elementos interactivos, preferencias de los usuarios, jerarquía del contenido, claridad de las etiquetas, etc.

El registro de clics funciona almacenando la posición dentro de la página (una coordenada) donde un usuario hace clic con el mouse. Esto se realiza mediante una combinación de JavaScript para detectar la posición y tecnologías de servidor para registrar la información en una base de datos. La ventaja de capturar este tipo de información es que basta con agragar un par de líneas de JavaScript para comenzar a acumular datos. Sin duda los costos son bajísimos, porque no se necesita reclutar participantes para realizar un estudio.

Actualmente existen varios servicios y herramientas que realizan la tarea y generan mapas visuales o heatmaps realmente interesantes. Algunos de ellos son Crazzy Egg, MapSurfaceClickTracks. Sin embargo, este tipo de medición tiene algunas limitaciones técnicas importantes:

  • El diseño de las páginas debe ser fijo, estático. De este modo la posición de los clics será estable. En un diseño elástico un vínculo cambiará de ubicación dependiendo del ancho de la ventana del navegador y hará imposible un registro estable.
  • Es posible que diferentes navegadores dibujen las páginas con algunas diferencias en las posiciones, lo que afectará la precisión de la medición. Por ejemplo, sabemos que una misma página en Explorer y Firefox no siempre se verá igual.
  • Si un usuario aumenta el tamaño del texto, alterará las posiciones de todos los elementos. Esto generará registros incorrectos.
  • Las mediciones se realizan usando JavaScript, pero todos sabemos que las diferencias de implementación entre navegadores pueden provocar inexactitudes. De todos modos, este factor es normalmente considerado por las herramientas.
  • Algunas herramientas de medición sólo registran los vínculos pinchados y no cada clic dentro de la página. Esto es relevante, porque si registramos los clics en zonas no vinculadas, podremos detectar por ejemplo, qué cosas los usuarios han creído que son interactivas cuando en realidad no lo son.

En definitiva, un estudio que busque un mínimo de precisión en los datos registrados deberá realizarse en un ambiente controlado, es decir, en un laboratorio, con unprotocolo definido: un navegador determinado, una configuración de pantalla concreta y un tamaño de ventana fijo. De este modo se obtendrá información confiable, pero se perderá la simplicidad y economía de este tipo de registros. Bueno, la vida no es simple.

Billetes Táctiles

Accesibilidad

Desde el jueves 24 de Agosto el Banco Central de Chile ha puesto en circulación billetes con marcas táctiles que facilitan su identificación para usuarios con discapacidad visual. Estos billetes reemplazarán gradualmente a los que se encuentran en circulación. De este modo, será más fácil para los ciegos reconocer los diferentes billetes y su denominación, a la vez que se introduce una nueva medida que dificulta la falsificación.

El Banco publicó una nota de prensa (PDF, 2.94Mb) e información detallada en su sitio web.

Este tipo de medidas integradoras son las que deberíamos ver con más frecuencia. Bien por el Banco Central.

Decreto 100: Nueva Normativa del Gobierno de Chile para el Desarrollo de Sitios Web Gubernamentales

Gobierno Digital

Me entero por Juan Carlos Camus, de que la tan esperada Norma Técnica para el Desarrollo de Sitios Web de los Órganos de la Administración del Estado (PDF, 36Kb) finalmente fue aprobada. Se trata de una iniciativa que comenzó por el 2002, que busca establecer pautas mínimas para el correcto desarrollo de sitios web gubernamentales.

Uno de los primeros pasos en ese sentido fue la Guía para el Desarrollo de Sitios Web, que si bien no es normativa, fijó una serie de pautas para los sitios estatales y tuvo un importante impacto tanto por el precendente que marcó, como para servir de orientación y educación para muchos profesionales. En esa ocasión me tocó colaborar de cerca, el esfuerzo fue grande y muy voluntarioso por parte de todos quienes participaron. La Guía Web contribuyó a establecer nuevas pautas para la industria local no sólo a nivel de gobierno, sino también para el sector privado. En gran medida los avances en términos deusabilidad, accesibilidad y otras disciplinas tuvieron su primer respaldo en esta iniciativa.

El trabajo del Comité de Normas Web fue largo y se consultó al rango más amplio de involucrados en diferentes áreas: desde los responsables de sitios web de gobierno para evaluar el impacto y factibildad técnica, otros comités técnicos de gobierno, fuentes académicas y privadas entre otros. Fui invitado a participar cerca del 2003 (no recuerdo con exactitud…) como consultor del área privada con participación en varios proyectos de gobierno, a algunas de las primeras reuniones donde se confrontaron opiniones de responsables de sitios, expertos en temas concretos y proveedores privados. Algunas de las discusiones más interesantes tuvieron que ver con las repercusiones técnicas de la accesibilidad y del uso de estándares web. Posteriormente no supe mucho de la actividad del Comité hasta ahora.

Detalles del Decreto 100

Revisando el decreto, podemos destacar algunos de los aspectos más relevantes que contempla:

  • Los sitios de gobierno deberán utilizar los dominios .gob.cl y .gov.cl. Algunos de los sitios más importantes actualmente sólo utilizan el dominio de país .cl
  • Disponibilidad de la información. Esto se refierre implícitamente al uso de marcado semántico.
  • Se recomienda que el marcado sea HTML, XHTML o XML válido
  • Se recomienda el uso de UTF-8 para la codificación de caracteres, esto en vías a la estandarización en XML.
  • Los sitios deben indicar explícitamente una política de privacidad.
  • Los sitios deberán usar CSS para la presentación
  • Se refuerza la independencia de navegadores, particularmente debiendo al menos uno de ellos (navegadores) ser de distribución y uso gratuito, y estar disponible desde el propio sitio web.

Cumplimiento de las Normas del Decreto 100

Para el cumplimiento de las normas se establecen dos niveles:

  • El primer nivel deberá cumplirse a partir de un año desde la publicación en el Diario Oficial
  • El segundo nivel será obligatorio a partir del segundo año desde la publicación en el Diario Oficial

En los próximos 140 días a la publicación del decreto que da origen a las normas, el Ministerio Secretaría General de Gobierno deberá publicar y adoptar una Guía de Accesibilidad para Discapacitados en Sitios Web y una Guía Modelo de Políticas de Privacidad.

Falta aún analizar los detalles del Decreto 100, pero me parece que ante todo es un avance muy positivo. Volveré pronto con más información.

Semáforos con Botones: Placebos Mecánicos

Diseño de Interfaces, Experiencia de Usuario

¿Alguna vez te has sentido como Locke en Lost, presionando el botón de los semáforos sin saber si eso realmente sirve para algo? ¿Cambiará más rápido la luz del semáforo?

ep202_19b_360x240

Locke, el personaje de Lost, ingresa el código numérico cada 108 minutos sin saber qué pasará cuando no lo haga… (foto de ABC)

Pues sucede que en muchos casos el botón no hace nada realmente. Funcionan como placebos mecánicos. El efecto que producen los botones de los semáforos es reducir la ansiedad de la espera y entregar, de paso, la ilusión de control.

El 2004 The New York Times publicó un artículo en el que contaba cómo los botones de los semáforos, que alguna vez fueron realmente funcionales, fueron desactivados con la implementación de sistemas de control de tráfico computarizados. El artículo explica los detalles y la historia de estos botones junto con las impresiones de los peatones que se enfrentan a ellos. Sobre el mismo tema, el Honolulu Advertiser también publicó un artículo poco tiempo después.

No deja de ser curioso que algo que ocurrió casualmente (el que los botones dejaran de funcionar y permanecieran instalados) continúa hasta hoy haciendo creer a muchos que existe un efecto real. La lógica de esto es que si el botón está ahí, existe alguna posibilidad de que funcione, y como es poco probable que el presionarlo cause algún problema, lo presionamos por si acaso. Aunque esto no tenga ningún efecto real, se reduce la percepción del tiempo de espera. Incluso si el tiempo es el mismo.

Todo esto se basa, naturalmente, en que algunos botones en semáforos sí funcionan, o en que alguna vez funcionaron. Esto le da credibilidad a todo el sistema y permite que nos engañemos pensando que todos funcionan. O al menos a que lo consideremos una posibilidad.

334213_spanish_traffic_light_green

El tiempo de espera para que cambie la luz del semáforo puede causar impaciencia en los peatones. El botón que existe en algunos semáforos no siempre funciona (casualmente o por diseño), pero crea una percepción de disminución de la espera y de aparente control (foto en stock.xchng, por pixman).

¿Podría utilizarse el efecto placebo en el diseño de interacción? Se me ocurre un ejemplo en que se utiliza un efecto similar: las animaciones que utilizamos para representar la carga de un elemento. Me refiero a las animaciones en Flash o en Ajax, en que no se indica el porcentaje de avance, sino solamente que está ocurriendo algo. No se está informando cuánto tiempo falta, solamente que debe esperar. Sin embargo ayuda a disminuir lapercepción de espera, en la medida en que el tiempo que transcurra sea breve. Evidentemente si la espera es demasiado larga, ninguna animación será efectiva y el usuario terminará frustrado. El efecto es parecido, aunque en realidad no ocurre una interacción real con el usuario.

Pero no saltemos rápidamente a conclusiones. No podemos pensar que intencionalmente podríamos utilizar este tipo de efecto placebo en un sistema interactivo sin consecuencias. En el caso de los semáforos, los usuarios tienen una duda razonable sobre la utilidad del botón, pero lo utilizan porque no hay un daño o perjuicio al presionarlo. Esta duda, no obstante, es un lujo que no podemos permitirnos fácilmente. Uno de los atributos más difíciles de lograr y muy frágil como para jugar con él es la confianza. Si juego con la credibilidad de los usuarios, las consecuencias pueden ser demasiado caras.

En el blog History of the Button hay una nota interesante sobre los botones de los semáforos, y si no lo has visto antes, es un sitio obligatorio para todos los interesados en el diseño de interfaces.

Tamaños de Pantalla, Resolución, Móviles y el Cambio Permanente

Móviles

Es común referirse al problema de los tamaños de pantalla cuando hablamos de web. Y lo que normalmente discutimos es si debemos utilizar layouts fijos, líquidos, mixtos y un sinfín de variedades. El problema de fondo es cómo nos adaptamos a las tendencias de uso de los monitores y las resoluciones de pantalla para garantizar que el contenido necesario esté disponible inmediatamente para la mayoría de los usuarios y cómo le prestamos soporte a los usuarios con tamaños menos frecuentes o en desuso.

Actualmente la tendencia de uso mayoritaria es 1024×768 píxeles (55% de los usuarios según TheCounter.com), la segunda mayoría utiliza una resolución aún mayor: 1280×1024 píxeles (18%). La tercera mayoría es una resolución en retirada rápida, 800×600 píxeles(17%). Aún recuerdo cuando la resolución mayoritaria era 800×600px., eso no fue hace demasiado tiempo. Pero estas tendencias de uso son muy dinámicas y varian con rapidez.

La rapidez relativa con que cambian las condiciones de visualización en el web nos obliga a tener al menos tres factores en consideración:

  • Cuáles resoluciones son las utilizadas actualmente
  • Cuáles son las resoluciones en salida, es decir, aquéllas que recientemente eran más utilizadas, pero que ha sido, o están siendo, superadas
  • Qué tendencias de uso podemos prever para el futuro próximo

Con estos tres factores podemos considerar los escenarios más comunes para la mayoría de los usuarios. Podremos satisfacer la demanda de la mayoría que utiliza una resolución estándar en un momento determinado, pero al mismo tiempo podremos soportar las condiciones de navegación de aquellos usuarios que aún no hacen el cambio y utilizan resoluciones en retirada. Pero además, estaremos preparados para admitir el cambio gradual hacia resoluciones de pantalla mayores. Los cambios no son inmediatos, por lo tanto no es fácil decidir cuándo dejar de soportar una resolución que hasta hace poco tiempo era común, pero que está a punto de caer en desuso por la mayoría.

Evidentemente, no es fácil manejar todos estos factores. En las condiciones actuales, estos tres puntos se podrían traducir en:

  • Actualmente la resolución de pantalla más utilizada es 1024×768px. Esto significa que los sitios deberían visualizarse adecuadamente en este tamaño, mostrando la información más importante en el espacio disponible para los navegadores en estos tamaños. Ningún contenido importante debería quedar oculto bajo el primer pantallazo. El texto debería ser fácilmente legible y estar dispuesto en bloques que no creen líneas que dificulten la continuidad de la lectura.
  • Hasta hace poco, la resolución más común era 800×600px y aún un número importante de usuarios navega en estas condiciones. Esto indica que debemos asegurar que el contenido más importante sea visible en esta resolución, aunque parte de la información menos indispensable quede parcialmente oculta y sea necesario hacer scroll para llegar a ella.
  • La tendencia en alza es el uso de monitores mayores: el más común y en ascenso actualmente es el de 1280×1024px. En mi opinión es un error utilizar layouts elásticos en estas resoluciones, porque las líneas de textos tienden a extenderse demasiado y se pierde en fluidez de lectura. Para estos casos, una estrategia mixta es más apropiada, en que se establezca un límite máximo para el despliegue de contenido. Con pantallas y resoluciones mayores se hace menos frecuente el uso de ventanas de navegadores maximizadas, con lo que el tamaño real en que se verá un sitio es incluso más variable.

Pues bien, esto no acaba aquí. He descrito un escenario bastante complejo, pero todavía manejable. Administrar las tendencias de uso del pasado, presente y futuro en el web hasta ahora parece posible. Pero todo se revuelve y dificulta cuando agregamos un factor cada vez más omnipresente: el acceso a web mediante móviles.

Los Teléfonos Móviles y Hanhelds

Los celulares con acceso a internet y los handhelds están aquí, eso es un hecho. El problema es que uno de los pocos factores que tienen en común estos dispositivos, es que son pequeños. Los tamaños son muy diversos y ni siquiera existe una proporción que pudiéramos considerar como estándar. Cuando hablamos de los monitores de los computadores de escritorio, la proporción es aproximadamente de 1,3 considerando el ancho y alto. Esta proporción se mantiene en 640×480, 800×600, 1024×768, 1280×1024. Los notebooks de pantalla ancha agregan un tipo de variación que antes no habíamos considerado y que debemos tener presente, porque la tendencia de esos dispositivos es hacia el uso de este tipo de monitores, comúnmente de 1280×768px.

Pero con los móviles no tenemos muchas certezas. Hay pantallas alargadas verticalmente, otras cuadradas y otras alargadas horizontalmente. Las proporciones son también diversas:1/1,25, 1/0,75, 1/1,3, etc.

tamanos-pantalla-moviles

No existe un tamaño estándar para las pantallas de los teléfonos celulares con acceso a web. Más aún, la diversidad de tamaños es enorme y en muchos casos no existe ni una relación de tamaños, proporciones o disposición. En la imagen, algunos ejemplo de tamaños de pantallas para teléfonos celulares.

La situación se extrema dejándonos al medio de un problema complejo: entre resoluciones muy pequeñas, que por su naturaleza no pueden crecer mucho más o dejarían de ser portátiles y las resoluciones mucho mayores de los monitores de escritorio nuevos. Aquí también el tamaño máximo es un límite, pero de todos modos aún hay espacio para crecer, más que en tamaño, en resolución: no he siquiera mencionado hasta ahora los monitores de alta densidad, con una densidad de píxeles mucho mayor en un menor espacio. En esta oportunidad no me detendré a comentar el impacto de las pantallas de alta definición, que agregan otro factor de incertidumbre y puede ser determinante para marcar una diferencia real entre lo que vemos en el monitor de un computador personal y en otros dispositivos.

¿Cómo se resuelve todo esto? ¿Cómo manejamos esta diversidad y priorizamos nuestros esfuerzos? En primer lugar, hay que analizar una serie de factores:

  • Identificar la audiencia: quiénes son los usuarios y qué necesidades tienen. Esto permitirá determinar cómo se estructura el sitio en función de los requerimientos de sus usuarios.
  • Identificar las tareas más comunes y urgentes: qué harán más frecuentemente los usuarios de un sitio y cuál es la real importancia de ellas. Esto permitirá priorizar y definir los requerimientos y condiciones en que se presentarán los contenidos.
  • Determinar contenido y funciones clave: no todo el contenido debe estar disponible para los móviles, hay contenidos y servicios particularmente sensibles que deben ser accesibles desde cualquier lugar, como por ejemplo, sistemas de mensajería, webmail, etc.
  • Identificar las plataformas más utilizadas por los usuarios: conocer las condiciones de navegación de modo tradicional (PC, notebook) y las plataformas móviles preferidas por los usuarios permite establecer una estrategia más precisa.

Con estos antecedentes, podemos determinar la real necesidad de tener versiones especiales de un sitio.

¿Cómo se Navega con un Móvil?

Es relevante conocer cómo se navega en internet utilizando móviles, porque existen distintas formas que afectan radicalmente el modo en que se accede a los contenidos y cómo se interactúa con ellos.

  • Los dispositivos móviles están utilizando cada vez más frecuentemente versiones light de navegadores web, como Opera Mini, que permiten navegar el web y ver cualquier sitio que un browser normal sea capaz de ver. Esto permite considerar el uso de hojas de estilo especializadas para presentar correctamente el contenido a estos dispositivos así como para las versiones full de los sitios. El problema es que esto no hace nada por tratar el contenido de un modo especial. Los móviles imponen requerimientos de tratamiento del contenido muy restrictivas no sólo porla resolución de las pantallas, sino que también por el ancho de banda y los costos relacionados. En este sentido la convergencia de dispositivos en una misma versión del sitio no es muy recomendable, porque no atiende las condiciones reales de cada uno.
  • Actualmente muchos de los sitios especialmente dedicados a móviles están preparados para servir a estos dispositivos adaptándose a sus dimensiones y condiciones. Ellas no sólo se refieren a la resolución, sino también a la velocidad de conexión, tipos de interacción, etc. Esta estrategia de realizar versiones especializadas diferentes de los sitios normales, tiene una gran ventaja, el contenido es preparado para las condiciones de navegación de los móviles: fotos de menor resolución, textos más breves, versiones resumidas, entre otras. En tanto la versión completa del sitio no se ve alterada. Paralelamente, la versión full del sitio, destinada a PCs de escritorio y notebooks no se ve afectada por las restricciones de los móviles.

Conclusiones

Hemos revisado varios puntos hasta ahora, por lo que terminaré con un resumen y conclusiones breves:

  • En los monitores de escritorio es necesario considerar las tendencias de uso de cada momento para decidir las resoluciones que se priorizarán, las que se soportarán parcialmente y qué estrategia seguiremos para las restantes
  • Debemos tener en consideración el cambio inminente en los monitores de escritorio que traerá pantallas con mayor definición y que podrían afectar la forma en que utilizamos el espacio de las pantallas
  • Debemos tener en consideración la proporción creciente de notebooks con pantallas alargadas o widescreen, que introducen una alteración en la forma en que los sitios son vistos por los usuarios
  • Es necesario tener en cuenta cómo los teléfonos móviles y los handhelds se integran a nuestra audiencia, o incluso cómo los podemos captar
  • Debemos tener en cuenta las diferentes formas de acceder a internet utilizando dispositivos portátiles como los teléfonos móviles y los handhelds, que afectan la forma en que los sitios son utilizados, y la experiencia que generan en los usuarios

Todo lo que acabo de plantear es una conversación abierta que es necesario discutir para decidir cómo nos adaptamos a las condiciones cambiantes de navegación y uso del web. Lo único que es permanente, es el hecho de que debemos estar atentos a los cambios y a cómo ellos afectan el modo en que diseñamos y desarrollamos para los usuarios.

Registro en Video de Testeos de Usabilidad

Usabilidad

Mientras leía un reporte de Nielsen Norman Group, me sorprendió la opinión de Nielsen respecto de los registros en video de las sesiones de usabilidad. Básicamente su posición es: no vale la pena hacer registro en video de las sesiones, un facilitador experimentado tomará suficientes notas, además el par de horas que puede tomar analizar un video se aprovecha mejor realizando más testeos.

La opinión de Nielsen es del año 2001 en el contexto de un estudio en particular, por lo tanto es posible que no represente su opinión general del tema. Sin embargo me sirve de excusa para hablar de los registros en video en las evaluaciones de usabilidad.

Hasta hace poco, lo común en los estudios de usabilidad, particularmente los testeos con usuarios, era utilizar cámaras de video con cintas VHS para realizar los registros, lo que complicaba bastante su uso posterior. El equipamiento de video para realizar el registro es, además, costoso y voluminoso: trípodes, cámaras, equipos para edición, etc.

Actualmente existen muchos programas que facilitan la tarea y la hacen menos intimidatoria para los usuarios: una webcam pequeña es lo suficientemente discreta como para que los participantes en las pruebas la oviden rápidamente y no necesita un operador que la maneje. De este modo se puede montar fácilmente un laboratorio de usabilidad muy económico y portátil.

Por otro lado, los registros digitales son baratos (no necesitas comprar cintas y los DVDs para realizar respaldos son muy económicos), fáciles de revisar y editar. Personalmente he revisado sesiones registradas en video digital en una fracción del tiempo real de duración de las sesiones. Normalmente el video sirve para corroborar opiniones, verificar dudas y discutir algunos detalles con otros evaluadores. Un video digital se puede explorar rápidamente, reproducir a mayor velocidad y, con aplicaciones especiales como Camtasia, se pueden crear marcadores en secciones específicas para identificar hitos importantes como el inicio o fin de las tareas.

En suma, las notas que se toman durante las sesiones de evaluación de usabilidad son fundamentales, pero los videos son un apoyo muy importante y, en mi opinión, imprescindibles.

Búsqueda Accesible en Google

Accesibilidad

En el newsletter de Google leí hace un par de días sobre un nuevo servicio de búsqueda optimizada para usuarios ciegos. Se trata un producto actualmente en el laboratorio, basado en el buscador de Google y que prioriza los resultados en páginas que sean más simples en su estructura, lo que presumiblemente las hace más accesibles. Sabemos que hay más factores involucrados con la accesibilidad del contenido web, pero una de las cosas más determinantes es la simplicidad y el marcado estructural de los contenidos medianteHTML.

T.V. Raman, a senior research scientist here at Google, is blind, and
he has just led an exciting project for us called Google Accessible
Search. This new service (currently on Google Labs) adds a small twist
to Google web search: in addition to finding the most relevant results
from Google as usual, Accessible Search further prioritizes results
based on the simplicity of their page layouts. When you search from the
Accessible site, you’ll get results that are prioritized based on their
usability. This tends to favor pages with few visual distractions, and
pages that are likely to render well with images turned off. Google
Accessible Search is built on Google Co-op’s technology, which
emphasizes search results based on specialized interests.

T.V. Raman, […] es ciego y ha liderado un exitante proyecto para nosotros llamado Búsqueda Accesible Google. Este servicio nuevo (actualmente en Google Labs) agrega unos pequeños ajustes al buscador web de Google: además de encontrar los resultados más relevantes en Google como es habitual, el buscador accesible prioriza los resultados basados en la simplicidad del layout de las páginas. Cuando buscas desde el sitio accesible obtendrás resultados que priorizan la usabilidad. Esto tiende a favorecer a las páginas con menos distracciones y a aquéllas que posiblemente se presentarán mejor sin imágenes. […]

http://labs.google.com/accessible

Sería ideal que este tipo de valoración se aplicara a las búsquedas normales y no fuera necesario utilizar una versión especial del buscador, aunque de todos modos sabemos que las páginas construidas adecuadamente, con simplicidad y cuidado obtienen mejor reconocimiento por los buscadores. Al fin y al cabo, los buscadores son ciegos. Con recursos, pero ciegos.

Desconferencia 2 en Santiago

General

El sábado pasado tuvimos en Santiago la segunda Desconferencia. La primera versión la organizaron los españoles y fue una muy buena experiencia a juzgar por lo que ellos cuentan. La segunda se organizó en torno a AIChile y se realizó el sábado 22 de julio entre las 9:00 y las 13:30.

En AIChile se habían organizado otras reuniones a las que yo no había podido asistir, por lo tanto conocía a la mayoría sólo por la lista de correo. Fue muy grato ver las caras de los integrantes y quedé muy contento con el resultado de la conversación.

desconferencia02

Algunos de los asistentes a la Desconferencia.

La jornada partió con el sorteo del orden de los participantes y tuve el privilegio de partir con la primera exposición. Me interesaba generar una conversación para poder compartir nuestras experiencias y visiones, así que decidí hablar sobre los wireframes en el contexto de las aplicaciones ricas o RIAs. Este tema ya lo venía tratando desde hace un tiempo y me interesa particularmente desde la perspectiva del proceso de diseño y cómo nos adaptamos a las nuevas condiciones tecnológicas.

El resumen de la conversación lo pueden encontrar en el sitio de la desconferencia, la verdad es que me dediqué a tomar fotos: publiqué una galería con cerca de 80 fotos.

En suma, fue todo un placer conocer a los que no conocía y ver a los antiguos (para no decir viejos) de siempre. Notas destacadas (por mis intereses, obvio, la verdad es que en general todo estuvo notable):

  • Camus, excelente presentación, me encantaría escucharte hablar más sobre la escritura para el web
  • Javier, quedé con gusto a poco, esperaré el IA Retreat ansiosamente
  • Rodrigo, el tema estuvo muy interesante, definitivamente en internet móvil hay todo un mundo

Esperaré ansiosamente la próxima oportunidad, ya hay ofrecimientos muy interesantes como el de Jorge de ser anfitrión en la 5ª región.