Categoría 'TECH'

Desde que realicé el proyecto final de carrera (Ingeniería informática en la UIB) sobre análisis de logs de servidores web (web data mining), me he preguntado por qué esa disciplina se trataba de un modo tan independiente (y habitualmente por expertos también independientes) al de la usabilidad web. Al fin y al cabo, ¿no se trata de conocer cómo utilizan los usuarios la web? Cuando se dicen cosas como "nuestros usuarios son así", o "la mayoría de usuarios utilizan más esta funcionalidad", ¿hasta qué punto se saben realmente?

Cualquiera que haya tratado mínimamente con las técnicas de análisis web sabe que extraer conclusiones del análisis de accesos es mucho más complicado de lo que podría parecer: filtrar bots, identificar usuarios únicos y sesiones,… Las técnicas que se utilizan son siempre heurísticas que dan resultados aproximados y que hay que saber interpretar.

Hasta que hace unos días he leído un artículo en el blog de Xperience Consulting que se plantea si ambas disciplinas son contrarias una a la otra. La respuesta es, obviamente, que no; no son opuestas, sino complementarias. Como dice Avinash Kaushik, la analítica web nos dice QUÉ están haciendo los usuarios, mientras la usabilidad web nos dice POR QUÉ lo hacen.

Por ejemplo, una herramienta de análisis web (como Google Analytics) nos puede indicar que un gran número de usuarios abandonan un proceso de compra de 4 pasos en el tercer paso, pero no nos dirá por qué. Para eso podemos hacer un estudio de usabilidad con usuarios reales y comprobar que no pasan de ese punto porque les obliga a introducir un dato que no entienden.

Sin embargo, en muchas ocasiones estas técnicas son explotadas de manera independiente: el departamento de Sistemas (o el de Márqueting) hace un análisis de los accesos, mientras que por otro lado el departamento de Desarrollo o Diseño web utiliza (si lo hace) técnicas de usabilidad web. Aunque parece que la cosa podría mejorar con nuevas metodologías de desarrollo.

(sigue …)

A partir de ahora os invito a que leáis un nuevo blog que lleva por nombre METAeuFORiAS.es, y en el que espero publicar de vez en cuando artículos interesantes que consistan, básicamente, en una metáfora. Y por 'metáfora' me refiero a comparaciones entre dos elementos que puedan parecer poco relacionados, pero que tengan aspectos comunes que puedan hacerlos más inteligibles, e incluso hacer descubrimientos interesantes al aplicar lo que sabemos de uno al otro.

Como muestra, el ejemplo que pone la RAE en la definición de metáfora ("el átomo es un sistema solar en miniatura") nos permite hacernos una idea de la estructura del átomo, suponiendo que conocemos la del sistema solar. Las metáforas no son nunca perfectas, ya que los elementos comparados no son idénticos, pero incluso las diferencias entre los elementos comparados permiten extraer conclusiones interesantes.

Por si no os habíais dado cuenta, esa metáfora entre un átomo y el sistema solar es la que inspira el logo de METAeuFORiAS

El primer artículo de METAeuFORiAS, que compara Google con el funcionamiento del cerebro, es una adaptación de otro que escribí en este mismo blog.

¿Por qué un nuevo blog sobre metáforas?

Tengo la impresión de que la mezcolanza de temas que tiene este blog personal hace que, a pesar de que ciertos artículos puedan resultar interesantes para un perfil determinado de usuarios, en general sea difícil que se enganchen de manera más continua al blog. De ahí el interés en crear un nuevo blog con una temática y estructura más homogéneas.

Y el tema de las metáforas me parece más que interesante, sobre todo desde una conferencia de Eduard Punset a la que asistí y en la que afirmaba que la verdadera característica que nos separa, como humanos, del resto de animales, es la capacidad de crear metáforas; y que son una herramienta poderosísima para el avance cultural y tecnológico. ¡Ah!, y también afirmaba que los informáticos son (somos) especialmente buenos en utilizar metáforas. ¿Hacían falta más motivos?

Mi primera idea fue crear una herramienta (tipo wiki) para que las metáforas fueran creadas, mantenidas y ampliadas de modo colaborativo; de ahí el proyecto Wikiphora que presenté a la beca Alzado y que, al igual que el otro proyecto que presenté (TALAIOT), dejo publicado para que, si alguien se anima a participar en su desarrollo, se ponga en contacto conmigo. La presentación se lee en un par de minutos: PROPUESTA WIKIPHORA (PDF, 104KB)

Así que creo que merece la pena un blog que explote esa capacidad de crear metáforas. Os animo a todos a que sigáis el nuevo blog, que os subscribáis a él, y que lo deis a conocer a todos aquellos que consideréis como posibles interesados. Y, por supuesto, que hagáis vuestras aportaciones a las metáforas a través de los comentarios.

Leo un artículo en el blog de Ricardo Galli titulado Tratar al código fuente como un ensayo que me ha vuelto a crear una conexión entre dos temas que en principio parecen poco relacionados pero de los que se puede extraer alguna enseñanza común; en este caso, la programación y la redacción de textos para la web.

Ricardo habla de un libro (Beautiful Code) y, más concretamente, de un capítulo titulado como su artículo: Treating Code As an Essay. En él se señala la similitud entre el código fuente de un programa y un ensayo, en el sentido de que, si bien en ambos casos su propósito es lo fundamental ("¿de qué se trata?"; "¿qué hace?"), no debe descuidarse el estilo en que están escritos, ya que no sirven de nada si no pueden ser interpretados por seres humanos.

A continuación rescata algunas reglas generales para escribir código de calidad:

• Brevedad: La brevedad es una virtud, definitivamente hay un coste de lectura para el ojo humano, el código debe eliminar la información redundante
• Familiaridad: Las personas son más conservadoras de lo que pensamos. Las curvas de apredizaje elevadas creean estrés y reducen productividad. Un lenguaje no debe obligar a los progamadores a trabajar con conceptos nuevos y complejos. No ser demasiado innovador es también una ayuda para el “código bello”.
• Simplicidad: Si un programa es complicado de entender no puede tener belleza.
• Separar bloques: Separar los bloques lógicos en cada función, así se facilita la lectura más rápida y en “diagonal”.
• etc.

Inmediatamente me han venido a la memoria las reglas que da Jakob Nielsen para escribir para la web; de hecho, algunos de los puntos son prácticamente idénticos: simplicidad, brevedad, lenguaje familiar, etc. Y es que, pensándolo un poco, las situaciones no son tan diferentes:

(sigue …)

En el capítulo de House de la semana pasada, durante una discusión, el ácido doctor soltaba el siguiente razonamiento:

Si quieres que la gente conduzca mejor, quita los airbags y pon un machete apuntando al cuello; nadie pasará de 10 por hora.

Drástico pero acertado, como casi siempre. La frase es para hacerle pensar a uno; parece obvio que es conveniente mejorar la seguridad de los automóviles pero… ¿de verdad se reducen los daños cuando se aumenta la seguridad de los vehículos?

Me recordó a algo que leí sobre los cascos de fútbol americano y la llamada teoría de compensación del riesgo; en la década de 1.940 se introdujeron los cascos de plástico en la liga norteamericana, lo que suponía una mayor protección para los jugadores. Sorprendentemente, las estadísticas mostraron que después de la introducción de esos nuevos cascos las lesiones relacionadas (cuello, cabeza) habían aumentado considerablemente.

¿Qué ocurría? Los jugadores de fútbol americano, al sentirse más protegidos por los nuevos cascos, actuaban de forma más arriesgada y usaban la propia protección del casco como elemento ventajoso. Y eso mismo es lo que expresa la teoría de compensación del riesgo:

(sigue …)

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. (sigue …)

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: (sigue …)

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"

(sigue …)

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]….

(sigue …)

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.

¿Qué indica Google al respecto? Como ya comentaba en otro artículo, los detalles de su algoritmo de búsqueda no son públicos. En concreto, respecto al orden de los resultados, Google afirma que:

Google's order of hits is determined by a combination of several factors, including PageRank priorities. Please check out our Why Use Google page for more detail, or take a look at Larry and Sergey's article The Anatomy of a Large-Scale Hypertextual Web Search Engine for pleasure reading. (Google General FAQ)

Es decir, pocas pistas.

¿Demasiado listo?

¿Es útil este funcionamiento? A mí se me antoja entre desconcertante y molesto. En las Preferencias, en el apartado "Idioma de la interfaz", se indica claramente "Mostrar consejos y mensajes de Google en: español". En ningún momento parece que esta elección vaya a influir en los resultados de la búsqueda; para eso existen otras opciones (por ejemplo, las que permiten buscar "páginas en español" o "páginas de España").

Parece que Google viola ese principio casi sagrado para los desarrolladores de separar presentación y comportamiento. ¿Por qué funciona así? Es posible que sea debido a una "sobreprotección" del usuario: "bien, estás viendo la interfaz en español, así que te voy a mostrar primero algunas páginas en ese idioma, aunque no sean las más populares". A mí me recuerda al (im)popular clip de Microsoft Office: la intención es buena, pero molesta que se pase de listo.

Puede que ordenar así los resultados resulte útil para usuarios con poca experiencia y/o escasos conocimientos de inglés, pero aún así puede resultar incluso peligroso. Por ejemplo, he visto casos en que la búsqueda de un determinado programa software devolvía como primer resultado una página en español de descarga previo pago, cuando la página oficial del programa (en inglés) lo ofrecía totalmente gratis.

Y para el resto de usuarios, resulta todavía más molesto. Puedo tener la interfaz configurada en español, pero si tengo facilidad para leer en inglés no quiero que los resultados más relevantes se vean desplazados por otros únicamente porque estén escritos en español.

"Soluciones"

Básicamente, Google debería mostrar claramente cómo afecta la configuración de idiomas a los resultados de la búsqueda. Si el idioma de la interfaz va a afectar al resultado, como mínimo debería mostrarse un aviso en las Preferencias (aunque, por lo que hemos visto, difícilmente se le puede seguir llamando únicamente "idioma de la interfaz").

En cualquier caso (y a mi modesto entender), sería más lógico que el idioma de la interfaz no afectara al orden de resultados. Si Google quiere "favorecer" los resultados en determinado idioma, sin filtrar los demás, ¿por qué no simplemente añadir una opción nueva en las opciones de búsqueda, y que sea el usuario el que decida?:

Buscar en: la Web la Web (primero páginas en español) sólo páginas en español páginas de España

Mientras tanto, estoy utilizando una solución que me permite buscar de ambos modos: después de instalar la barra de herramientas de Google en Firefox, me encontraba con dos cuadros de búsqueda en el navegador con la misma funcionalidad: buscar en www.google.es:

Ahora he configurado el buscador incorporado de Firefox (arriba a la derecha) para lanzar una búsqueda en el servidor www.google.com, de modo que puedo utilizar este último para las búsquedas "normales" en inglés (por ejemplo, si busco la última versión de un programa), y usar el de la barra de herramientas de Google (abajo a la izquierda) para las búsquedas "en español" (por ejemplo, para buscar información sobre un ayuntamiento de España).

Si quieres añadir esa búsqueda (sin redirección de idioma) a tu buscador de Firefox, añade este motor de búsqueda desde mozdev.org.

¿Alguien tiene más información sobre cómo se ordenan realmente los resultados, en función del idioma?

Esto es lo que me he encontrado en mi bandeja de entrada:

Serán las cosas de la publicidad del Día del Padre.

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)

(sigue …)

(visto en un tablón de anuncios del Ágora de la Universidad Politécnica de Valencia)

Paradojas del Access

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.