Ayer tuve la ocasión de experimentar sufrir un proceso de compra de entradas a través de Internet, de esos que te dejan la duda existencial:

¿Realmente les interesa que la mayor cantidad de usuarios puedan comprar por Internet, o piensan que no es justo que la cosa sea tan cómoda, y ponen algunas dificultades para que el usuario demuestre que merece el privilegio?

En concreto me refiero a la compra de entradas para el Pamesa Valencia de baloncesto. Además de algunas cuestiones más o menos obvias (por ejemplo, usar una dirección numérica en la URL no da mucha confianza a la hora de realizar una transacción económica), la selección de la zona del pabellón utiliza esta imagen como ayuda:

Sí, este es el tamaño real de la imagen, y sí, los números de la parte inferior de cada zona son los que sirven para identificarla a la hora de seleccionar las entradas. Difícil, ¿verdad? Ahora preguntad conmigo: ¿qué les costaba poner la imagen un poco más grande, o al menos, los dichosos numeritos? ¿Qué necesidad había de forzar a los usuarios a utilizar una lupa o dejarse varias dioptrías en el proceso de elegir la sección?

Y si al menos se pudiera seleccionar la zona haciendo click sobre ella… pero no. Es necesario leer intuir el número y utilizar el enlace correspondiente.

Y eso no es todo. (más…)

En contra de lo que suele ser habitual, recojo hoy el meme que ofrece Torres Burriel y que consiste en contar cuál es el artículo más visitado del blog (muchas veces para consternación y/o sorpresa del autor).

Pues bien, resulta que en este blog el artículo más visitado es este: ¿Qué es un ‘framework’?, que intenta ser una explicación sencilla y lo suficientemente general de lo que significa el término ‘framework’ (y que, de tanto usarlo, creo que cada vez está más difuminado).

¿Alguien más se anima a explicar cuál es su artículo más visitado?

Leo en torresburriel.com una referencia a un artículo sobre los problemas de usabilidad que pueden provocar las aplicaciones o componentes software de terceros; es decir, piezas de software que no pertenecen a la plataforma original y que son desarrollados por separado. Por ejemplo, esa encuesta o ese juego que insertas en tu página web, o tus últimas fotos, etc.

En este caso el peligro es que normalmente tenemos menos control sobre esos componentes, y por tanto su usabilidad puede estar bastante más descuidada que la de la aplicación en la que están insertados, del que tenemos mayor control, y al que prestamos mayor atención.

Para evitar esos peligros, nos ofrecen 3 consejos:

1. Negociar en los acuerdos que se mantengan los estándares de usabilidad.
2. Incorporar tus estándares de usabilidad como requisito obligatorio para integrar aplicaciones de terceros.
3. Trabajar junto con tu proveedor para fomentar la usabilidad como requisito en su proceso de desarrollo.

Ambos artículos y los consejos (que, dicho sea de paso, parecen un tanto redundantes) me provocan algunas reflexiones: (más…)

Recuerdo cómo un compañero de trabajo, en medio de una conversación informal, se cuestionaba que habitualmente se incluya al correo electrónico dentro de las llamadas “nuevas tecnologías“, cuando es un sistema que tiene ya más de 40 años de existencia; razón no le faltaba.

Aún así, tengo la impresión de que el correo electrónico, a pesar de ser una herramienta de trabajo y entretenimiento básica para muchos millones de personas, está todavía lejos de ser una tecnología totalmente desarrollada en todo su potencial.

Las novedades más llamativas suelen ser más cuantitativas que cualitativas, ofreciendo más espacio o mejores buscadores (como en el caso de GMail), útiles pero no revolucionarias.

Y no me refiero ya al problema del spam (que puede ser desde curioso para algunos a exasperante para otros muchos), sino a que lleva muchos años funcionando básicamente del mismo modo, sin incluir avances o mejoras dignas de grandes menciones. Puede que no las echemos en falta porque estamos ya muy acostumbrados a su funcionamiento, pero considero que todavía están por implementarse las mejoras definitivas que harán del correo electrónico una herramienta mucho más útil y potente. Estas son algunas de ellas.

“Para” y “Cc:” parecen lo mismo, pero no lo son

En la práctica, ambos campos son utilizados de modo indistinto, ya que su efecto es el mismo: el destinatario recibe el mensaje. Pero los campos de destinatario (”Para:”) y con copia (”Cc:”) deberían estar más diferenciados, sobre todo en la “bandeja de entrada” de los receptores del mensaje. Los mensajes en los que eres el destinatario directo reclaman, en principio, mucho más tu atención que aquellos de los que simplemente recibes una copia. ¿Y si los primeros aparecieran resaltados o, simplemente en bandejas de entrada diferentes?

Ahora mismo, al enviar un mensaje para múltiples personas, no pensamos demasiado si colocamos una dirección en un campo u otro. Pero conocer que la recepción va a ser diferente en cada caso, nos permitiría distinguir claramente las personas que realmente son los destinatarios de la información, de aquellos que únicamente tienen que estar al corriente.

Casi podríamos simplificarlo así:

• Para: “tienes que leerlo” (y, posiblemente, contestar o hacer algo)
• Cc: “tienes que saber que se ha enviado”

(más…)

Hace poco, en una de esas sesiones de navegación aleatorias que todos realizamos de vez en cuando, acabé leyendo una curiosa noticia sobre un conflicto legal relacionado con marcas de papel higiénico, con párrafos tan interesantes como este:

Según los demandantes, dicha marca resultaba violatoria de la legislación andina sobre propiedad industrial toda vez que constituye un signo descriptivo que da a conocer al público consumidor las características propias del producto: dos rollos de papel higiénico contenidos en uno.

No deja de ser divertido que los litigios legales lleguen hasta la denominación que le podemos dar al material que usamos para tan higiénica tarea.

Pero no nos engañemos; en el entorno de las nuevas tecnologías no nos libramos de tales farragosidades jurídicas. De hecho, son peores, ya que frecuentemente provienen de personas y organizaciones que nadan (¿naufragan?) en un medio que apenas conocen pero al que intentan aplicar usos y hábitos de las “viejas tecnologías” (valga la expresión).

‘Este mensaje va dirigido a su destinatario’ (¡no me digas!)

No me refiero únicamente al sinsentido de equiparar la copia de contenidos digitales con un robo, que probablemente sea el que más conocemos. Sin ir tan lejos, casi todos habremos recibido algún correo electrónico que incluye un texto al final, muchas veces en varios idiomas, parecido a este:

Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial cuya divulgación no está permitida por la ley. [bla, bla, bla..] . En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que [más bla bla bla]….

(más…)

Más de una vez nos sorprendemos cuando, al buscar utilizando Google, los primeros resultados corresponden a páginas con contenidos escritos, no en inglés, sino en español (o en el idioma de la interfaz establecido en las preferencias de idioma de Google y que afecta al idioma de los consejos, de los mensajes, etc.).

Por ejemplo, busquemos ‘Firefox‘ en www.google.es, en páginas escritas en cualquier idioma, pero con la interfaz de Google configurada en español:

Vemos que aparecen antes los resultados de páginas en español que las del sitio oficial “central” en inglés. Sin embargo, en las opciones de búsqueda NO hemos limitado a páginas en un idioma concreto, y parece seguro que las páginas en inglés son más relevantes (cosa que se puede comprobar con esta búsqueda). Otros usuarios han destacado, en diferentes foros, ese mismo funcionamiento.

Al parecer, el orden de los resultados (en lo que respecta al idioma) puede depender tanto del idioma de la interfaz como del servidor Google concreto que se utiliza (google.com vs. google.es) e incluso, de la geolocalización del usuario (es decir, el orden de los resultados será diferente buscando desde un ordenador en España o desde uno en Estados Unidos). Y posiblemente también dependa de la localización geográfica del sitio que haya indicado su webmaster.

(más…)

Después de desarrollar varias aplicaciones utilizando Microsoft Access, uno descubre que existen algunas prácticas y formas de trabajo que simplifican su desarrollo y el mantenimiento, sobre todo cuando la aplicación empieza a crecer más de lo que tenías previsto (cosa que suele pasar casi siempre).

Seguramente Access no es una base de datos que pueda soportar una gran aplicación con multitud de usuarios accediendo al mismo tiempo, que maneje una gran cantidad de datos, o con requisitos complejos de rendimiento o seguridad. Pero como herramienta que permite implementar una aplicación completa (desde las tablas de datos hasta interfaces de pantalla o informes impresos) para unos pocos usuarios de manera rápida, hay que reconocer que tiene pocos rivales. Los desarrollos con Access son tan rápidos que puede utilizarse como una herramienta de prototipado que ayude a definir claramente los requisitos de usuario antes de pasar a un sistema más potente.

1. Define bien las tablas y sus relaciones

Los desarrolladores conocen lo importante que es tener un buen modelo de datos en su aplicación. Y en Access, eso se convierte en la pantalla de Relaciones (dentro del menú Herramientas):

Es decir, define globalmente los campos de cada tabla y las relaciones entre tablas, para toda la aplicación, tal como son en la realidad (no como deberían ser). No definas tablas, campos y relaciones para necesidades puntuales que puedas tener en un formulario o informe concreto.

En concreto, evita las listas de valores y conviértelas en tablas. Si vas a guardar todos tus CD y libros en la base de datos, no introduzcas el “tipo de objeto” como una lista de valores en un campo de la tabla “Objetos” o de un formulario; mejor crea una tabla “Tipos de objeto” y guarda los valores “libro” y “CD” como registros. Si más adelante quieres añadir un nuevo tipo de objeto (como “DVD”), bastará añadirlo a la tabla y te evitarás tener que buscar todos los puntos donde está especificada la lista de valores.

[Actualización 03-mar-2008]

Tal como indica javieran en un comentario, es conveniente crear las relaciones desde el diseño de tablas. Para eso, basta con seleccionar la pestaña “Búsqueda” y la opción “Mostrar control” > “Cuadro combinado”, seleccionando una tabla como “Origen de la fila”; todo esto cuando se defina un campo que obtiene los valores de otra tabla previamente creada (lo que se conoce como “clave externa“).

Siguiendo con el ejemplo anterior, se trataría de utilizar esa opción cuando se defina, dentro de la tabla “Objetos”, el campo “Tipo de objeto” para que indique si cada registro es un libro, un CD o un DVD.

Esta acción tiene dos efectos:

• En vez de un cuadro de texto, la interfaz de Access mostrará automáticamente un cuadro combinado para seleccionar uno de los valores existentes.
• Se crea una relación entre ambas tablas (por defecto, sin integridad referencial)

(más…)

Os presento aquí uno de los dos proyectos que envié a la beca Alzado y que, obviamente, no fueron premiados. Como ya expresé en un comentario en Alzado (comentario núm. 4), creo que los criterios de la beca podrían haber estado mejor definidos, pero el motivo de escribir este artículo es otro.

Las ideas están sólo esbozadas y (todavía) no tienen “cuerpo”, aunque me gustaría poder desarrollarlas en algún momento. Sería muy optimista pensar que voy a hacerlo yo sólo, así que antes de que se pierda en el olvido, prefiero dejarlo aquí explicado de modo que, si alguien quiere colaborar en ponerlo en marcha o tiene alguna aportación que hacer, pueda contactar conmigo.

TALAIOT

El objetivo de este proyecto sería proporcionar a los usuarios alguna herramienta que les permita seguir las modificaciones en páginas que les interesen, incluso para aquellas que no las publiquen de modo explícito con sistemas como RSS o similares.

Esto permitiría, por ejemplo, enterarnos de nuevos comentarios en artículos de blogs, conocer cambios en nuestras páginas de del.icio.us, o saber cuándo se modifican las páginas de la competencia.

Este proyecto constaría de dos partes:

1. Crear un sistema que permita valorar (numéricamente y automáticamente) las modificaciones que se producen en cualquier página HTML, a partir del análisis de su código y a partir de determinados algoritmos.
2. Ofrecer un sistema que permita a los usuarios utilizar ese sistema para recibir notificaciones cuando se produzcan cambios en las páginas en las que estén interesados.

Aunque no hay nada inamovible, mi intención inicial era utilizar Ruby on Rails (y aprender de paso) para el desarrollo, dedicándole especial atención a dos elementos clave (a mi entender) en cualquier aplicación: el esquema de base de datos por un lado y a la usabilidad de las interfaces por el otro.

Propuesta TALAIOT (PDF, 334KB)

Os invito a que leáis la presentación de la propuesta (se hace en un par de minutos), a que hagáis vuestras aportaciones mediante los comentarios de esta entrada, y a que os pongáis en contacto conmigo si queréis colaborar de algún modo en ella. Gracias.

Leo en los últimos días la enésima discusión sobre usabilidad vs. accesibilidad; sin ir más lejos, en Accesibilidad, Usabilidad y Estandares Web, en Inclusión, o en la lista de correo Cadius.

La cosa suele empezar con una afirmación o pregunta sobre si:

• La usabilidad es parte de la accesibilidad.
• La accesibilidad es parte de la usabilidad.
• Usabilidad y accesibilidad son complementarias.
• Usabilidad y accesibilidad apuntan, en ocasiones, en sentidos opuestos.

Y después siguen definiciones más o menos formales, casos prácticos y visiones personales que suelen acabar por agotamiento más que por llegar a alguna conclusión.

Sinceramente, creo que se trata de un debate poco productivo, del que se pueden sacar pocos resultados útiles o prácticos. Y lo creo porque la cosa es bastante más sencilla que todo eso.

¿Para quién?

Huyendo de definiciones universales y cuestiones metafísicas, hagamos un ejercicio de simplicidad y digamos que:

• accesible = que se pueda acceder a ello
• usable = que sea fácil de usar

A partir de ahí, las conclusiones son bastante sencillas:

• Accesible o usable son términos relativos. Cuando los veamos utilizados de modo absoluto (”la página X es accesible”, “el sitio web Y es poco usable”) deberíamos siempre hacernos la misma pregunta mental: “¿accesible/usable para quién?”
• Para que algo sea fácil de usar, es necesario que se pueda usar. Por eso, para un mismo perfil de usuario, usable implica accesible (pero no al revés). O dicho de otro modo, la accesibilidad es condición necesaria (pero no suficiente) para la usabilidad.

Así de sencillo.

Otra cosa es que se pueda discutir, por ejemplo, que una interfaz sea más usable para un perfil de usuario, pero menos accesible para otro perfil de usuario.

Por ejemplo, ¿es la interfaz AJAX de Google Mail más usable que la versión simple HTML? Casi todos estaremos de acuerdo en decir que sí, para los usuarios con navegadores que soporten JavaScript. Para el resto de usuarios no tiene sentido preguntar si es usable cuando simplemente no pueden acceder a ella (por eso necesitan una versión alternativa).

En resumen, muchas de esas discusiones pierden su sentido si no se responde a la pregunta “¿para quién?”.

El trabajo en Valencia, en el grupo SQUaC, me está permitiendo realizar algunas actividades que difícilmente hubiera podido llevar a cabo antes. La cosecha del 2007 (¡qué pronto se nos antoja antiquísima una fecha del año pasado!) dejó, entre otras cosas, la publicación de un artículo sobre testeo de software y una ponencia en Madrid sobre accesibilidad web.

La ponencia: accesibilidad web

En noviembre di una charla dentro de Expo:QA 2007, un congreso sobre calidad de software que tuvo lugar en Madrid. La ponencia tenía como título “Accesibilidad web: principios, mitos y algunos ejemplos prácticos“, y trata sobre principios y ejemplos relacionados con el objetivo de conseguir que el mayor número de usuarios puedan acceder a los contenidos de la web, no sólo los discapacitados, porque… (si quieres saberlo, tendrás que leer la presentación).

La presentación está colgada, en formato PDF, en la web de Expo:QA. El contenido se entiende bastante bien, a pesar de que está pensada para acompañarse de las explicaciones que dió en su momento este que os escribe.

Hay referencias a la presentación en el blog de SQUaC, y en otros sitios web como este, este o este.

El artículo: recetas para el diseño de casos de testeo

El artículo, escrito junto a la responsable del grupo SQUaC, Tanja Vos, forma parte de los proceedings de las IV Jornadas sobre Testeo de Software (JTS2007) que tuvieron lugar el año pasado. Por cierto, este año estamos en plena preparación de las V Jornadas, JTS2008, que os recomiendo desde aquí.

La primera parte del artículo consiste en una introducción al testeo de software, incluyendo algunas definiciones básicas, que creo que puede resultar interesante tanto para aquellos a los que el software testing les suena a chino, como para aquellos interesados en el tema que quieran aclarar conceptos.

(más…)