Antes que todo, mis más sinceros agradecimientos y felicitaciones para los chicos de Derechos Digitales, el trabajo que están haciendo es notable. Ahora, aquí va mi registro del taller legal para bloggers organizado por la Corporación Derechos Digitales, que se suma a la ya amplia cobertura en los blogs de los asistentes.

Nota: las fotografías, así como todos los contenidos de el factor humano están publicados con una licencia Creative Commons, así que eres libre de pedir prestado, reciclar y republicar según las reglas de la licencia.

El evento local para celebrar el Día Mundial de la Usabilidad fue todo un éxito. Sobrepasó nuestras expectativas de asistencia y de calidad. Las exposiciones y discusiones fueron muy interesantes y constructivas y la asistencia llegó a más de 80 personas, bastante más de nuestros cálculos más optimistas.

Todo partió con una presentación de Javier Velasco y luego Paulo Saavedra habló sobre el rol de la usabilidad en el gobierno electrónico y lo realizado en el Estado chileno al respecto, así como también de los planes futuros.

Siguiendo, Hernán Saavedra, Gerente Banca a Distancia de BancoEstado nos dió a todos una sorpresa por la lucidez de su presentación desde la perspectiva de un cliente, pero de uno que tiene las cosas muy claras.

Para continuar, Felipe Almazán, Coordinador Desarrollo de Sistemas de la Biblioteca del Congreso Nacional presentó la experiencia de aplicar las pautas de Nielsen y Krug para mejorar el sitio web de la Biblioteca.

Después del descanso, continuamos con la primera mesa de discusión, sobre Usabilidad y Negocios, con Juan Carlos Camus (SBIF) y César Romero (BCI), moderada por Juan Luis Martínez. La conversación se centró en la banca y el rol de la usabilidad en los resultados del servicio al cliente y sobre cómo se vende internamente la necesidad de usabilidad en una organización.

Una grata sorpresa fue el contacto de Javier Velasco vía Skype con Steve Krug, con quien conversamos por unos 15 minutos.

Para terminar, la segunda mesa estuvo compuesta por Leo Prieto, Gabriela García (Amable), Jorge Barahona (Ayer Viernes) y yo, Nelson Rodríguez-Peña. La discusión se centró en la relación entre diseño y usabilidad.

Sin más intoducción, los dejo con el registro fotográfico de la jornada.

Motivado por la publicación de Nielsen sobre la usabilidad de los blogs, Vuarnet
(www.isopixel.net) invitó a un grupo de autores de blogs hispanoparlantes para entregar su propia versión de los problemas de usabilidad. Se realizó un trabajo de discusión en línea entre los integrantes repartidos por México, España y Chile y se generó el siguiente listado de problemas comunes de usabilidad en blogs. El grupo está conformado por:

• Gustavo Barron (http://ageku.net/)
• Nelson Rodríguez-Peña (http://www.webstudio.cl/blog/)
• NOlo y Seth (http://alquimistas.evilnolo.com/)
• Raúl Ramírez, Vuarnet (http://www.isopixel.net)
• Yusef Hassan, (http://www.nosolousabilidad.com/hassan/)

Esta lista es un trabajo colectivo que publicamos simultáneamente en
nuestros blogs personales. Los dejamos con la lista, no sin antes saludar a
Vuarnet quien está pasando por un difícil momento personal, un
reconocimiento para él y nuestros mejores deseos a la recuperación de su
hermano, Juan Guadalupe Ramírez.

Enlace a la página principal no disponible

Un error frecuente y complejo es la falta de un vínculo permantente hacia la página principal o portada del blog. Un usuario que entre al sitio directamente a una página interior se verá imposibilitado de acceder a la portada, a menos que modifique directamente la URLbuscando la página principal.

Enlaces que se abren en una nueva ventana

Por razones de interoperatividad e independencia de dispositivos de visualización oficialmente se dejó de incluir el atributo target en XHTML. Esta propieda permitía abrir una nueva ventana al activar un vínculo. Para un usuario puede resultar molesto, desorientador e intrusivo que sin previo aviso se abra una nueva ventana, las consecuencias de accesibilidad son aún más negativas. Es más apropiado dejar que el usuario tome la decisión de navegar en la misma ventana o decidir abrir una nueva.

Enlaces embebidos

Los enlaces que figuran dentro de un texto más extenso deben tener un rótulo descriptivo, que permita predecir hacia dónde lleva el enlace y que a la vez sea significativo respecto al contenido del que trata. Deben ser representados visualmente de un modo distintio y lo más convencional posible. Por esta caracterización especial, no se debe abusar de enlaces en el cuerpo del texto, ya que pueden producir ruido visual y dificultar la lectura.

Acerca de…

No es necesaria una fotografía del autor, pero una breve descripción del sitio y un aviso desde que lugar (país) desde donde se está escribiendo es de gran importancia. Darse a conocer genera confianza y esto aumenta la credibilidad.

Correo de contacto

Un correo de contacto es fundamental, los comentarios en el blog no son suficientes. Si alguien desea preguntar algo en privado, sugerir un tema, o establecer cualquier tipo de comunicación, debe encontrar un mecanismo simple y efectivo para ello.

Enlaces permanentes (Permanent Links) usables

Los permalinks o enlaces permanentes son la URI para identificar un post. El permalink de un post debe ser único y permanente, no cambiar. A esto se aplican las reglas generales de una URI bien diseñada: que sea legible y no una solicitud GET de forma http://miblog.com?postid=12345

Títulos claros y significativos

Los títulos deben ser precisos y concretos además de estar relacionados con el ontenido de un post. Un título como He estado pensando… es ambiguo y poco significativo, en tantoPensamientos sobre diseño utiliza palabras clave relevantes que indican inequívocamente el tema general del que se habla. Esto ayudará a describir mejor el tema, permitirá a los buscadres indexar más apropiadamente, etc.

Títulos de ventanas

El título de la ventana o más apropiadamente del documento (head->title) debería estar construido como Título del post – Nombre del Blog. De este modo se informa apropiadamente al usuario del tema y la ubicación de la página, a la vez que resulta mucho más fácil leer el historial del navegador y las pestañas de las ventanas minimizadas, cuando están disponibles. Un ejemplo de buen uso es Señalética en Baños > Mi blog de diseño.

Enlace a contenido sindicado

Los contenidos sindicados (o feeds) mediante formatos como RSS o Atom son muy utilizados por quienes acostumbran leer blogs. Por lo mismo, es importante ofrecer vínculos claros a este tipo de canales alternativos. Aunque muchas herramientas ofrecen auto descubrimientode feeds, es importante hacer explícita la existencia de estos formatos y disponer de un modo rápido de suscribirse a ellos.

Contenido sindicado: demasiados sabores, demasiados dolores de cabeza

Los formatos de contenido sindicado y sus mecanismos de lectura son conocidos por los usuarios frecuentes de blogs, pero no se debe asumir que todos los letores estarán familiarizados con ellos o su significado. Si a esto agregamos la variedad de alternativas de formatos, tenemos una gran posibilidad de confusión. Es recomendable utilizar herramientas que proveen contenidos optimizados para cada usuario o cliente de modo automático, como por ejemplo Feedburner. Estos servicios permiten entregar un solo formato al usuario final, con una única URL, evitando así traspasar al usuario un problema innecesario.

Entradas previas y Encontrabilidad

Los blogs son sistemas de publicación basados en fechas y con una actualización frecuente de contenidos, por lo que es común que los posts vayan quedando ocultos en los archivos. Resulta útil, con el objetivo de proporcionarles visibilidad, ofrecer sistemas de navegación alternativos al clásico Archivo: Taxonomía de categorías, esquemas de navegación por paginación cronológica (atras/adelante), y elementos como los posts más leídos, destacados, etc. Además de estos sistemas, enlazar desde posts actuales aquellos otros posts relacionados temáticamente y publicados con anterioridad proporcionará encontrabilidad a estos últimos.

Páginas con exceso de información o mal organizadas

Es frecuente el uso de columnas o sidebars de apoyo que contienen información o funcionalidades complementarias, como por ejemplo buscadores, archivos, categorías y otros. Tamien es común la promoción de algunos servicios o campañas. No obstante, el abuso de estos elementos y su disposición indiscriminada puede causar efectos nocivos como lentitud en la carga de las páginas y una gran contaminación visual.

Vocabulario excluyente o demasiado tecnologizado

No todos entienden lo que es un blog, un blogroll, un permalink, un feed, un post ni por qué existen los comentarios o cómo se comenta. Es importante asumir que los visitantes nunca han visitado un weblog, por lo que es preferible pecar de obvio que dejar a los usuarios sin pistas de lo que se está hablando. Si alguien encuentra accidentalmente.

Redacción

Es preferible utilizar un lenguaje sencillo, claro y directo. Resume.

Limpieza y Legibilidad

Es necesario evitar el uso de texto multicolor, el empleo de bajos contrastes entre texto y fondo, tamaños de texto minúsculos, el UsO InjUStificADO de mayúsculas y eskritur4 ko0l. Todos estos recursos dificultan la lectura y van en desmedro del acceso al contenido.

Estética

La estética es uno de los factores de diseño que de forma más directa impacta en la percepción de los usuarios. Cuidar la estética, que no significa añadir elementos decorativos superfluos, contribuirá a persuadir y motivar al usuario. Recordemos además que el minimalismo en el diseño es al mismo tiempo un principio heurístico de usabilidad y una noción estética.

Escribe en tu idioma

Un error de usabilidad bastante común es no usar correctamente el lenguaje. evita los aforismos en la medida de lo posible. Cuando existan términos que reflejen apropiadamente un concepto en castellano, prefiere la opión en castellano. En este documento, hemos optado conscientemente por téminos como blog y post porque creemos que las traducciones no son tan apropiadas. Al incluir una cita originalmente en otro idioma, es importante traducirla. Es un esfuerzo que los usuarios agradecerán.

Intenta seguir estándares

Los estándares en la web (XHTML, CSS…) así como las directrices de accesibilidad (WAI), son importantes para no excluir a nadie de tu blog.

Ya casi me había olvidado de este pequeño juego/experimiento. Hoy me lo recordó un comentario en el post y me fui directo a Google a ver cómo andaba todo. Y como verán, funciona perfectamente.

¿De qué se trata? se preguntarán. Pues bien, hace casi cuatro meses escribí un post tituladoOptimización de Búsqueda, No de Motores de Búsqueda para probar y demostrar el comportamiento de los buscadores, en particular Google. La idea era simple, escribí sobrecómo podemos modelar el contenido para mejorar los resultados de búsqueda. Pero aquí no me refiero a cómo engañarlos para obtener mejores posiciones, sino a cómo guiar a los indexadores para que reconozcan con mayor precisión el contenido y puedan calificarlo apropiadamente. Es decir, no optimizar el contenido para sacar ventajas de un buscador y su funcionamiento maliciosamente, sino optimizar el contenido para asegurar que sea indexado correctamente y de ese modo sea encontrado en un contexto relevante.

Las claves del experimiento eran utilizar repetidamente los términos más relevantes y variaciones del mismo: buscar, buscador, búsqueda, buscando, buscarán junto con Google,Yahoo, MSN, entre otros. Estas palabras claves fueron utilizadas en puntos importantes como el título de la página. Además, se utilizaron discretamente algunos vínculos a páginas externas con temas relacionados, para respaldar el contenido.

Finalmente, y pese a que sólo unos pocos se animaron a comentar (lo que ciertamente hubiera aumentado las posibilidades de mejorar los resultados), la página es el primer resultado retornado por Google en una búsqueda general para los términos optimización de búsqueda, sin indicar idioma, es decir, en todo el universo de páginas indexadas por Google. Sí, primer resultado retornado entre 658.000 encontrados. Impresionante, ¿no? Pese a que el ejercicio estaba orientado a Google, Yahoo también responde a patrones similares, y califica la página en el lugar 13, nada mal. MSN por su parte parece no calificar las cosas del mismo modo, porque ni siquiera pude encontrar la posición en que aparece. Como no estamos hablando de una técnica en particular, sino de cómo construir el contenido para facilitar el trabajo de los buscadores, esto no habla muy bien de MSN.

Conclusión: es muy relevante preocuparse de utilizar los términos apropiados, repetirlos en lugares importantes como el título de la página, los encabezados h1, h2, etc. y validar el contenido con vínculos externos relevantes.

Hoy tuve una de esas experiencias que te toman de la mano y te aterrizan a una realidad que a veces nos elude. Estaba en un cajero automático, ATM o como quieras llamarlo, y a unos tres metros observé a una persona, un hombre relativamente joven, con un aspecto que evidenciaba su falta de recursos. Estaba en una actitud que no era para nada intimidante, pero me llamó la atención.

Cuando terminamos la operación (con Are, mi esposa), nos alejamos del cajero, pero este personaje se me acercó y me pidió ayuda. ¿Me puede ayudar a usar la tarjeta?. Claro, fue más señas y gestos que una frase elaborada. Asumiendo que estábamos en un lugar público, abierto, con algunas personas alrededor y un par de guardias a la vista, accedí. Me pasó su tarjeta. Este simple gesto describe todo el escenario. Este hombre, probablemente un campesino pobre, con toda ingenuidad le pasó a un desconocido su tarjeta para utilizar el cajero automático. Si le pido su clave, seguro me la hubiera dado.

Su actitud era de completo temor al aparato que tenía en frente. Le devolví su tarjeta y lo guié mientras él realizaba la operación, pese a que me pidió que lo hiciera yo para el observar y aprender. Esto me dejó en claro que su nivel de alfabetización era mínimo, apenas podía leer. Quería sacar $10.000, unos U$18 ó €15.

En cada pantalla nueva del cajero su desconcierto era mayor. Sumemos a su condición, el que el dispositivo no tenía alineadas correctamente las opciones de la pantalla con los botones que se encuentran al costado para realizar las selecciones. Esto provocó un par de intentos erróneos en que cualquier persona se hubiera equivocado.

Con ayuda y muchas dudas, logró terminar la transacción.

La situación completa me hizo pensar en muchas cosas, desde la brecha cultural, la famosa brecha digital y el diseño de interfaces para públicos tan disímiles como este extremo, que de seguro es el denominador mínimo al momento de desarrollar una interfaz para usuarios sin discapacidades particulares. Pero claro, planteado así, el analfabetismo es una discapacidad.

Cómo no va a ser un tipo de discapacidad, inmediatamente recordé una situación similar cuando tenía unos 12 años, y una señora mayor me pidió que le ayudara a encontrar el bus del recorrido que necesitaba. Evidentemente no sabía leer. Y en otra oportunidad en que una abuela me pidió que le marcara un número en un teléfono público. Estas situaciones acá son aisladas, Chile es un país con un nivel de analfabetismo bajísimo, 4.4%. Pero son los casos extremos, entre medio hay muchos matices.

Pues bien, esto me hizo ver con otros ojos un proyecto en el que estoy participando que involucra como público objetivo a personas desde el nivel del personaje del cajero automático, hasta personas más preparadas, pero de todos modos de un nivel sociocultural bajo, sin acceso directo al mundo digital. En una situación como ésta, todo lo que damos por sentado hay que cuestionarlo, todo es nuevo, nada es una convención. ¡Vaya desafío de interacción!

Me enteré ayer de la publicación de los resultados de un estudio de las páginas de inicio de las Universidades Españolas. El proyecto está organizado por AIPO, Asociación Interacción Persona Ordenador. El proyecto se coordinó mediante un blog, USABAIPO, Proyecto Usabilidad Páginas Web Universidades Españolas. Revisando los resultados y metodología usados, me surgieron algunos conflictos. Aquí va mi comentario, realizado con el mejor de los espíritus y entendiendo que éste es un esfuerzo notable.

Introducción

El proyecto USABIPO se planteó analizar las páginas de inicio de 69 universidades españolas. Sé personalmente que esto es un esfuerzo monumental. Durante el primer semestre de este año participé en un estudio encargado por el Ministerio de Economía del Gobierno de Chile para analizar la usabilidad de los trámites en línea del Estado chileno. Mi rol en este estudio fue particularmente la planificación, coordinación y ejecución de las evaluaciones heurísticas de 61 trámites, en el que participaron tres evaluadores junto a mí como evaluador y responsable de esa parte del estudio. El proceso fue notable y, aparte de los inevitables problemas de tiempo y recursos de un proyecto como éste, me siento muy satisfecho de haber participado en él.

Pues bien, comento esto para dejar en claro que entiendo el esfuerzo que el proyecto USABIPO implica y lo valoro en ese sentido. Pero como mencioné antes, hay algunos aspectos metodológicos que me sorprendieron, y que paso a comentar como aporte y crítica constructiva.

Metodología

USABIPO plantea el tema de la metodología del siguiente modo:

Se efectuó una evaluación por inspección a través de la aplicación de tres métodos diferentes ampliamente consensuados dentro del ámbito de la IPO:

• Inspección de estándares
• Análisis de zonas de la interfaz
• Evaluación heurística

Inspección de Estándares

Nadie podría decir que los estándares web no me preocupan, pero no creo que deberían ser una parte fundamental de un estudio de usabilidad. Puede ser un complemento, un factor más, pero no una parte del estudio, porque el uso de estándares no garantiza usabilidad. Es cierto que es más posible que un sitio basado en estándares web sea más usable y accesible, pero no es una condición automáticamente adquirida.

Por otro lado, creo que hacer una validación automatizada es sólo una parte: así como ya lo hemos discutido muchas veces respecto a la accesibilidad, las validaciones automatizadas no son suficientes en sí mismas. Es cierto que validar CSS y HTML es más fácil que validar accesibilidad, porque los primeros se basan en las reglas predefinidas de un vocabulario conocido, donde la interpretación es menor. Pero un sitio válidamente formado no es lo mismo que un contenido semánticamente estructurado. Creo que esto último no lo cumple el estudio de USABIPO.

Análisis de Zonas de la Interfaz

Creo que es interesante lo que se ha hecho en esta área, pero me parece que se han entregado sólo datos y no información. Para mejorar un sitio, o la portada de un sitio, no me sirve que se identifique cómo está compuesta mi página, sino que se me entreguen pautas para mejorarla.

Evaluación Heurística

Por mi experiencia es aquí donde tengo más observaciones. El primer detalle que me llamó la atención es algo que pudiera parecer menor, pero que creo que metodológicamente puede tener repercusiones en los resultados: la redacción de las pautas heurísticas no es consistente y no representa criterios positivos. En algunos casos el criterio no queda claramente explicado. Esto puede llevar a inexactitudes al momento de la evaluación, porque es posible que los evaluadores interpreten de modo distinto las pautas.

Con lo anterior me refiero a que las pautas deberían estar compuestas por criterios positivos, cosas que el sitio o sujeto de estudio debería cumplir. Una heurística, entonces, debería ser un listado de pautas que se conocen como buenas prácticas de usabilidad. Si se desea incluir un problema frecuente a una heurística, es mejor transformarlo en algo positivo, por ejemplo, la tercera pauta del criterio Navegación de la heurística de USABIPO dice:

¿Se utilizan instrucciones genéricas (Ej. “Haga clic aquí”) o vínculos genéricos? (Ej. “Más”)?

La redacción es sumamente ambigua, y no es claro si el sitio debe cumplir o no con este criterio. Si respondo que sí, estoy afirmando que hace uso de una mala práctica. Si respondo que no estoy diciendo que el sitio no lo hace, lo que es correcto. Confuso. Quedaría mucho mejor planteada así:

El sitio utiliza vínculos en contexto, con un contenido descriptivo, en lugar de usar instrucciones genéricas (Ej. “Haga clic aquí”) o vínculos genéricos (Ej. “Más”)

Esto se aprecia en varias preguntas, por ejemplo:

¿Se utilizan las ventanas emergentes para dar información importante del sitio Web?

es ambigua respecto de si el uso de ventanas emergentes es bueno o malo. Entiendo que el sistema de puntuación trata de enfrentar esto, pero creo que es mucho más simple calificar usando una escala de 5 puntos y un no aplica.

Finalmente, la presentación de los resultados de la evaluación heurística me resulta sorprendentemente simple. No basta con un gráfico para saber cómo salí en la evaluación, necesito feedback detallado para saber cómo soluciono cada uno de los puntos en que fallé. Espero, e imagino de buena fe que así habrá sido, que a cada una de las universidades se les habrá entregado un resultado más detallado de estas evaluaciones.

Conclusiones

Reitero mi reconocimiento por el esfuerzo realizado, pero debo concluir con una visión un tanto negativa respecto a los resultados: creo que existen algunos problemas metodológicos y que hace falta una retroalimentación mucho más rica que permita conocer los problemas reales y detallados, junto con una orientación respecto a la forma de enfrentar los problemas observados.

Un problema frecuente en las aplicaciones web abiertas al público es el de los scripts automatizados que tratan de explotar algunas de sus caraterísticas para propósitos diversos, normalmente ilegítimos. Desde los robots que ingresan comentarios spam a los blogs por miles, hasta aquéllos que intentan abusar de los servicios de correo como MSN, Yahoo! y más recientemente Gmail, el factor común es que se trata de scripts o programas relativamente pequeños que se diseñan para abusar específicamente de ciertos sistemas.

Los spammers de blogs apuntan en particular a los comentarios, normalmente abiertos al público, para dejar vínculos que pretenden sacar partido de los buscadores que valoran positivamente la cantidad de referencias a un sitio. Los wikis, con su esencial característica de edición colectiva, son vulnerables también a estos problemas.

Una forma específica de enfrentar el problema, es utilizar un mecanismo que permita garantizar que quien realiza una acción es un humano y no un robot programado. La técnica más común es el uso de imágenes distorsionadas que para los humanos resultan relativamente simples de leer, pero que para un programa es muy difícil procesar. Estas imágenes son conocidas como captchas.

Captchas

Partamos por la definición del nombre: éste es una abreviación de Completely Automated Public Turing Tests to Tell Computers and Humans Apart, algo así como Prueba Turing Pública Completamente Automatizada para Diferenciar Humanos y Máquinas y fue acuñada por un equipo de IBM en el año 2000.

Esta técnica, desarrollada originalmente por AltaVista en 1997, busca distinguir claramente a un humano de un proceso programático, mediante el uso de imágenes distorsionadas de un modo que haga imposible el que sean leídas por algo que no sea un humano. Quien esté familiarizado con los escáneres de imágenes, probablemente conocerá también la tecnologíaOCR, Optical Character Recognition, que permite escanear páginas de texto como imágenes y transformarlas a texto. La tecnología OCR permite reconocer caracteres desde imágenes mediante análisis de inteligencia artificial, y demuestra que si bien se puede programar un sitema para que reconozca imágenes, deben existir ciertas condiciones para que el reconocimiento de los caracteres sea más fácil. Por lo mismo, los captchas distorsionan la imagen de un modo que hace imposible que que las tecnologías OCR actuales identifiquen su significado. Algunas de las técnicas para ocultar el texto en la imagen son el uso de tipografías poco usuales, distorsionadas, irregulares, junto con diferentes colores y elementos de ruido visual. Vale hacer notar que con un esfuerzo considerable es posible programar sisteas que sean capaces de leer captchas, pero normalmente el costo de esto es muy alto.

La técnica completa de los captchas consiste en presentar una imagen al usuario y solicitarle que ingrese el texto que reconoce en ella en un campo, normalmente una mezcla de caracteres alfanuméricos, y luego se comparan ambos para verificar si coinciden. Un script automátizado no pasará la prueba, en tanto un humano sí. ¿Sí?

Accesibilidad y Captcha

La base de la técnica de captcha se basa en que los humanos podemos leer. Pues bien, la mayoría lo hace, pero no todos podemos leer. Sí, me refiero a los ciegos. Esto establece un problema de accesibilidad concreto, que de no ser corregido, significa discriminación. La buena noticia, es que los captchas no sólo se pueden realizar con imágenes, es posible también utilizar audio para entregar información que sólo será diferenciable para humanos. La técnica es similar: se presenta la grabación de una serie aleatoria de letras y números en con ruido auditivo y cierta distorsión. Lo ideal es tener ambos sistemas, captcha de imagen y de audio, para permitir que todos los usuarios puedan ciertamente pasar la prueba de discriminación de humanos y máquinas.

En el Mundo Real

En muchos casos he encontrado captchas de imagen en sitios públicos como Yahoo! o incluso más recientemente en Gmail. Pero en todos los casos se omitía el problema de accesibilidad. En Gmail parecen tener planes al respecto, porque junto a cada imagen captcha se encuentra un gráfico pequeño con el símbolo de discapacidad, aunque la solución ofrecida es actualmente bastante pobre: abre una ventana nueva usando JavaScript, la ventana tiene el mismo captcha con texto en el atributo ALT que dice algo como usted no puede ver la imagen porque las tiene desactivadas en el navegado. Cómico, si lo quieres tomar con humor.

Sin embargo, hace uns días me llevé una sorpresa, que fue la que me motivó a escribir este ya extenso post: en MSN utilizan captchas de imagen y audio. Las siguientes imágenes muestran parte del proceso de creación de nueva cuenta y al final hay un ejemplo del captcha de audio.

El captcha de audio presentado por MSN es una lectura distorsionada de una serie de números que se oye así (WAV, 64Kb.). Vale hacer notar también que la grabación del captcha se presenta en castellano, como corresponde a un sitio mulilingüe.

Más Información

Si el tema te interesa, te recomiendo algunos lugares para buscar más información sobrecaptchas:

• Proyecto Captcha del Palo Alto Research Center
• Información en Wikipedia
• Proyecto Captcha, Carnegie Mellon University
• Una nota del W3C sobre los problemas de accesibilidad de los captchas
• Wikipedia hace notar la vigencia de una patente en EE.UU. que cubre el concepto

Desde hace tiempo tenía la intención de opinar respecto a los blogs como medio, sobre la comunidad y las expectativas que muchos se crean de esto. El impulso final me lo da la polémica sobre algunas supuestas irregularidades o faltas a la ética del senador Flores. Así que aquí voy.

Antes de comenzar con el factor humano, observé por un tiempo muchos blogs, pero me contuve de publicar el mío porque el formato me parecía muy narcisista, demasiado basado en el ego de personalidades con tendencias a la figuración. Aún creo que esto es verdad en muchos casos, pero me he demostrado que también se puede hacer de otro modo y que es posible utilizar el medio como una forma más de publicación, con características muy especiales e interesantes desde varias perspectivas.

Tengo la necesidad de compartir y publicar aquéllas cosas que me interesan de mi trabajo y mi permanente proceso de investigación y aprendizaje. Trato de hacerlo con la mayor seriedad y rigor. Soy responsable de lo que publico, y sé que entre los lectores de efh hay gente que está iniciándose en un mundo complejo como el del diseño y desarrollo web, así como otros profesionales con quienes comparto intereses y perspectivas, no necesariamente coincidentes, pero eso es parte del juego. Por lo mismo trato de documentar mis notas, aclarar mis dudas y no actuar de modo impulsivo. Tengo una responsabilidad hacia quienes me leen y confían en lo que publico. Esto es lo que procuro hacer en este sitio. También me tomo ciertas licencias y hago algunos paréntesis que son completamente personales, pero que también trato de hacer con respeto.

Lo mismo que hago ahora en efh lo hice en mi primera aventura web allá por 1999,directorzone.com, un proyecto personal en el que publicaba información sobre Macromedia Director, la primera herramienta en la que me especialicé a fondo.

Pero el hecho de que yo publique un blog, o que un millón de otras personas lo hagan no me familiariza automáticamente con ellas, no me hace parte de una comunidad. No por leer el periódico soy igual a todos los que leen el periódico. No por tener un blog soy parte de una comunidad. El medio es lo único común. Mi sitio no tiene nada en común con el fotolog de un estudiante que publica las fotos de la fiesta del fin de semana. Ni con el lo de alguien que desea ventilar sus intimidades públicamente. Tampoco con el de aquél que escribe temas serios, documentados, pero ajenos a mí. No me considero ni más ni menos que los anteriores, pero no somos lo mismo. Por lo tanto, desde mi perspectiva, la blogosfera es un concepto bastante débil. Tal vez las únicas formas reales de que estos espacios individuales se encuentren es en lugares como Technorati o Bloglines, en los que nuevamente es el medio, la tecnolgía el factor de cohesión.

Sí existe una comunidad entre quienes establecen una red de contactos y de comunicación por intereses compartidos. Yo leo los blogs de Dani Torres Burriel, de Juque, Juan Carlos García, Diego Lafuente, los chicos de Isopixel, Véase además, etc. (mis disculpas por las omisiones, pero ya entienden el punto), y muchos de ellos me leen a mí también. Eso es comunidad. Pero es en torno a ideas e intereses, no al medio. El medio es una circunstancia, claro que es facilitadora, pero no es más que eso.

Todo esto lo menciono porque vengo viendo repetidamente ideas sobre blogger power, ética del blog y otros sinsentidos más. Muchos de estos exabruptos surgen a raiz de la intención de comercializar con los blogs, desde el querer poner publicidad, hasta el cobrar por hacer cursos sobre el medio. Parece ser que ciertos personajes se toman el medio como una causa y no son capaces de ver más allá, respondiendo con intolerancia o quién sabe qué espíritu.

Es por esto que no he firmado la solicitud de Mi Primer PC, pero de verdad. Porque si bien coincido en algunos de los puntos, hay otros con los que no estoy de acuerdo. Por ejemplo, no estoy convencido de que Linux esté apto para usuarios no principiantes. Yo tengo varios años como usuario de PCs, conozco de programación y no se me prodría describir como primerizo o inexperimentado. Tengo en mi notebook una partición dual con WinXP y Fedora. Antes tuve Mandrake y Suse. Pero aún así he pasado horas en Linux solucionando problemas que deberían ser triviales de resolver. No le desearía esto a alguien que se enfrenta pr primera vez con un computador, la experiencia podría ser frustrante. Sí estoy convencido de que Linux es una muy buena alternativa en otros contextos y que en un tiempo más podrá competir con las interfaces gráficas de los OSs comerciales.

No pretendo abrir una discusión sobre el tema, entiendo muchas de las razones tras la falta de usabilidad en Linux. Soy usuario de muchas aplicaciones open source como OpenOffice, WordPress, etc. Mi punto es que la consigna de levantar a la comunidad bloguera, me queda grande. No existe tal comunidad. Y ya pasé algunos años luchando contra la dictadura(insertar ironía), tuve mi cuota de colectivismo.

Por eso los ataques al senador Flores, con quien no tengo ningún contacto, no soy lector de su blog, ni nada parecido, me parecen destemplados, carentes de análisis e irresponsables. Creo que la argumentación de Leo Prieto sobre el tema aclara la situación y deja fuera cualquier otra interpretación.

Por lo demás, si alguien quiere hacer de los blogs una forma de vida, vamos, todo es posible. Y si no te has enterado de los blogs corporativos, estás muy atrás en el asunto.

Continuando con la explicación sobre el uso de id y class en HTML, ahora corresponde revisar la segunda parte, cómo utilizamos estos atributos en CSS para aplicar diseño al contenido.

CSS utiliza selectores para identificar a qué parte de un documento se aplican los estilos. Los selectores son declaraciones de diversos tipos que permiten indicar con un nivel de detalle bastante preciso a qué se aplicarán las reglas de estilo. El selector más simple es el de elemento. Este selector identifica un elemento de HTML y aplica las reglas a todas las instancias de ese elemento en el documento. Por ejemplo:

p { font-size: 1em; }

En este caso, el selector determina que todos los elementos p utilizarán la regla indicada, según el ejemplo, su texto tendrá un tamaño de 1em. En consecuencia, este selector es uno genérico, que no permite un nivel de discriminación muy detallado. Se aplicará a todos los elementos que definamos, sin excepción.

Pero frecuentemente necesitamos seleccionar elementos con un grado de discriminación más refinado. Aquí es cuando entran los selectores id y class.

Cuando necesitamos seleccionar un elemento único dentro del documento para asignarle una regla específica, lo haremos a través del atributo que los identifica de modo exclusivo: el id. Como vimos en el post anterior, id permite identificar de modo único a un elemento, no puede haber dos elementos con un id con el mismo valor. Si por ejemplo tenemos un elemento definido como id="contenido", en CSS nos referiremos él del siguiente modo:

#contenido { margin: 1em 2em; }

Siempre que deseemos referirnos en CSS a un elemento con un id n, antepondremos el caracter # y luego, sin espacios, el id: #n.

En otras ocasiones necesitamos referirnos a un grupo de elementos que comparten una clase común. En el ejemplo del post anterior, mencionábamos una clase nota para identificar a párrafos usados como notas al pie. En este caso seleccionaríamos a estos elementos del siguiente modo en CSS:

p.nota { border: 1px solid #CCCCCC; }

El uso de class nos permite seleccionar un rango mayor de elementos. Hay una serie de usos más avanzados de este selector, además de otros más avanzados. Incluso es posible combinar diferentes tipos de selectores, pero eso queda para otro post, recordemos que esto es una introducción.

Para finalizar, en un post anterior titulado CSS y Semántica traté este tema un poco más profundamente.

Hace un par de días me escribió un lector de EFH para preguntarme la diferencia entre id yclass. Según mi experiencia en capacitaciones a equipos de diseño y clases en la universidad puedo decir que éste es uno de los conceptos que más cuesta asimilar cuando comienzas a trabajar en el esquema de HTML/CSS. Por lo tanto, aquí va mi aporte para aclarar las dudas.

Presentación y Contenido

Lo primero que tenemos que entender es que la idea tras el uso de CSS, es separar el diseño o presentación, del contenido. Esto suena simple pero es un concepto que toma tiempo dimensionar. Partamos por hacer algunas definiciones.

¿Qué es presentación? Todo aquello que sea una característica visual es presentación. Colores, espaciado, alineamiento, fuentes, tamaños, disposición, etc., son todos factores de diseño, que nada tienen que ver con el contenido.

Por otro lado, ¿qué es el contenido? Es el motivo para crear una página. Es el texto, imágenes y otros medios de los que trata un documento. Sí, dije imágenes y no fue un error. Hay que hacer una distinción importante, sin embargo: algunas imágenes son contenido, otras son presentación. Son fáciles de diferenciar, por ejemplo, la fotografía que acompaña a una noticia es contenido, porque aporta información y lo complementa. Una imagen usada como bullet en una lista es presentación, porque no aporta información al contenido, aunque haga la lectura más fácil o permita diferenciar los elementos que destaca.

Pero en el contenido hay un elemento subyacente que es clave para la separación real de contenido y presentación. Se trata de la estructura.

Estructura del Contenido

El contenido no sólo es el texto y los medios que constituyen la información. También es parte del contenido la estructura interna de éste. Esta estructura está dada por los tipos de datos, las relaciones internas y la jerarquía. Aquí es donde entra HTML.

HTML es un lenguaje de marcado, o para ser más claros, de descripción de contenidos. Cada elemento dentro de HTML está compuesto de dos partes: su contenido y la semántica. Veamos el siguiente ejemplo:

<h3>Estructura del Contenido</h3>

En este caso, el contenido es Estructura del Contenido, pero eso no es todo. Por sí sola, esa frase no tiene contexto ni otro tipo de información adicional, es sólo texto. Pero el hecho de estar encerrada en el elemento H3 de HTML entrega la información restante: este elemento es un título de tercer nivel, por lo tanto es un texto importante, es más importante que un párrafo, y probablemente define el contenido que sigue después de él. Pero es menos importante que un H2 o un H1, que definen contenido de mayor alcance dentro del documento.

Del mismo modo, cada elemento en HTML, y en mayor medida en XHTML, que busca depurar el vocabulario para eliminar los elementos de presentación, tiene un significado preciso. Sólo por nombrar algunos, A define el contenido como un vínculo y sus atributos hablan del destino (href), descripciones (title), idioma (lang), etc., STRONG y EMindican peso y énfasis, y así con los demás elementos.

Class y ID

En HTML y XHTML los atributos son información adicional que se aplica a los elementos. Por ejemplo, en el elemento IMG el atributo src indica la fuente o source para la imagen, su ubicación. Este atributo es específico para el elemento IMG, del mismo modo muchos elementos tienen atributos exclusivos. Pero hay otros que son globales y pueden ser aplicados a prácticamente cualquier elemento.

Dos de estos atributos comunes son id y class.

El atributo id permite identificar de modo único a un elemento dentro de un documento. De hecho id es la abreviación de identificador. Por lo tanto, sólo puede haber un único elemento con un identificar determinado. Por ejemplo, si un elemento tiene un id con valorpost-225 (id="post-225"), no podrá existir otro elemento en el documento que se llame igual.

El atributo class, en cambio, define la clase o tipo de un elemento. Por ejemplo, si observamos que frecuentemente utilizamos notas al pie en nuestros documentos, podemos crear una clase que se llame nota. Y la asociaremos a párrafos (P) que utilicemos para las notas:

<p class=”nota”>Esta es una nota al pie de página.</p>

Por definición, podemos asociar una clase a muchos elementos dentro de un documento, en cada caso estaremos diciendo: este elemento es de la clase o tipo X.

Como verás, la diferencia ahora es evidente. ¿Pero cómo uso esto para aplicar presentar el contenido con CSS? Eso lo explicaré en el próximo post con más detalle.