Categoría 'estándares'

Leía la semana pasada en Menéame que Google ha conseguido la patente del diseño de su home (página inicial). Mucho se ha escrito ya sobre las patentes (los casos del software y los medicamentos son, valga la expresión, "sangrantes"), aunque podríamos decir como resumen que, si bien en teoría existen para proteger las ideas originales y a sus creadores, en la práctica se convierten en un obstáculo a la innovación:

La creencia que sustenta la necesidad de las patentes y los derechos de autor es que, si no se les da una protección, el creador no va a innovar. "Pero debería ser algo obvio que es la competencia, y no el monopolio de ideas, lo que sustenta la creación", añade el economista.

El problema añadido es que, en este tipo de patentes, existe un factor negativo más, y es el que afecta a la usabilidad de las aplicaciones web.

Es innegable que muchos de los estándares de facto en Internet provienen de ciertos portales representativos como son Amazon, Ebay y, sobre todo, Google; si un diseñador tiene que crear un sitio web de comercio electrónico, de subastas, o un buscador esas son sus referencias, y antes de crear una interfaz totalmente nueva seguramente se inspirará (cuando no copie directamente) esas otras páginas.

Esto tiene como efecto positivo (si no es la causa) que los usuarios ya saben cómo utilizarlas, y no necesitan aprender cómo funciona cada una de ellas, para lo cual probablemente no tengan suficiente tiempo y/o interés.

Pero ¿qué ocurre si Google y otros sitios web empiezan a patentar y a hacer valer sus derechos sobre esos diseños? Los responsables de sitios web similares podrán optar por pagar los correspondientes derechos por utilizarlos, o bien tendrán que crear una interfaz totalmente distinta. Y esas son las malas noticias: cada sitio web tendrá entonces un aspecto y/o funcionamiento diferentes, y los usuarios tendrán que aprender cómo funciona cada uno de ellos.

Teóricamente esas nuevas interfaces podrían ser mejores que las existentes, pero pocas veces las mejoras se consiguen a través de una ruptura radical con lo existente sino que habitualmente provienen de mejorar lo que ya funciona.

Parece, pues, que en este caso los efectos negativos de las patentes no serían únicamente para los desarrolladores sino también para los usuarios, es decir, todos nosotros.

¿Cómo nos afectarán en la práctica esas patentes?

Es posible que acabes de llegar al mundo del diseño de páginas web, o lleves más tiempo en él. La cuestión es que has oído hablar de usabilidad, accesibilidad, estándares… Todo eso suena realmente bien, y decides que son materias que debes tener en cuenta; hay toneladas de información en la red sobre esos temas, así que… ¿por dónde empezar con todo eso?

Si estás en esa situación (o parecida), es posible entonces que estas pocas descripciones y enlaces te sirvan de iniciación.

Evitando errores frecuentes

Un buen punto de partida es conocer los errores más frecuentes, aprovechando las malas experiencias de los demás para evitarlos. Y antes de empezar a diseñar páginas, es importante conocer qué errores deben evitarse a la hora de gestionar una web:

• Top ten mistakes of web management (diez principales errores de la gestión web)

Jakob Nielsen, el más popular gurú de la usabilidad, tiene multitud de pequeños artículos ("alertbox") sobre diversos temas relacionados con el diseño web. En general son muy recomendables por su claridad y pragmatismo, y un buen punto de partida son los titulados "top ten …" ("diez principales … "), como el de 10 directrices para el diseño de la página inicial, o los 10 principales errores de diseño web (¡los de 1996!).

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

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