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 …)

He hecho algunas modificaciones en los últimos días en la página; no son muy espectaculares ni de gran importancia, pero os las cuento.

El botijo

Para empezar, la más visible: he cambiado el logo de la página. El curioso botijo que podéis ver en la parte superior izquierda es una versión “regional” de la famosa tetera del libro de Don Norman, “The Design of Everyday Things“, y es una idea que le he tomado prestada a Juan Carlos García, de Úsalo. Se trata de un ejemplo exagerado de cómo los malos diseño nos complican la vida; imaginad el sinsentido de intentar utilizar una tetera o un botijo como esos.

Lo malo de no ser diseñador es que nunca consigues una realización tan buena como la que tienes en mente, pero para una página personal como esta me sirve de momento. Por supuesto, se aceptan opiniones

(sigue …)

Casi todos los que nos hemos dedicado en algún momento al desarrollo de aplicaciones reconocemos la importancia de mantener separados el contenido y la presentación; es decir, independizar qué hace la aplicación de cómo lo muestra al usuario. Yendo un paso más allá, el patrón MVC propone una separación del software en tres partes:

• Modelo (model): la información con la que trabaja la aplicación (”los datos”). Habitualmente esta parte está soportada por un sistema de base de datos.
• Vista (view): cómo interacciona el usuario con la aplicación (”la interfaz”). En una aplicación web suele utilizarse HTML y CSS.
• Controlador (controller): las acciones que realiza la aplicación (”el comportamiento” o “la lógica”).

Muchos frameworks de desarrollo siguen este patrón, ya que las ventajas de esa separación son múltiples: la aplicación resulta más modular, más flexible, facilitando cambios en una de las partes sin necesidad de modificar el resto.

Por ejemplo, una aplicación desarrollada siguiendo ese patrón permitiría fácilmente cambiar el gestor de base de datos (el modelo) sin necesidad de modificar el resto de la aplicación; o desarrollar cada una de las partes de modo independiente; o acceder a la misma aplicación desde diferentes dispositivos como navegadores web o móviles, simplemente creando diferentes vistas.

¿Este patrón no queda del todo claro? ¿Sus ventajas no resultan tan evidentes? Puede que lo comprendamos mejor si establecemos un símil con algo que casi todos conocemos: la estructura de los teléfonos móviles.

(sigue …)

I have recently inserted the Flash badge for Twitter in my site; but the original code offered by them is not valid HTML. So why not use code that passes validation? Here it is:

<div style="width: 176px; text-align: center"><object width="176" height="176" title="what am I doing... (Twitter badge)" type="application/x-shockwave-flash" data="http://twitter.com/flash/twitter_badge.swf">
<param value="http://twitter.com/flash/twitter_badge.swf" name="movie" />
<param value="color1=255&type=user&id=USER_ID" name="flashvars" />
<param value="high" name="quality" />
<param value="twitter_badge" name="name" />
<param value="always" name="allowScriptAccess" />
<param value="transparent" name="wmode" />
<param value="http://www.macromedia.com/go/getflashplayer" name="pluginspage" /></object>

<a style="font-size: 10px; color: #0000ff; text-decoration: none" href="http://twitter.com/USER_NAME">

follow USER_NAME at http://twitter.com</a></div>

And the result is (using my own user data):

Just some comments:

• Don’t forget inserting your actual USER_ID and USER_NAME (and your preferred color1 parameter if you want to); you can get them at Twitter’s badges page.
• The & strings are not part of the URL but the correct way to write ampersands in HTML code; more information about ampersands in URLs can be found here.
• More information about inserting Flash using valid (X)HTML can be found here.

Pues sí, ya que es inevitable, aprovecho para desearos que el nuevo año sea mejor que este (sobre todo, mejor que los últimos días). Y que los buenos propósitos e intenciones duren hasta más allá del… ¿15 de enero?

Para seguir con las tradiciones, aquí dejo (para posterior arrepentimiento y escarnio público) mi propósito para el 2007: rediseñar esta página, más por cumplir con los estándares y evitar la maquetación con tablas que por mejorar la estética (la de la página, no la mía).

Y que nos leamos mucho este año.

Hace algunos días, buscando información sobre un libro, me encuentro con esta pantalla de error en una conocida librería virtual:

Un tanto intimidatorio, ¿no os parece? El mensaje de error es muy poco informativo; el usuario se encuentra bastante perdido: ¿”Razones técnicas”? ¿Qué puedo hacer ahora? ¿Volver a intentarlo? ¿Debo avisar a alguien?

Es fácil encontrar artículos y recomendaciones a la hora de diseñar pantallas y mensajes de error, y es conveniente tenerlos en cuenta en el diseño de una aplicación web, algo que muchas veces olvidamos; ¿cuántas veces nos encontramos, navegando en algún sitio de Internet, con las páginas de error por defecto que ofrecen información escasa y puramente técnica?

Sin embargo, para lo que no existen recetas mágicas es para la selección de las imágenes que acompañan a los mensajes. No es mala idea incluir un elemento gráfico que indique de manera casi instantánea y clara que algo no esperado ha ocurrido; pero la imagen elegida en este caso resulta casi agresiva. De hecho, parece más adecuada a un error de tipo “acceso no permitido”.

Más útil habría sido ofrecer al usuario, además del mensaje de error, más información y/o alguna acción alternativa: ir al “mapa del sitio”; contactar y comunicar el error; etc. Y una imagen algo más amable no sería una mala idea.

Leo que la semana pasada el Govern de les Illes Balears puso en marcha un nuevo portal para “realizar gestiones, pagar impuestos y multas municipales por vía telemática a través del portal de tributos locales”. La dirección es www.contribucions.org, y en la nota de prensa se destaca, entre otras cosas, su alto nivel de accesibilidad.

Dado que “en este mundo no hay cierto, salvo la muerte y los impuestos”, y como prácticamente todos somos posibles usuarios del portal, no está de más comprobar si es realmente usable y accesible.

(sigue …)

Muchos de los que nos dedicamos al desarrollo de software utilizamos, conocemos o, como mínimo, nos hemos tropezado con el concepto de framework (cuya traducción aproximada sería “marco de trabajo”). En concreto, y por diferentes motivos, he hecho algún pinito utilizando JavaServer Faces así como en Ruby on Rails.

Sin embargo, el concepto de framework no es sencillo de definir, a pesar de que cualquiera con experiencia programando captará su sentido de manera casi intuitiva, y es muy posible que esté utilizando su propio framework (aunque no lo llame así).

¿Cuál es el sentido de un framework?

(sigue …)

Esta semana se ha publicado en Usolab un artículo mío titulado Usando AJAX en la banca por Internet.

Usolab es una empresa consultora en usabilidad con la que mantengo contacto y he hecho alguna que otra colaboración.

El artículo en cuestión incluye una demo funcional como ejemplo de lo que podría ser un extracto de movimientos financieros en una aplicación de banca por Internet, utilizando la tecnología AJAX; también se anuncia el artículo en su weblog.

Para los menos iniciados, os cuento que AJAX es el nombre que recibe una combinación de tecnologías que permite que las aplicaciones web refresquen la información sin cargar páginas nuevas. Las aplicaciones más conocidas que utilizan AJAX son las de Google: Google Maps y GMail.

Os invito a que leáis el artículo, tanto a los iniciados en estas tecnologías como a los que seáis usuarios de la banca por internet o, simplemente, tengáis cierta curiosidad

NOTA: El artículo ha sido publicado en Barrapunto, y también Enrique Dans lo ha mencionado en su blog, sugiriendo la posibilidad de que las entidades bancarias utilicen estas nuevas tecnologías para, por ejemplo, personalizar la página de entrada o aumentar la seguridad de la banca online.

Una de las características fundamentales de lo que conocemos como World Wide Web (WWW o simplemente “la web”) es la posibilidad de relacionar información que se halla situada diferentes documentos o páginas. Y en un navegador web, la manera de indicar que los elementos tienen información relacionada en otros documentos es mediante los enlaces (vínculos, hipervínculos, links) que todos vemos y utilizamos en páginas de Internet.

A pesar de que no se definiera formalmente, desde el momento de la creación de la WWW el estándar “de facto” para la visualización de enlaces textuales es la utilización de texto azul subrayado como este:

En el origen de la World Wide Web los enlaces se mostraban azules y subrayados.

Adicionalmente es habitual que los enlaces cambien de color una vez han sido utilizados para que el usuario distinga qué páginas ha visitado anteriormente. De hecho, los estándares de usabilidad aconsejan utilizar ese formato para los enlaces de modo que sea fácil y rápido identificar qué elementos de la página tienen información relacionada (en otras palabras, “dónde se puede hacer click“).

No obstante, este estándar tan sencillo se ha quedado corto. El enorme crecimiento de la WWW tanto en tipos de contenido como en modos de interacción con el usuario hacen necesario (e inevitable) que aparezcan nuevas técnicas de visualización de enlaces.

(sigue …)

El texto explicativo del icono, Standards Compliance Mode (modo de cumplimiento de estándares) indica que el código de la página cumple los estándares. ¿Qué estándares? Mi sospecha es que el icono se muestra cuando la página declara un DTD y después lo valida; o, dicho de otro modo, cuando se compromete a seguir una determinada estructura y después lo cumple.

(sigue …)

El pasado lunes, 15 de mayo, presenté en la UIB el proyecto fin de carrera de la Ingeniería en Informática, que tenía pendiente desde que terminé todas las asignaturas en 1996; cuando uno empieza a trabajar cuesta dedicarle horas a algo por lo que no te pagan.

El proyecto se titula Análisis de accesos a un servidor web de contenidos dinámicos; en pocas palabras, trata de la aplicación de técnicas de minería de datos (web data mining) a los logs de los servidores de Internet e Intranet de la empresa donde trabajo, “SA NOSTRA” para conocer el comportamiento de sus usuarios; su característica más destacada es que son servidores dinámicos (en concreto, basados en Lotus Notes / Domino).

(sigue …)