Joel on Software

Joel on Software La Opinión de Joel sobre qué es Software

 

Diseño de Interfaz de Usuario para Programadores
Capítulo 1
Capítulo 2
Capítulo 3
Capítulo 4
Capítulo 5
Capítulo 6
Capítulo 7
Capítulo 8
Capítulo 9

Otros artículos de "Joel on Software" en Español

Otros artículos de "Joel on Software" en Inglés

Envíele un Email al autor (solo en Inglés)

 

Diseño de Interfaz de Usuario para Programadores
Capítulo 1: Controlar Tu Entorno Te Hace Feliz


Por Joel Spolsky
Traducido por Angel García Cuartero
Editado por José Manuel Navarro
10 de Abril de 2000

La mayoría de los programadores incondicionales de C++ que conozco odian la programación de interfaz de usuario. Esto me sorprende, porque a mí me parece que la programación de IU es esencialmente fácil, sincera y divertida.

Es fácil, porque normalmente no necesitas algoritmos más sofisticados que uno para centrar un rectángulo dentro de otro. Es sincera, porque cuando cometes un error, inmediatamente lo ves y puedes corregirlo. Es divertido, porque los resultados de tu trabajo son visibles al momento. Sientes que estás esculpiendo el programa directamente.

Creo que el miedo de la mayoría de estos programadores viene de su miedo de hacer diseño de IU. Piensan que el diseño de IU es como el diseño gráfico: Ese misterioso proceso por el cual esa gente creativa, que van vestidos de negro, beben capuchinos y llevan piercings curiosos produce un material artístico tan chulo. Los programadores se ven a sí mismos como pensadores analíticos y lógicos: fuertes a la hora de pensar, débiles a la hora de opinar sobre arte. Así que piensan que no pueden hacer diseño de IU.

De hecho, creo que el diseño de IU es muy fácil y racional. No se trata de un problema misterioso que requiere un título de una escuela de arte y cierta inclinación por el color de pelo morado chillón. Existe una manera racional de pensar en interfaces de usuario, con reglas simples y lógicas, que puedes aplicar en cualquier sitio para mejorar las interfaces de los programas en los que trabajas

No os voy a enseñar "Zen y el Arte del Diseño de IU". No es un arte, no es budismo, sólo es un conjunto de reglas. Una forma de pensar racional y metódica. Este libro está pensado para programadores. Voy a asumir que no necesitas instrucciones para construir una barra de menú; mejor dicho, lo que necesitas es pensar qué vas a poner en la barra de menú (o si realmente te hace falta una). Os enseñaré que hay un axioma primario que guía todo buen diseño de IU y que no es difícil en absoluto de entender.

Mi primer trabajo de verdad fue en una gran panadería industrial. La panadería fue diseñada para tener seis filas de producción. Por cada dos filas había una amasadora, que producía pedazos de masa gigantes de 180 Kg. que se podían volcar a la derecha o a la izquierda:

 

Bueno, este era el diseño. En realidad, el Mezclador C no había sido construido aún, ni tenía las filas 3 y 5. Así que el apaño que había era este:

 

El despierto lector estará pensando "¿Cómo llegaba la masa del Mezclador B a la fila 6?". Bueno, pues ahí es donde el pequeño Joel entraba. Mi trabajo era, si os lo podéis creer, quedarme al lado del Mezclador B, coger la masa de 180 Kg. según salía, ponerla en una bañera con ruedas, llevar la bañera rodando a la fila 6 y, usando un chisme parecido a un torno, echar la masa en la fila 6. Tenía que hacer esto cada 10 minutos, desde más o menos las 10 de la noche hasta las 4 de la madrugada.

Había otras complicaciones. La fila 6 en realidad no podía hacerse con los 180 Kg. de masa enteros, así que tenía que cortarla con un cuchillo gigante en unos 10 trozos. Ni siquiera voy a entrar en lo absurdamente difícil que era esto.

Los primeros días, por supuesto, era malísimo en este trabajo. Me parecía casi imposible. Me dolían todos los huesos del cuerpo. Tenía ampollas en las ampollas. Me dolían partes de mi cuerpo que ni siquiera sabía que existían.

Al principio, simplemente no podía mantener alimentada la fila 6. Cada vez que había una interrupción en la masa esto creaba un enorme hueco en la línea de producción. Cuando el hueco llegaba al horno, éste (suministrando la misma cantidad constante de energía sobre una cantidad de masa más reducida) se calentaba más, lo que quemaba el pan. A veces, la fila 6 se atascaba y paraba la producción, pero el mezclador continuaba produciendo masa y yo corría el riesgo de quedarme sin bañeras donde ir poniendo la masa. Cuando esto pasaba, lo que en verdad hacía era limpiar y engrasar el suelo y volcar en él la masa, que luego se reutilizaba. Esto no estaba muy bien, porque si la masa se quedaba así más de 30 minutos, fermentaría y no produciría buen pan. Si pasaba esto, había que cortarla en pedazos de 5 kg y poner uno de estos pedazos en la mezcla en el siguiente lote.  

Después de una semana o así, mejoré tanto en la rutina que, si recuerdo bien, tenía 2 minutos libres para descansar por cada ciclo de masa de 10 minutos. Calculé un horario exacto y aprendí cómo decirle a la amasadora que se saltara un lote cuando la línea de producción se paraba.

Entonces empecé a pensar por qué, como dice el anuncio de la cerveza, algunos días son mejores que otros.

Un día, pensando en este problema, me di cuenta de que una de las bañeras rodantes tenía unas ruedas lamentables que no giraban bien. A veces, esta bañera no iba hacia donde yo la empujaba y se chocaba con las cosas. Esta era una pequeña frustración. A veces, según tiraba de la cadena para sacar la masa de la bañera, me arañaba -- sólo un poquito -- con una esquirla de la cadena. Otra pequeña frustración. A veces, según corría con una bañera vacía para coger la masa que salía de la amasadora, me resbalaba con un poco de aceite en el suelo. He de decir que no lo suficiente para caerme, sólo una pequeña frustración.

Otras veces, tenía pequeñas victorias. Aprendí a cronometrar la producción de masa tan perfectamente que la masa fresca llegaba segundos antes de que el lote anterior se acabara. Esto garantizaba la masa más fresca posible y producía el mejor pan. Algunas de las victorias eran incluso más pequeñas: Localizaba un poco de masa que había salido disparado del mezclador y se había pegado a la pared, lo rascaba con una espátula que llevaba en el bolsillo trasero y lo tiraba a la basura. ¡SÍ SEÑOR! Cuando cortaba la masa en trozos, a veces se podía cortar muy agradable y fácilmente. Pequeños momentos de satisfacción, cuando conseguía controlar el mundo a mi alrededor, aunque fuese de una manera ínfima.

Así pasaban los días. Un montón de pequeñas frustraciones y un montón de pequeños éxitos. Pero todos se acumulaban. Incluso algo que parece una pequeña frustración sin consecuencias afecta tu humor. A tus emociones no parece importarles la magnitud de un acontecimiento, sólo la calidad del mismo.

Y empecé a aprender que los días en los que era más feliz eran los días con montones de pequeños éxitos y unas poquitas pequeñas frustraciones.

Años más tarde, cuando fui a la universidad, aprendí algo de una importante teoría de psicología llamada Indefensión Adquirida, desarrollada por el Dr. Martin E. P. Seligman. Esta teoría, respaldada por años de investigación, dice que una gran depresión aparece tras un sentimiento de indefensión: el sentimiento de que no puedes dominar tu entorno.

Cuánto más sientes que puedes controlar tu entorno y que las cosas que haces funcionan, más feliz eres. Si estás frustrado, enfadado y contrariado, es porque probablemente te ha ocurrido algo que no puedes controlar: aunque sea algo pequeño. La barra espaciadora de tu teclado no va bien. Cuando tecleas, algunas palabras se quedan pegadas. Esto es frustrante, porque le has dado al espacio y no ha pasado nada. La llave de tu casa no funciona bien. Cuando intentas girarla, que atasca. Otra pequeña frustración. Estas cosas se acumulan; estas son las cosas que nos hacen infelices día a día. Incluso aunque parezcan demasiado insignificantes para explayarse con ellas (quiero decir, hay gente en África muriéndose de hambre, por el amor de Dios, no me puedo enfadar con la barra del espacio), no obstante, afectan a nuestro humor.

Una ligera pausa y volvamos a los ordenadores.

Vamos a inventarnos un típico usuario avanzado de Windows llamado Pete. Cuando piensas en interfaces de usuario, tener usuarios imaginarios en la cabeza ayuda. Cuanto más realista sea el usuario imaginario, mejor te irá al pensar cómo van a usar tu producto. Pete es un contable en una editorial técnica que lleva usando Windows desde hace seis años en la oficina y un poco en casa. Es muy competente y bastante técnico. Sabe instalar su propio software; lee PC Magazine, e incluso se ha programado algunas macros de Word para ayudar a las secretarias de su oficina a enviar los recibos. Se va a poner un cable modem en casa. Pete nunca ha usado un Macintosh. "Son muy caros", dice. "Te puedes comprar un PC a 700 Mhz con 128 MB de RAM por el precio de..." Vale, Pete. Lo pillamos.

Un día Gena, la amiga de Pete, le pide ayuda con su ordenador. Gena tiene ahora un Macintosh iBook, porque le encantan estos equipos translúcidos. Cuando Pete se sienta e intenta usar el Macintosh, rápidamente se va frustrando. "Odio estas cosas", dice. Al final ha podido ayudar a Gena, pero se ha vuelto gruñón e infeliz. "Los Macintosh tienen una interfaz de usuario tan patatera".

¿Patatera? ¿De qué esta hablando? Todo el mundo sabe que los Macintosh tienen una interfaz de usuario elegante, ¿no? ¿El paradigma de la facilidad de uso?

Este es mi análisis de dicho misterio.

En un Macintosh, cuando quieres mover una ventana, pues coges cualquier borde con el ratón y lo mueves. En Windows, tienes que coger la barra de título. Si coges un borde, la ventana se redimensiona. Cuando Pete estaba ayudando a Gena, trató de ensanchar una ventana arrastrando el borde derecho. De manera frustrante, la ventana completa se movió, en lugar de redimensionarse como él esperaba.

En Windows, cuando una caja de mensaje aparece, puede darle a intro o a la barra espaciadora para cerrarla. En un Mac, pulsar espacio no funciona. Normalmente hace falta pulsar con el ratón. Cuando a Pete le salían avisos, intentaba cerrarlos pulsando la barra del espacio, como ha estado haciendo inconscientemente durante los últimos seis años. La primera vez, no pasó nada. Si ni siquiera haberse dado cuenta, Pete le dio más fuerte al espacio, porque pensaba que el problema era que el Mac no había recibido la pulsación de espacio. De hecho, si que la recibió -- ¡pero no le importó! Por fin utilizó el ratón. Otra pequeña frustración.

Pete ha aprendido a usar Alt+F4 para cerrar ventanas. En los Mac, en realidad cambias el volumen. En un determinado punto, Pete quería pulsar el icono del Internet Explorer en el escritorio, que estaba parcialmente cubierto por otra ventana. Así que pulsó Alt+F4 para cerrar la ventana e inmediatamente hizo doble click donde el icono debería haber estado. El Alt+F4 subió el volumen del ordenador y no cerro la ventana, así que el doble click fue al botón de Ayuda en la barra de herramientas de la ventana que quería cerrar, lo que inmediatamente lanzó una ventana de ayuda, así que ahora tiene dos ventanas abiertas que hay que cerrar.

Otra pequeña frustración. Pero, chico, se acumulan. Al final del día, Pete se ha vuelto gruñón y está enfadado. Cuando intenta controlar las cosas, no responden. La barra de espacio y la tecla Alt-F4 "no funcionan" --a todo efecto, es como si estuvieran rotas. La ventana le desobedece cuando la intenta ensanchar, le juega una pequeña travesura moviéndose en lugar de agrandarse. Ventana mala. Incluso si todo es inconsciente, esa sutil sensación de no tener el control se traduce en indefensión, que a su vez se traduce en infelicidad. "Me gusta mi ordenador", dice Pete. "Lo tengo todo preparado de manera que funcione como me gusta. Pero estos Macs son cutres y difíciles de usar. Es un ejercicio de frustración. Si Apple hubiera estado trabajando en MacOS todos estos años en vez de tontear con los Newton, su sistema operativo no sería tan desastroso".

Vale, Pete. Ahora lo sabemos. Estas sensaciones aparecen a pesar del hecho de que los Macintosh son realmente fáciles de usar -- para los usuarios de Mac. Qué tecla pulses para cerrar una ventana es totalmente arbitrario. Los programadores de Microsoft, que, presuntamente, estaban copiando la interfaz de Mac, probablemente pensaron que molaba añadir una característica que permitía redimensionar ventanas arrastrando cualquier borde. Los programadores de Mac 8.0 probablemente pensaron que molaba añadir una característica que hacía que pudieras mover las ventanas arrastrando cualquier borde.

La mayoría de las discusiones leídas sobre asuntos de interfaz de usuario se concentran en la cuestión equivocada. Windows es mejor porque te ofrece más formas de redimensionar ventanas. ¿Y qué? No es eso. La cuestión es, ¿responde el IU al usuario de la manera que el usuario espera que lo haga? Si no lo hace, el usuario se va a sentir desprotegido y sin el mando, de la misma manera que yo me sentía cuando las ruedas de la bañera con la masa no giraban en la dirección que yo las empujaba y me chocaba con la pared. Buuuumba.

Las IU son importantes porque afectan a las sensaciones, las emociones y el humor de tus usuarios. Si la IU está mal y el usuario siente que no puede controlar la aplicación, literalmente no serán felices y culparán a tu programa de ello. Si la IU está bien y las cosas funcionan de la manera que los usuarios esperan, estarán contentos cuando consigan completar pequeñas tareas. ¡Hey! ¡Acabo de copiar un CD! ¡Y ha funcionado! ¡Este programa está bien! ¡Moooooola!

Para hacer feliz a la gente, tienes que permitirles sentirse al mando de su entorno. Para hacer esto, necesitas interpretar correctamente sus acciones. La interfaz necesita comportarse de la manera que ellos esperan que se comporte.

Así, el axioma fundamental de todo diseño de interfaz de usuario es:

 

Una interfaz de usuario está bien diseñada cuando el programa se comporta exactamente como el usuario piensa que lo haría.



Como Hillel dijo, todo lo demás son comentarios. Todas las demás reglas de buen diseño de IU son sólo corolarios.



> Capítulo 2

Esté articulo apareció originalmente en Inglés con el nombre User Interface Design for Programmers Chapter 1: Controlling Your Environment Makes You Happy  

Joel Spolsky es el fundador de Fog Creek Software, una pequeña empresa de software en Nueva York. Es titulado por la Universidad de Yale y ha trabajado como programador y gerente en Microsoft, Viacom, y Juno.


El contenido de estas páginas representan la opinión de una persona.
Todo el contenido es Copyright ©1999-2005  por Joel Spolsky. Todos los derechos son reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky