en su libro “The Elements of user interface design”, Theo Mandel cuenta la siguiente anécdota para ilustrar una de las reglas de oro del diseño de interfaz, da el control a los usuarios:

“After designing a complex of buildings, an architect was supposed to design the walkways between the buildings. He did not assume that he knew how users would really use the walkways between the buildings. So he didn’t design the walkways or build them at the same time as the buildings. Rather, he had fields of grass planted between the buildings. It is rumored that even he posted signs saying, “Please walk on the grass.” A few months after the buildings were completed, he came back and saw where the most worn paths were where people walked across the grass between buildings. Then he knew where he should put the walkways.”

Una para saber el ránking de las páginas más enlazadas de del.icio.us (en las últimas horas, no las totales) y la segunda para saber qué tags le ha puesto la gente a una url.

Si te interesa el tema, hay una colección completa de utilidades en el blog Quick Online Tips That Work.

En estos días que tan de moda están las aplicaciones web, y más que lo van a estar, quiero hacer una pequeña reflexión poniendo en una balanza sus ventajas e inconvenientes.

Primero, las ventajas:

• Desarrollo barato, sencillo y rápido (y más aún si desarrollas en RoR).
• Acceso ubicuo, sin necesidad de distribución e, idealmente, con pocos requerimientos técnicos.
• Datos centralizados y fácil integración de datos de multiples fuentes.
• Permiten el desarrollo de comunidades que dan valor a las aplicaciones (software social).

Todas estas obvias ventajas (y más de las que ahora no quiero acordarme) dejan claro el potencial de las aplicaciones web, pero no es oro todo lo que reluce…

Las carencias:

• Acceso limitado, la necesidad de conexión permanente y rápida a Internet hacen que el acceso a estas aplicaciones no esté al alcance de todos.
• La interactividad no se produce en tiempo real, en las aplicaciones web cada acción del usuario conlleva un tiempo de espera excesivo hasta que se obtiene la reacción del sistema.
• Elementos de interacción muy limitados. En comparación con el software de escritorio, las posibilidades de interacción con el usuario que ofrecen las aplicaciones web (mediante formularios principalmente) son muy escasas.
• Diferencias de presentación entre plataformas y navegadores. La falta de estándares ampliamente soportados dificulta el desarrollo de las aplicaciones.

Por suerte, casi todas estas limitaciones están en la actualidad camino de ser superadas. Nuevas tecnologías y estándares hacen pensar que en poco tiempo muchas de estas dificultades serán simples recuerdos. Pero lo que todo el mundo se pregunta es si algún día podrán sustituir a las aplicaciones de escritorio, yo de momento sólo diré que sigo prefiriendo el cliente de correo de escritorio frente a cualquier webmail (sí, incluyendo a gmail y a Oddpost).

Y seguimos leyendo sobre aplicaciones web. Os pego otro listado, esta vez con los pasos para crear una.

When building any Internet application you’re going to go through the following steps:

1. Develop a data model. What information are you going to store and how will you represent it?
2. Develop a collection of legal transactions on that model, e.g., inserts and updates.
3. Design the page flow. How will the user interact with the system? What steps will lead up to one of those legal transactions? (Note that “page flow” embraces interaction design on Web, mobile browsers, and also via hierarchical voice menus in VoiceXML but not conversational speech systems.)
4. Implement the individual pages. You’ll be writing scripts that query information from the data model, wrap that information in a template (in HTML for a Web application), and return the combined result to the user.

Por Walter Kobylanski

Después de mucho tiempo, por fin puedo sentir la satisfacción de mostrar mi propia aplicación web, abierta al público desde hace una semana.

Si tienes ganas de poder hacer lo mismo, aquí van algunos sencillos pasos para hacerlo realidad

1. Despidete de tu familia por una temporada, de tu pareja, del cine, de la televisión, de salir a comer, de la vida sana, de la cama, de jugar al doom, de parecer joven y saludable y de tu vida actual en general.
2. Acostumbrate a pasar horas sentado, a recibir baños de rayos catódicos, a que se te duerman las extremidades, al escozor crónico en los ojos, a la mala comida y la envidia que te da el resto del mundo que parece tener una vida más normal y desahogada.
3. Trabaja todo lo que puedas, mientras puedas.
4. Lanza tu aplicación web.

   Y ahora ¿qué toca? ¿qué va a pasar?

5. Go To 1

Tomo nota Walter!

Llevaba tiempo buscando una herramienta así! Googlemonitor es un programita con el que puedes ir monitorizando la posición de tu web en los resultados de búsqueda de Google de una o varias palabras claves.

Visto en SeoMaker. Por cierto, el enlace (a SeoMaker) es una demostración de que la primera regla de la guía de posicionamiento en buscadores de google.dirson.com es totalmente cierta:

1. Buenos contenidos.

Este es el punto principal, ya no solo para aparecer en los primeros puestos en Google, sino para que la gente visite tu sitio web.

SeoMaker participa en un concurso de posicionamiento web y su lista de recursos sobre buscadores le ha hecho ganarse un fantástico peluche… enlace de blogold :)

Quería suscribirme a la lista de correos de Typofonderie, así que he hecho clic en el input correspondiente, (donde había un texto que no he leido) y se ha borrado. He escrito mi e-mail y …. ¿dónde está el botón enviar??

Por suerte el mecanismo era el mismo que el del formulario superior, el buscador, y he comprendido que se enviaba pulsando la tecla Enter.

Seguramente si hubiera sido una usuaria primeriza, no hubiera tardado mucho en frustrarme y cerrar la página.

Es cierto que cuando utilizo un formulario con un solo campo de entrada y un botón para enviar los datos de ese campo (como el típico formulario de búsqueda o de suscripción), casi nunca cojo el ratón para hacer clic en el botón. Normalmente pulso la tecla Enter, que es mucho más rápido.

Pero cuando falta el botón, se crea un gran desconcierto. No solo porque no te queda claro cómo introducir los datos (¿habrá cargado mal la página? ¿se le habrá olvidado al webmaster poner el botón?), sino que además desaparece el feedback gráfico del botón pulsado (que aparece también cuando se activa con una tecla en vez de con el ratón) y que te hace saber que la acción de enviar se ha iniciado.

Asi que, diseñadores del mundo, no juguéis con los formularios, que son una cosa muy seria. La web está en pañales aún y hay que seguir unas reglas de interacción mínimas para facilitar el aprendizaje a los usuarios.

Ya habrá tiempo de experimentar ;)

La importancia de la velocidad de carga de los sitios web para la experiencia de los usuarios es indiscutible. El debate gira en torno a cuánto tiempo están dispuestos a esperar los usuarios a que cargue un sitio y, aunque existen diversos estudios, no parece existir un consenso sobre este dato, si bien parece claro que el tiempo de espera tolerable por los usuarios se situa bastante por encima de los famosos 10 segundos del tío Jakob.

Habitualmente, los buenos diseñadores web se esfuerzan en minimizar el código XHTML, reducir el peso de las imágenes al máximo y otras diversas técnicas de optimización de sitios web. Pero existen otros factores influyentes que no son habitualmente considerados:

El tiempo de carga percibido

Dos páginas con el mismo tiempo de carga real pueden ser percibidas por los usuarios como una más rápida que otra. Existen muchas formas de influir en esta percepción y es realmente esta variable la que valorarán los usuarios.

Evitar que los elementos varien su posición durante la carga (para que el usuario pueda empezar a ojear aquellas zonas ya cargadas), permitir la descarga progresiva de los gráficos e imágenes, ofrecer un adecuado feedback durante la espera, ofrecer contenido de interés durante la carga (interesante para contenido realizado con flash), cargar primero aquella información que suelen venir buscando los usuarios y otra técnicas de este estilo, pueden ayudar a reducir el tiempo de espera percibido y/o hacerlo más llevadero.

La experiencia de uso comienza mucho antes de que el sitio haya terminado de cargar

Al igual que nuestra experiencia con un nuevo producto comienza desde el momento que tenemos el paquete en nuestras manos y no cuando ya lo estamos utilizando, nuestras experiencias con los sitios podemos considerar que comienzan desde el momento en que tecleamos la url en nuestro navegador. Por este motivo, debemos facilitar el que nuestros sitios puedan ser usados sin necesidad de que hayan cargado por completo.

Un ejemplo concreto: un usuario trata de encontrar una imagen en la que aparece un determinado personaje en una galería de 20 imágenes que se muestran a un tamaño considerable, en esta situación, un simple texto alternativo suficientemente explicativo en cada imagen sería de muchísima utilidad y le permitiría buscar la imagen sin necesidad de esperar a que hayan cargado todas.

Quería implementar el típico select con un listado de los países del mundo que hay en la mayoría de los formularios de registro.

Como no sabía cómo conseguir un listado actualizado, estaba a punto de ir a copiar la lista de algún portal importante, cuando he descubierto que hay un listado oficial: la norma ISO 3166, de la International Organization for Standardization.

Listado estándar

En realidad, la norma ISO 3166 es un listado de códigos para cada país. Un código numérico, uno de dos letras, y otro de tres letras.

Los códigos de dos letras, por ejemplo, son los que se utilizan para la terminación de las URLs de cada país: www.elmundo.es, www.lemonde.fr, www.corriere.it…

La norma se lanzó en 1974 y contaba entonces con 220 países. 4 años después se creó la Agencia de Mantenimiento de la norma, encargada de la actualización de la lista, que actualmente tiene 240 países.

Bueno, en realidad de las listas, porque la norma incluye 3 listas:

ISO 3166-1

Es un listado de los países con los códigos de cada uno. Se publicó en octubre de 1997 y sólo ha habido un cambio en el listado desde entonces.

ISO 3166-2

Es un listado de las regiones de cada país del ISO 3166-1, con un código de dos cifras para cada región. Se publicó en diciembre de 1998, pero se actualiza a menudo.

ISO 3166-3

Recoge los nombres con los que antiguamente se conocía a los países. Se publicó a principios de 1999.

Usabilidad

Siempre me ha surgido la duda de si es mejor usar el listado con los nombre de los países en inglés o si sería mejor poner el nombre de cada país en el idioma de ese país. En este caso en concreto, el sitio que estoy construyendo está íntegramente en inglés, así que el nombre de los idiomas también irá en inglés.

Creo que lo más lógico es que el listado aparezca con los nombres de los países en el idioma que tenga el resto del formulario. Ya que si alguien es capaz de rellenar un formulario en un idioma (que no sea el nativo), probablemente conocerá el nombre de su país en ese idioma.

Sólo sería útil el listado con cada nombre en su idioma cuando se espera una audiencia que no sepa idiomas, pero que probablemente es capaz de reconocer un control de formulario para elegir su país y en ese caso el sistema pueda llevarlo a una página en su idioma.

Otro aspecto importante de la usabilidad de este tipo de controles de formulario, es intenta marcar como seleccionada la opción más probable. En este caso, creo que intentaremos detectar el país del usuario y seleccionarlo en el formulario.

Pero en otros casos similares, donde se sabe el país de la mayoría de los usuarios, es recomendable seleccionarlo.

Descargas

Para implementar el select, podéis utilizar un archivo sql que he encontrado que genera una tabla en la base de datos con el listado de países.

Actualización (11/04/06): Álvaro ha publicado en korsarios un listado en castellano en SQL de los países del mundo.

Hace poco, la W3C lanzó el borrador de la segunda versión de las pautas de accesibilidad al contenido en la web. He estado comparándolas un poco con la versión 1.0 y he hecho algunas anotaciones básicas sobre la estructura de ambos documentos:

WCAG 1.0 utiliza 15 pautas. Cada pauta tiene varios checkpoints, y cada checkpoint tiene un nivel de accesibilidad (A, AA o AAA).

WCAG 2.0 se divide en 4 grandes principios. Cada principio tiene varias pautas, y cada pauta 3 niveles de éxito. Cada nivel de éxito tiene varios puntos a cumplir.

En nivel 1 de éxito de la WCAG 2.0 equivale al nivel A de la WCAG 2.0, el nivel 2 a la AA y el 3 a la AAA.

Los cuatro principios básicos de la WCAG 2.0 son:

• El contenido debe ser perceptible
• Los elementos de la interfaz en el contenido deben ser manejables
• El contenido y los controles deben ser comprensibles
• El contenido debe ser suficientemente robusto para funcionar con las tecnologías actuales y las del futuro.

En la WCAG 2.0 cada guía va acompañada de un párrafo explicando a qué tipo de usuarios ayuda y con varios ejemplos de uso.

A ver si este fin de semana consigo acabar de leermelas y puedo escribir un poco más sobre las novedades que trae.