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

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.

Diseño de Interfaz de Usuario para Programadores
Capítulo 2: Calcular lo que esperan

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

Cuando un nuevo usuario se pone a usar un programa, no viene como una hoja en blanco. Tiene ciertas espectativas de cómo cree que el programa va a funcionar. Si ha utilizado una aplicación parecida, pensará que ésta nueva va a funcionar como la otra. Si ha usado cualquier software anteriormente, pensará que tu software se atiene a ciertas convenciones comunes. Puede que intuyan inteligentemente cómo va a funcionar el IU. Esto es lo que se conoce como modelo de usuario: es la comprensión mental de lo que el programa está haciendo para él.

El programa también tiene un "modelo mental", sólo que está codificado en bits y será ejecutado de manera fiel por la CPU. Esto es lo que se conoce como modelo de programa y es La Ley. Tal como hemos aprendido en el Capítulo Uno, si el modelo de programa corresponde al modelo de usuario, tu interfaz de usuario tendrá éxito.

Echemos un vistazo a un ejemplo. En Microsoft Word (y en la mayoría de procesadores de texto), cuando metes una imagen en tu documento, la imagen realmente queda empotrada en el mismo fichero que el propio documento. Puedes crear la imagen, arrastrarla al documento, luego borrar el fichero de la imagen original, pero la imagen permanecerá en el documento.

Bien, pues HTML no te deja hacer esto. Los documentos HTML deben almacenar sus imágenes en un fichero separado. Si tomamos un usuario habituado a procesadores de texto, que no sabe nada de HTML, y lo sentamos enfrente de un bonito editor HTML tipo WYSIWYG como FrontPage, casi seguro pensará que la imagen va a ser almacenada en el fichero. Llamemos a esto inercia del modelo de usuario, si os parece.

Así que tenemos un desgraciado conflicto entre el modelo de usuario (la imagen se empotra en el documento) y el modelo de programa (la imagen debe estar en un fichero separado), y por ello, el IU seguro que causará problemas.

Si estás diseñando un programa como FrontPage, acabas de encontrar tu primer problema de IU. No puedes cambiar HTML. Algo tiene que haber que alinee el modelo de programa con el modelo de usuario.

Tienes dos opciones. Puedes intentar cambiar el modelo de usuario. Esto resulta extraordinariamente difícil. Puedes explicar cosas en el manual, pero todo el mundo sabe que los usuarios no leen los manuales, y probablemente no tendrían por qué hacerlo. Puedes mostrar una pequeña ventana de diálogo explicando que el fichero de la imagen no va a ser incluido, pero esto tiene 2 problemas: es molesto para los usuarios avanzados y de todas maneras, los usuarios no leen cuadros de diálogo (hablaremos de esto en el Capítulo Seis).

Así que si la montaña no va a Mahoma... tu mejor elección casi siempre va a ser cambiar el modelo de programa, no el modelo de usuario. Quizás cuando inserten la imagen en el documento, puedas hacer una copia de la imagen en un subdirectorio por debajo del fichero del documento, de manera que al menos puedas casar la idea del usuario de que la imagen ha sido copiada (y el original puede ser borrado de manera segura).

¿Cómo sé cuál es el modelo de usuario?

Esto resulta bastante fácil. ¡Pregúntaselo a ellos! Elige al azar a cinco personas de tu oficina, o amigos, o familia, y diles lo que hace el programa en términos generales ("Es un programa para hacer páginas web"). Luego descríbeles la situación: "Tienes una página en la que estás trabajando, y un fichero con una imagen que se llama Imagen.JPG. Insertas la imagen en tu página web". Entonces hazles algunas preguntas para probar e intenta averiguar su modelo de usuario. "¿Dónde ha ido la imagen? Si borras Imagen.JPG, ¿la página web será todavía capaz de mostrar la imagen?"

Un amigo mío esta trabajando en una aplicación de un álbum de fotos. Después de insertar las fotos, la aplicación muestra un montón de miniaturas: pequeñas muestras de cada imagen. Bien, generar estas pequeñas miniaturas toma mucho tiempo, especialmente si tienes un montón de imágenes, así que lo que él quiere es almacenar estas miniaturas en el disco duro en algún sitio de modo que sólo tengan que ser generadas una vez. Hay muchas maneras para hacer esto. Se pueden almacenar en un fichero enorme llamado Miniaturas. Se pueden guardar en ficheros separados, en un subdirectorio llamado Miniaturas. Se puede marcar los ficheros como ocultos desde el sistema operativo, de modo que los usuarios no los vean. Mi amigo eligió una de las maneras de hacerlo en lo que él pensó que era lo que más le compensaba: guardó una miniatura de cada imagen imagen.JPG en un nuevo fichero llamado imagen_t.JPG en el mismo directorio. Si hacías un álbum con 30 imágenes, cuando acababas tenías 60 ficheros en el directorio, incluyendo las miniaturas.

Podríamos discutir durantes semanas acerca de los méritos y deméritos de los diversos modos de almacenar las imágenes, pero lo cierto es que hay una manera mucho más científica de hacerlo. Pregunta a un montón de usuarios dónde creen que se van a almacenar las miniaturas. Por supuesto, muchos de ellos dirán que no lo saben o que no les importa, o que no han pensado en ello, pero si preguntas a mucha gente, comenzarás a ver cierta clase de consenso. La elección popular es el mejor modelo de usuario, y depende de ti hacer que el modelo del programa se ajuste a él.

Después, tienes que poner a prueba tus teorías. Construye un modelo o prototipo de tu interfaz de usuario y mándales tareas a la gente. Según van trabajando con las tareas, pregúntales qué creen que está pasando. Tu objetivo es calcular qué es lo que esperan. Si la tarea es "inserta un imagen", y ves que están intentando arrastrar una imagen al programa, te darás cuenta de que será mejor incluir soporte para arrastrar y soltar. Si van al menú Insertar, verás que será mejor tener una opción para Imagen en ese menú. Si van a la barra de herramientas de Fuentes y reemplazan las palabras "Times New Roman" con las palabras "Insertar Imagen", acabas de encontrar una reliquia que no conoce todavía los entornos gráficos y que espera encontrarse un intérprete de línea de comandos.

¿Cuántos usuarios necesitas para probar con ellos tu interfaz? El instinto dice que "cuántos más, mejor", y tiene sentido para experimentos científicos. Pero ese instinto está equivocado. Casi todo el mundo que se gana la vida haciendo pruebas de usabilidad parece creer que cinco o seis usuarios bastan. Después de eso, se empiezan a ver los mismos resultados una y otra vez, y añadir más usuarios es una pérdida de tiempo.

No te hace falta un laboratorio formal de usabilidad, y ni tampoco traer usuarios "de la calle" -- puedes hacer pruebas de "todo a cien" en las que simplemente te coges al primero que pase por allí y le pides que haga una pequeña prueba. Asegúrate de que no lo echas todo a perder diciéndole cómo hacer las cosas. Pídele que "piense en alto" e interrógales haciendo preguntas abiertas para intentar descubrir su modelo mental.

Si tu modelo de programa no es trivial, probablemente no es el modelo del usuario.

Cuando tenía 6 años y mi padre trajo a casa una de las primeras calculadoras de bolsillo, una HP-35, intentó convencerme de que tenía un ordenador dentro. No creí que fuera posible. Todos los ordenadores en Star Trek era del tamaño de una habitación y tenían unas enormes unidades de cinta. Pensé que debía haber algún tipo de correlación inteligente entre las teclas del teclado y los elementos individuales de la pantalla que hacía que aquello produjera resultados matemáticamente correctos. (Eh, tenía 6 años).

Una regla buena regla general es la de que los modelos de usuario no son muy complejos. Cuando la gente tiene que pensar cómo va a funcionar un programa, intentan pensar en cosas simples, más que en cosas complicadas.

Siéntate en un Macintosh. Abre dos hojas Excel y un fichero Word. Casi todo usuario novato creería que las ventanas son independientes. Parecen independientes:

El modelo de usuario dice que al pulsar en la Hoja 1, eso traerá al frente dicha ventana. Lo que en realidad ocurre es que la Hoja 2 viene al frente, un sorpresa frustrante para casi todo el mundo:

Resulta que el modelo de programa de Microsoft Excel dice que "hay unas hojas invisibles, una para cada aplicación, y las ventanas están 'pegadas' a ellas. Cuando traes Excel a primer plano, todas las ventanas de Excel se moverán al frente también".

Vaaaaaaaaaaaaaale. Hojas invisibles. ¿Qué posibilidades hay de que el modelo de usuario incluya el concepto de hojas invisibles? Probablemente cero. Así que los nuevos usuarios se verán sorprendidos por este comportamiento.

Otro ejemplo del mundo de Microsoft Windows es la combinación de teclas Alt+Tab que cambia a la "siguiente" ventana. La mayoría de los usuarios probablemente asumirá que simplemente rota entre todas las ventanas disponibles. Si tienes las ventanas A, B y C, con A activa, Alt+Tab debería llevarte a B. Alt+Tab de nuevo te llevaría a C. En realidad, lo que ocurre es que el segundo Alt+Tab te lleva de vuelta a A. La única manera de ir a C es mantener pulsada Alt y pulsar Tab dos veces. Es una bonita manera de alternar entre dos aplicaciones, pero casi nadie se lo imagina, porque es un modelo ligeramente más complicado que el modelo de rotar-entre-todas-las-ventanas-disponibles.

Ya es suficientemente duro hacer que el modelo de programa se ajuste al modelo de usuario cuando los modelos son simples. Cuando un modelo se vuelve complejo, es incluso más difícil, así que elige el modelo más simple posible.

Esté articulo apareció originalmente en Inglés con el nombre User Interface Design for Programmers Chapter 2: Figuring Out What They Expected
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.

Diseño de Interfaz de Usuario para Programadores Capítulo 3: Decisiones Por Joel Spolsky Traducido por Angel García Cuartero Editado por José Manuel Navarro Miércoles, 2 de Abril de 2000 Cuando entras a un restaurante y ves un letrero que dice "No se permiten perros", podrías pensar que esa señal es puramente prescriptiva: Al dueño del restaurante no le gusta que los perros anden por ahí, así que, cuando construyó el restaurante, puso ese cartel. Si eso fuera todo, entonces también habría otro cartel de "Serpientes no"; después de todo, a nadie le gustan las serpientes. Y también otro cartel con "Elefantes no", porque rompen las sillas cuando se sientan. La verdadera razón de que ese letrero esté ahí es histórica: es una marca histórica que indica que la gente solía tratar de entrar con sus perros al restaurante. La mayoría de los carteles prohibitivos están ahí porque los propietarios de un establecimiento estaban hartos de que la gente hiciera X, así que pusieron un cartel pidiéndoles que, por favor, no lo hicieran. Si vas a uno de estas familiares cafeterías de cincuentones, como Yankee Doodle in New Haven, las paredes están cubiertas de letreros con cosas como "Por favor, no ponga su zurrón en el mostrador", más pruebas antropológicas de que aquella gente solía poner sus zurrones en el mostrador frecuentemente. Por la antigüedad del letrero, te puedes hacer una idea de cuándo los zurrones eran populares entre los estudiantes del lugar. A veces, son más difíciles. "Por favor, no traiga botellas de cristal al parque" debe significar que alguien se cortó alguna vez pisando una botella mientras andaba descalzo por la hierba y seguro que demandó a la ciudad. El software también tiene un registro arqueológico: Es el cuadro de diálogo de Opciones. Despliega el menú Herramientas | Opciones y verás la historia de las discusiones que los diseñadores del software tuvieron acerca del producto. ¿Deberíamos abrir automáticamente el último fichero sobre el que trabajó el usuario? ¡Sí! ¡No! Hay un debate de dos semanas, nadie quiere herir los sentimientos del otro, el programador pone un #ifdef en defensa propia mientras los diseñadores discuten. Al final, deciden convertirlo en una opción. Ni siquiera tiene que haber un debate entre 2 personas: puede ser un dilema interno. Tal vez no pueda decidir si deberíamos optimizar la base de datos para tamaño o para rapidez. En cualquier caso, te acabas encontrando con lo que es, inequívocamente, el cuadro de diálogo del "asistente" más imbécil en la historia del sistema operativo windows. Este diálogo es tan estúpido que merece algún tipo de premio. Una nueva categoría de premio. Se trata del cuadro de diálogo que aparece cuando intentas buscar algo en Ayuda: El primer problema con este diálogo es que te distrae. Estás intentando encontrar ayuda en el fichero de ayuda. En ese particular momento, te importa un carajo si la base de datos es pequeña, grande, personalizada o cubierta de chocolate. Mientras tanto, este diálogo tan tan retorcido, se permite el lujo de comentarte que va debe crear una lista (o base de datos). Hay unos tres párrafos ahí, la mayoría de los cuales son confusos. Está la dolorosamente incómoda frase "su(s) fichero(s) de ayuda". Mira, parece que puedes tener uno o más ficheros. Como si te importara en este punto que pudiera haber más de uno. Como si eso supusiera una gran diferencia. Pero el programador que trabajó en el ese diálogo estaba obviamente angustiado más allá de cualquier creencia con la posibilidad de que hubiera más de un fichero(s) y claro, sería incorrecto hablar de un fichero de ayuda, ¿verdad? Ni siquiera voy a empezar con el tema de que la mayoría de la gente que quiere ayuda no son la precisamente la clase de personas que entienden esta clase de arcanos. O que incluso usuarios avanzados, programadores licenciados en informática que lo saben todo acerca de índices de texto completo, ni sabrían decir sobre qué se les está preguntando que elijan. Para añadir insultos al agravio, esto ni siquiera es un cuadro de diálogo... es un asistente (la segunda página del cual dice algo así como "gracias por someterse a esta innecesaria pérdida de tiempo" literalmente). Y es muy obvio que los diseñadores tenían alguna idea de cuál de las opciones es la mejor; después de todo, se han tomado la molestia de recomendar una de las elecciones. Lo que nos lleva a nuestra segunda regla fundamental del diseño de interfaz de usuario: Cada vez que propongas una opción, estás pidiendo al usuario que tome una decisión. Pedir al usuario que tome una decisión no es malo en sí mismo. La libertad de elección puede ser maravillosa. A la gente le encanta pedir un café en Starbucks porque pueden elegir entre un montón de opciones. ¡Un café semidescafeinado con leche desnatada y crema batida, muy caliente! El problema viene cuando les pides que tomen una decisión sobre un tema que no les importa. En el caso de los ficheros de ayuda, la gente busca ayuda porque tienen problemas para hacer algo que realmente quieren realizar, como hacer una invitación de cumpleaños. La tarea de hacer su invitación de cumpleaños desafortunadamente ha sido interrumpida porque no saben como pintar globos que están dados la vuelta boca abajo, o lo que sea, así que van a ver el fichero de ayuda. Ahora, algún molesto programador del motor de índices de ayuda de Microsoft, con una exagerada idea de su propia importancia en el esquema total de las cosas, tiene la audacia, la jeta de interrumpir al usuario una vez más y empezar a darle clases de cómo hacer listas (o bases de datos). Este segundo nivel de interrupción no tiene nada que ver con las invitaciones del cumpleaños, y simplemente garantiza la perplejidad del usuario y finalmente conseguir que se cabree. Y creedme, a los usuarios les importan menos cosas de lo que cabría suponer. Usan tu programa para realizar un tarea. Lo que les importa es la tarea. Si es un programa gráfico, probablemente querrán ser capaces de controlar cada pixel hasta el más fino nivel de detalle. Si es una herramienta para construir sitios web, seguro que están obsesionados con hacer que la página web sea exactamente de la manera que ellos quieren que sea. A ellos, sin embargo, no les importa un comino si la barra de botones del programa está arriba o abajo. No les importa cómo se indiza un fichero. No les importan un montón de cosas, y es la responsabilidad del diseñador hacer estas elecciones, de manera que ellos no tengan que hacerlo. Es el colmo de la arrogancia para un diseñador de software infligir una elección como ésta al usuario simplemente porque el diseñador no pudo pensar lo suficiente como para decidir qué opción es la mejor (Es incluso peor cuando intentas tapar el hecho de que estás dando al usuario una elección difícil conviertiendolo en un asistente, como hizo la gente de la ayuda de Windows. Como si el usuario fuera un gañán que necesitara hacer un minicurso de 2 lecciones en la elección que se les ofrece, de manera que puedan tomar una decisión inteligente). Se dice que el diseño es el arte de tomar decisiones. Cuando diseñas una papelera para una esquina, tienes que tomar decisiones entre requisitos conflictivos. Tiene que ser pesada, así no se volará. Tiene que ser ligera, para que así el barrendero la pueda volcar. Tiene que ser grande, de manera que quepa mucha basura. Tiene que ser pequeña, así no molesta al paso de la gente en la acera. Cuando estás diseñando, y declinas tu responsabilidad forzando al usuario a que decida algo, probablemente no estás haciendo tu trabajo. Alguien más hará un programa más fácil que realice la misma tarea con menor intrusión, y les encantará a la mayoría de los usuarios. Cuando Microsoft Excel 3.0 salió en 1990, era la primera aplicación que lucía una característica llamada barra de herramientas. Era una característica razonable, a la gente le gustaba y todo el mundo la copió -- hasta el punto de que no es usual ver una aplicación sin una de ellas nunca más. La barra de herramientas tuvo tanto éxito, que el equipo de Excel hizo investigación de campo usando una versión de Excel que distribuyeron a unas pocas personas; esta versión mantenía estadísticas de qué comandos eran los más frecuentes y se informó de ello a Microsoft. Para la siguiente versión, añadieron otra fila de botones, esta vez, conteniendo los comandos más usados. ¡Bien! El problema era que nunca se les ocurrió disolver el equipo de la barra de botones, que parecía no darse cuenta de cuando debían parar. Querían que tú fueras capaz de personalizar tu barra de herramientas. Querían que tú pudieras arrastrar la barra a cualquier parte de la pantalla. Entonces, empezaron a pensar que realmente, la barra de menú es una barra de botones glorificada con palabras en lugar de botones, así que permitieron que pudieras arrastrar la barra de menú a cualquier punto de la pantalla también. Personalización a tope. Problema: ¡a nadie le importa! Nunca he encontrado a alguien que quiera su barra de menú en otra sitio que no sea la parte superior de la ventana. Pero aquí esta el chiste (malo): si intentas tirar del menú hacia abajo, y accidentalmente coges la barra de menú un poquito más lejos hacia la izquierda, arrancas la barra entera de menú, arrastrandola al único sitio donde posiblemente no quieras que esté: tapando el documento en el que estás trabajando. ¿Cuántas veces habéis visto eso? Y una vez que está hecho, no está claro lo que hiciste o cómo arreglarlo. Así que aquí tenemos una elección (mover la barra de menú) que nadie quiere (bueno, tal vez un 0,1% de la humanidad lo quiere), pero que se interpone en el camino de todo el mundo. Un día, una amiga me llamó. Tenía problemas enviando el correo. La mitad de la pantallas estaba gris, decía. ¿Que la mitad de la pantalla estaba gris? Me llevó cinco minutos al teléfono intentar averiguar qué había pasado. Había arrastrado accidentalmente la barra de tareas de Windows a la derecha de la pantalla y luego, también accidentalmente, la había ensanchado: Esta es la clase de cosas que nadie hace a propósito. Y hay un montón de usuarios de ordenadores que no saben salir de este lío; por definición, cuando reconfiguras accidentalmente una de las opciones de tu programa, no sabes como re-reconfigurarla. Es casi asombroso cuánta gente desinstala y vuelve a instalar su software cuando las cosas empiezan a comportarse de manera extraña, porque al menos, saben cómo hacerlo (Aprendieron a desinstalar primero, porque de otra manera, todas las configuraciones extrañas volverían a aparecer). "¡Pero, espera!", dices. "¡Es importante tener opciones para usuarios avanzados que quieran retocar su entorno!". En verdad, no es tan importante como crees. Esto me recuerda a cuando intenté cambiar a un teclado Dvorak. El problema era que no uso un solo ordenador. Uso ordenadores de todas las clases. Uso ordenadores de otras personas. Uso normalmente tres ordenadores en casa y otros tres en el trabajo. Uso ordenadores en el laboratorio de pruebas en el trabajo. El problema de personalizar tu entorno es que los cambios no se propagan, así que ni siquiera merece la pena. La mayoría de los usuarios avanzados usan varios ordenadores normalmente; actualizan su equipo cada dos años, reinstalan sus sistemas operativos cada tres semanas. Es cierto que la primera vez que supieron que se podía remapear el teclado en Word, cambiaron todo para hacerlo lo más agradable a su gusto, pero tan pronto como se actualizaron a Windows 95, aquellas configuraciones se perdieron, y no eran las mismas que las del trabajo, y eventualmente dejaron de configurar las cosas. He preguntado un montón a mis amigos "usuarios avanzados" acerca de esto; rara vez alguno de ellos personaliza algo que no sea lo mínimo para que su sistema se comporte de manera razonable. Cada vez que proporcionas una elección, estás pidiendo al usuario que tome una decisión. Esto significa que tendrán que pensar acerca de algo y decidir. Esto no es necesariamente mala cosa, pero en general, deberías intentar minimizar el número de decisiones que la gente ha de tomar. Esto no significa que haya que eliminar todas las elecciones. Hay aún suficientes decisiones que los usuarios tendrán que tomar en cualquier caso: el aspecto que tendrá su documento, la manera en que se comportará su web, o cualquier otra cosa que tenga que ver con la tarea que el usuario está haciendo. En estas áreas, desparrama: está muy bien darles opciones a la gente: de cualquier modo, cuantas más, mejor. Y hay otra categoría de elecciones que gustan a la gente: la posibilidad de cambiar el aspecto visual de las cosas, sin cambiar su comportamiento. A todo el mundo le gustan las pieles (skins) del WinAmp; todos ponemos una imagen de fondo de escritorio. Dado que esto afecta el aspecto visual sin cambiar la manera en que algo funciona, y que los usuarios tienen la libertad de ignorar las opciones y no por ello dejar de hacer su trabajo, este es un buen uso de las opciones. Diseño de Interfaz de Usuario para Programadores Capítulo 4: Invitaciones y Metáforas Por Joel Spolsky Traducido por Angel García Cuartero Editado por José Manuel Navarro 18. 4. 2000 Desarrollar una interfaz de usuario donde el modelo del programa coincida con el modelo de usuario no es fácil. A veces, puede que tus usuarios no tengan una expectativa concreta de cómo funciona el programa y qué se supone que debe hacer. En este caso, vas a tener que darle pistas de cómo funciona. Con las interfaces gráficas, una forma muy común de resolver el problema es mediante metáforas. Pero no todas las metáforas se crean de la misma manera y es importante comprender por qué las metáforas funcionan, de manera que sepas si has conseguido una buena. La más famosa metáfora es la "metáfora de escritorio" usada en Windows y en Macintosh. Tienes estas pequeñas carpetas con ficheros en ellas, las cuales puedes arrastrar por ahí. Puedes arrastrar un fichero de una carpeta a otra para moverlo. La razón por la que esta metáfora funciona es porque las pequeñas imágenes de carpetas realmente recuerdan carpetas a la gente, lo que les hace darse cuenta de que pueden poner documentos en ellas. Aquí hay una captura de pantalla de Kai's Photo Soap. ¿Sabes cómo ampliar la imagen? No es muy difícil. La lupa es una metáfora del mundo real. La gente sabe qué se supone que hace. Y no hay peligro de que esta operación de ampliación modifique la imagen, ya que no es lo que las lupas hacen. Una metáfora, incluso una imperfecta, funciona mejor que si no tienes ninguna. ¿Adivinas cómo ampliar con Microsoft Word? Word tiene dos pequeñas lupas en su interfaz, pero una de ellas está en el botón "Vista preliminar" (por alguna razón), y la otra está en el botón "Mapa del documento", sea lo que sea eso. La manera real de cambiar el nivel de zoom es con el campo desplegable en el que ahora pone "100%". Ni siquiera es un intento de metáfora, con lo que es incluso más difícil para los usuarios averiguar como hacer zoom. Esto no es necesariamente malo; hacer zoom probablemente no es lo suficientemente importante en un procesador de textos como para justificar tanto espacio de pantalla como hace Kai. Pero es una apuesta segura que serán capaces de usar el zoom más usuarios de Kai que de Word. Una metáfora mal elegida es peor que ninguna metáfora en absoluto. ¿Recordáis el maletín de Windows 95? Este iconito tan mono ocupó más o menos unos 3 centímetros cuadrados en el escritorio de todo el mundo durante unos cuantos años hasta que Microsoft se dio cuenta de que nadie lo quería. Y nadie lo quería porque era una metáfora rota. Se supone que era un "maletín", donde ponías tus ficheros para llevarte a casa. Pero cuando te ibas a llevar los ficheros a casa, resulta que todavía los tenías que poner en un disco. Así que, ¿los pongo en el maletín o en el disco? Ni idea. No entiendo el maletín. Nunca llegué a usarlo. Invitaciones Los objetos bien diseñados dejan claro cómo funcionan sólo con verlos. Algunas puertas tienen grandes placas de metal a la altura del brazo. Lo único que puedes a una placa de metal es empujarla. En palabras de Donald Norman, la placa te invita a empujar. Otras puertas tiene asas grandes y redondeadas que hacen que quieras tirar de ellas. Incluso sugieren cómo quieren que pongas la mano en el asa. El asa te invita a tirar. Hace que quieras tirar de ella. Otros objetos no están tan bien diseñados y no se puede averiguar qué hacen. La quintaesencia de esto que digo es la caja de CD, que requiere que pongas los pulgares de cierta manera y tires en cierta dirección. Nada en el diseño de la caja indica cómo se supone que tienes que abrirla. Si no conoces el truco, es muy frustrante, porque la caja no se abre. La mejor manera de proponer una invitación es hacer eco de la mano humana en un "espacio negativo". Mira de cerca a la (excelente) cámara digital Kodak DC-290, mostrada aquí por delante y por detrás. De frente, puedes ver una gran empuñadura de goma en la que parece que encajan tus dedos. Aún más inteligente, por detrás, en la esquina inferior izquierda, puedes ver una depresión que se parece familiarmente a la huella de un pulgar. Cuando pones tu pulgar izquierdo ahí, tu dedo índice izquierdo se enrosca de manera muy cómoda en la parte frontal de la cámara, entre las lentes y otro asidero de goma. Es como una sensación agradable que no habías sentido desde que te chupabas el dedo (y enroscabas tu índice alrededor de tu nariz). Los ingenieros de Kodak sólo intentan persuadirte de que cojas la cámara con ambas manos en una posición que asegure que la cámara sea más estable, e incluso apartar algún dedo descarriado de tapar el objetivo por error. Toda esta goma no es funcional, su único propósito es incitarte a que cojas la cámara correctamente. Las buenas IU informáticas también proponen invitaciones. Hace unos diez años, la mayoría de los botones se hicieron "3D". Usando sombras de gris, parecía que se salían de la pantalla. Esto sólo no es para que parezcan chulos: es importante porque los botones 3D invitan a ser pulsados. Parece que sobresalen y que la manera de usarlos es pulsando en ellos. Desafortunadamente, estos días, muchos sitios web (desconocedores del valor de las invitaciones) tienen botones que parecen chulos, mas que botones que parecen pulsables; como resultado, a veces tienes a la caza del sitio donde pulsar. Mira este anuncio: Los botones "Go" y "Login" sobresalen y parece que quieran que los pulses. Los botones "Site Map" y "Help" no parecen tan pulsables, de hecho, parecen exactamente lo mismo que la etiqueta QUOTES que no es pulsable. Hace cerca de cuatro años, en muchas ventanas empezaron a brotar tres pequeñas muescas en la esquina inferior izquierda que parecen un asidero. Parece esa clase de cosas que alguien pone en un interruptor que desliza para aumentar la fricción. Invita a arrastrar. Está rogando que la arrastren para estirar la ventana. Finalmente, uno de los mejores ejemplos de invitación es es famoso "diálogo con pestañas". ¿Te acuerdas del viejo panel de control de los Mac? La idea era que elegías uno de los iconos de la lista (deslizante) de la izquierda. Según pulsas el icono, la parte derecha de la pantalla cambia. Por alguna oscura razón, este tipo de indirección les resultaba increíblemente lógicas a los programadores que lo diseñaron, pero muchos usuarios no lo comprendían. Entre otras cosas, la gente raramente averiguaba cómo deslizar la lista para sacar más de los primeros 4 paneles. Pero más críticamente, la mayoría de la gente ni siquiera comprendía que hubiera una conexión entre los iconos y el cuadro de diálogo. Los iconos realmente parecían que eran una de las opciones. Desde más o menos 1992, estas interfaces empezaron a desaparecer, para ser reemplazados con un invento llamado diálogo con pestañas: Los diálogos con pestañas son una gran invitación. Es realmente obvio en esta imagen que tienes seis pestañas; es realmente obvio en qué pestaña estás, y es realmente obvio cómo cambiar a otra pestaña. Cuando Microsoft hizo las primeras pruebas de usabilidad de la interfaz con diálogos de pestañas, la usabilidad subió de un 30% (la antigua manera de Mac) al 100%. Literalmente, cada uno de los usuarios de pruebas se averiguaba cómo funcionaban los diálogos de pestañas. Dado el destacable éxito de esta metáfora, y el hecho de que el código para estos diálogos está incluido en Windows y está disponible prácticamente gratis, es una incógnita ver aplicaciones que todavía no saquen partido de ella. Estas aplicaciones sufren de hecho de problemas mensurables del mundo real porque rehusan a ponerlas en el programa. Diseño de Interfaz de Usuario para Programadores Capítulo 5: Consistencia y Otros Duendes Por Joel Spolsky Traducido por Angel García Cuartero 22. 4. 2000 Los principales programas en la suite Microsoft Office, Word y Excel, se desarrollaron desde cero en Microsoft, pero otros se compraron de compañías externas, destacando FrontPage (comprada a Vermeer) y Visio, comprada a Visio. ¿Qué tienen en común estos programas? Originalmente fueron diseñados para tener el aspecto y comportamiento que tenían las aplicaciones de Microsoft Office. La decisión de emular la IU de Office no fue meramente "copiar" a Microsoft ni disponer a las empresas en una posición favorable para su compra; en realidad, Charles Ferguson, que desarrolló FrontPage, no dudó en admitir su antipatía por Microsoft; repetidamente suplicó al departamento de Justicia que hiciera algo respecto a las Bestias de Redmond (hasta que les vendió su compañía, tras lo cual su posición se hico algo más complicada). De hecho, Vermeer y Visio parecían haber copiado la IU de Office principalmente porque era conveniente: era más fácil y rápido que reinventar la rueda. Cuando Mike Mathieu, un director de grupos de programas de Microsoft, descargó FrontPage del sitio web de Vermeer y lo probó, resulta que funcionaba casi todo como en Word. Dado que funcionaba de la manera que él esperaba que un programa fuera a funcionar, era más fácil de usar. Y esta facilidad de uso le dio una impresión favorable del programa desde la casilla de salida. Bien, cuando Microsoft tiene una impresión favorable de un programa desde la casilla de salida, resulta que venden unos 150 millones de dólares, más o menos. Tu objetivo es un poco más modesto; quieres que tus programas causen una impresión favorable y por ello vender tal vez 39 millones de dólares. Pero es la misma idea: la consistencia da lugar a facilidad de uso, que a su vez, da lugar a buenas sensaciones, que tienen como resultado más dinero para ti. Es difícil hacer una estimación de cuánta consistencia ayuda a la gente a aprender y a usar una gran variedad de programas. Antes de las interfaces gráficas, cada programa reinventaba los fundamentos de interfaz de usuario. Incluso una simple operación como "salir" que todos los programas debían tener, era completamente inconsistente. En aquellos días la gente memorizaba, al menos, el comando salir de los programas comunes, de manera que podían usarlos y salir. Los fanáticos de Emacs memorizaban ":q!" (y nada más) en caso de que se encontraran atascados por error usando vi, mientras que los usuarios de vi memorizaban "C-x C-c" (Emacs incluso tiene su propia manera de representar los caracteres de control). En la tierra de DOS, ni siquiera podías usar Wordperfect a menos que tuvieras una de esas lamentables plantillas de plástico que te recordaban lo que hacía Alt+Ctrl+F3. Yo sólo memoricé F7, que te sacaba de todo aquello. No sólo eso, sino que pequeñas inconsistencias en cosas como el modo de tecleado por defecto (sobreescribir o insertar) puede volverte loco. Me acostumbrado tanto a Ctrl+Z para "deshacer" en aplicaciones Windows que cuando uso Emacs constantemente me encuentro minimizando la ventana (Ctrl+Z) por error (Lo divertido es que la auténtica razón por la que Emacs interpreta Ctrl+Z como minimizar es por consistencia con esa terrible interfaz de usuario, csh, la C shell de UNIX). Esta es una de esas frustraciones menores que se van sumando a ese sentimiento general de infelicidad. Para coger un ejemplo incluso más pequeño, Pico y Emacs usan ambos Ctrl+K para borrar líneas, pero con una ligera diferencia de comportamiento que habitualmente maltrata mis documentos cuando me encuentro trabajando en Pico. Estoy seguro de que tú mismo tienes una docena de ejemplos de tu propia cosecha. En los primeros días del Macintosh, antes de Microsoft Windows, los evangelistas de Apple decían a todo el mundo que el usuario medio de Mac usaba más variedad de programas para hacer su trabajo que el usuario medio de DOS. No recuerdo los números exactos, pero creo que era algo así como uno o dos programas para el usuario medio de DOS, contra doce programas para un usuario de Mac. El motivo por el que era tan fácil aprender un nuevo programa de Mac era porque generalmente funcionaban de la misma manera. La consistencia es el principio fundamental de un buen diseño de IU, pero es tan sólo un corolario del axioma "haz que el modelo de programa se ajuste al modelo de usuario", porque el modelo de usuario va a reflejar la manera en que los usuarios ven cómo se comportan otros programas. Si el usuario ha aprendido que hacer doble clic en un texto significa seleccionar palabra, puedes enseñarle un programa que no hayan visto nunca antes y adivinarán que la manera de seleccionar una palabra es haciendo doble clic. Ahora bien, será mejor que se seleccione la palabra cuando se hace clic (en oposición, digamos, a buscar la palabra en el diccionario), o de lo contrario tienes un problema de usabilidad. Si la consistencia es tan obviamente beneficiosa, ¿por qué estoy desperdiciando el tiempo evangelizando al personal? Desafortunadamente, hay una fuerza oscura ahí fuera luchando contra la consistencia, y es esa tendencia natural de los diseñadores y programadores a ser creativos. Mira, odio ser el que diga "no seas creativo", pero desafortunadamente, para hacer una interfaz de usuario fácil de usar, tienes que canalizar tu creatividad en otra área. En la mayoría de las decisiones de IU, antes de diseñar algo desde cero, tienes que mirar qué están haciendo otros programas conocidos y emularlos de una manera tan parecida como te sea posible. Si estas creando un editor de documentos del tipo que sea, mejor que se parezca un montón a Microsoft Word, hasta los atajos de teclado de los menúes que tengas en común. Algunos de tus usuarios usarán Ctrl+G para guardar; algunos estarán habituados a Alt+F, G para guardar y otros todavía usarán Alt, F, S (Soltando la tecla Alt). Otro grupo buscará el icono del disco en la parte superior y lo pulsarán. O funcionan los cuatro, o tus usuarios van a tener algo que no quieren. He visto empresas donde la dirección se enorgullece de hacer las cosas deliberadamente de manera distinta a Microsoft. "Sólo porque lo haga Microsoft, no significa que esté bien", proclaman, y entonces van y se crean gratuitamente una interfaz diferente de lo que la gente está acostostumbrada a usar. Antes de que empieces a repetir el mantra de "sólo porque lo haga Microsoft, no significa que esté bien", por favor, considera estas dos cositas: Aún si no es correcto, si Microsoft lo hace en un programa conocido como Word, Excel, Windows o Internet Explorer, entonces hay millones de personas que van a pensar que está bien, o al menos, que conforma un cierto estándar, y van a asumir que tu programa funciona igual. Incluso si piensas (como los ingenieros de Netscape 6.0 claramente hicieron) que Alt+Izquierda no es un buen atajo de teclado para "Atrás", hay literalmente millones de personas que intentarán usar Alt+Izquierda para ir atrás, y si rehusas a hacerlo así basándote en alguna norma de tipo religioso que diga que Bill Gates es el malvado enemigo de los pitufos Gargamel, entonces lo que estás haciendo es arruinar tu programa de manera que tú te sentirás satisfecho y tus usuarios no te lo van a agradecer. No estés tan seguro de que no está bien. Microsoft se gasta muchísimo más dinero en usabilidad de lo que tú haces, mantienen estadísticas detalladas basadas en millones de llamadas de soporte técnico y vamos, tienen una buenísima oportunidad de que lo hayan hecho de esa manera porque hay mucha gente que se imagina que aquello funciona de esa manera. Para crear un buen programa con una interfaz de usuario decente, te vas a tener que dejar tu religión en la puerta antes de empezar, gracias. Puede que Microsoft no sea la única empresa a copiar: si vas a montar una tienda de libros, deberías asegurarte de tu sitio web es, al menos semánticamente, igual a Amazon. Amazon mantiene tu carrito de la compra durante 90 días. Tal vez puedas pensar que eres super-listo y vacíes el carrito al pasar 24 horas. Si haces esto, habrá algún cliente de Amazon que haya puesto cosas en su carrito de la compra y vuelva dos semanas más tarde esperando encontrarlas allí. Cuando vea que no están, has perdido un cliente. Si estás pensando en hacer un editor de alta gama para gráficos profesionales, te aseguro de que el 90% de tus usuarios sabrán usar Adobe Photoshop, así que será mejor que tu programa se parezca un huevo a Photoshop en las áreas en las que coincidan. Si no lo hace, la gente dirá que tu programa es difícil de usar, incluso si tú piensas que es más fácil de usar que Photoshop, porque no se comporta de la manera que ellos esperan que lo haga. Hay otra tendencia popular a reinventar los controles comunes que vienen con Windows. Ni siquiera voy a comentar lo de Netscape 6. Había un tiempo en el que podías decir cuándo un programa estaba compilado con Borland C++ porque tenían unos botones de "Aceptar" grandes y anchos con una marca de verificación gigante y verde. Eso no era ni la mitad de malo que Kai's Photo Soap: Bueno, la verdad es que guapo, pero la O con una línea atravesada (que de hecho significa "no") me recuerda al "OK", y el estándar en Windows es tener el OK en la izquierda, así que me encontraba pulsando el botón equivocado un montón de veces. El único beneficio que tenía el hecho de mostrar unos botones extraños, en lugar de "Aceptar" y "Cancelar" como todo el mundo, era vacilar de lo creativo que eras. Si la gente se equivoca debido a la creatividad de Kai, bueno, es sólo el precio que hay que pagar por estar en presencia de un artista. (Otro problema con este diálogo es que no tiene una barra de título estándar que se pueda usar para moverlo por la pantalla. Así que si el diálogo se interpone en medio de algo que quieras ver para responder a la pregunta que el propio diálogo te hace, lo llevas claro). Ahora bien, hay un montón que ganar si tienes una interfaz de usuario que mola y que está logrado. Un buen diseño gráfico como el de Kai es agradable y hará que tu programa atraiga a la gente. El truco es hacerlo sin romper las reglas. Puedes cambiar el aspecto visual de los diálogos, un poquito, pero no la funcionalidad. Cuando se escribió la primera versión de Juno, tenía el diálogo inicial estándar de acceso que te pedía un usuario y una contraseña. Después de haber introducido el nombre, se supone que debías pulsar TAB para ir al campo de contraseña y teclearla. Bueno, pues esto distrajo a uno de los jefes de programación de Juno, que tenía muchísima más experiencia en UNIX que en Windows, así que él estaba acostumbrado a teclear el nombre, pulsar luego la tecla ENTER para saltar al campo de contraseña (en lugar de TAB). Vale, pues cuando estás escribiendo un programa orientado a usuarios no expertos de Windows, un programador de UNIX no es probablemente el ejemplo ideal de un usuario típico, pero este jefe insistía mucho en que la tecla intro debería mover el cursor al siguiente campo, en lugar de hacer lo habitual en Windows, "Aceptar". "Sólo porque Microsoft lo haga, no significa que esté bien", parloteaba. Así que los programadores perdieron una considerable cantidad de tiempo escribiendo código asombrosamente complicado para que un diálogo no se comportara de la manera habitual en Windows. (Ser inconsistente es casi siempre más trabajo que simplemente comportarse de la manera que tu plataforma espera que lo hagas). Este código es una pesadilla de mantenimiento enorme; no se tradujo muy bien cuando nos mudamos de Windows 16 bits a 32 bits. No hacía lo que la gente esperaba. Y según se iban uniendo programadores nuevos al proyecto, no entendían por qué las cosas estaban hechas de una manera tan rara con este diálogo. Una gran cantidad de programadores han intentado reimplementar varios de los controles comunes de Windows, desde botones, barras de desplazamiento y barras de herramientas hasta barras de menú (la favorita para reimplementar del equipo de Microsoft Office). Netscape 6.0 fue tan lejos como para reimplementar todos y cada uno de los controles comunes de Windows. Esto usualmente tiene efectos imprevistos. El mejor ejemplo es el campo de edición. Si reimplementas el campo de edición, hay un montón de características de las que ni siquiera sabes nada (como los añadidos para el lenguaje chino y las versiones bidireccionales de Windows que soportan texto de derecha a izquierda) que van a dejar de funcionar porque no reconocen tu campo de edición no estándar. Algunos de los críticos de la versión previa de Netscape 6.0 se dieron cuenta de que la barra de direcciones, que usaba un control no estándar de edición, no soportaba características de edición comunes como hacer clic con el botón derecho para sacar el menú contextual. Cuando te encuentras discutiendo con un fundamentalista anti-Microsoft o con un diseñador gráfico creativo acerca de la consistencia, son propensos a citar a Emerson incorrectamente: "La consistencia es el duende de las pequeñas mentes...". La cita real es "Una consistencia estúpida es el duende de las pequeñas mentes". Los buenos diseñadores de IU utilizan la consistencia de manera inteligente, y aunque con ello no puedan chulearse de su creatividad, a largo plazo hace que los usuarios sean más felices. Diseño de Interfaz de Usuario para Programadores Capítulo 6: Diseñando para gente que tiene cosas mejores que hacer con su vida Por Joel Spolsky Traducido por Raúl Herranz Serrano 26. 4. 2000 Cuando diseñas interfaces de usuario, es una buena idea mantener los siguientes dos principios en mente: Los usuarios no tienen el manual, y si lo tuvieran, no lo leerían. De hecho, los usuarios no pueden leer nada, y si pudiesen, no querrían leerlo. Estos no son, hablando de forma estricta, hechos, pero deberías actuar como si lo fueran, porque esto te permitirá hacer tus programas más sencillos y amigables. Diseñas con estas ideas en mente se conoce como respetar al usuario, lo que significa no tener mucho respeto por el usuario. ¿Confundido? Déjame que te explique. ¿Qué significa hacer algo fácil de usar? Un modo de medir esto es ver qué porcentaje de usuarios reales son capaces de completar tareas en una cantidad de tiempo dada. Por ejemplo, supón que la finalidad de tu programa es permitir a la gente convertir fotos tomadas con su cámara digital en un álbum de fotos web. Si sientas a un grupo de usuarios medios delante de tu programa y les pides que completen la tarea, entonces cuanto más usable sea tu programa, el porcentaje de usuarios que son capaces de crear el álbum de fotos web será mayor. Para verlo desde un punto de vista científico, imagina 100 usuarios del mundo real. No tienen por qué estar familiarizados con los ordenadores. Estas personas tendrán muy diferentes talentos, pero algunos de ellos no tienen ningún talento en el área del uso de ordenadores. Algunos se distraerán mientras estén usando el programa. El teléfono suena. ¿QUÉ? El niño llora. ¿QUÉ? Y el gato se dedica a saltar por la mesa jugando con el ratón. ¡NO PUEDO OÍRTE! Ahora, incluso sin llevar a cabo el experimento, te puedo asegurar con cierta confianza que algunos de estos usuario simplemente no llegarán a completar la tarea, o les llevará una cantidad de tiempo extraordinaria hacerlo. No quiero decir con esto que estos usuarios sean estúpidos. Más bien lo contrario, seguramente ellos tendrán una inteligencia superior, o quizá sean grandes atletas, pero en un vis-à-vis con tu programa, no están aplicando todas sus capacidades motoras ni todas sus neuronas a su uso. Únicamente estás consiguiendo captar aproximadamente un 30% de su atención, por lo tanto tendrás que conformarte con un usuario que, desde el interior del ordenador, parecerá que no está jugando con el tablero completo. Los Usuarios No Leen los Manuales. En primer lugar, ellos no tienen el manual. Puede que no haya un manual. Si hay uno, el usuario no lo tendrá debido a toda una serie de razones lógicas: están en un avión; están usando una versión de demostración obtenida de tu página web; están en casa y el manual está en la oficina; su departamento de informática nunca les dio el manual. Incluso si tienen el manual, francamente, ellos simplemente no van a leerlo a no ser que esta sea la única posibilidad. Con muy pocas excepciones, los usuarios no tomarán tu manual entre sus brazos ni lo leerán de cabo a rabo antes de empezar a usar tu software. En general, tus usuarios tratarán de conseguir algo hecho, y para ellos, leer el manual será visto como malgastar el tiempo, o como mucho, como una distracción que les impedirá tener sus tareas realizadas. El mismo hecho de que estés leyendo este libro te coloca en el grupo de élite de gente con grandes capacidades literarias. Si, ya sé que la gente que usa los ordenadores son perfectamente capaces para leer, pero te garantizo que un porcentaje muy alto de ellos encontraran la lectura como un deber. El idioma en el que esté escrito el manual puede que no sea su primer idioma, y posiblemente no puedan leer con perfecta fluidez el texto. ¡Serán niños! Ellos podrán descifrar el texto si realmente se ven en la necesidad, pero puedes estar seguro de que no lo leerán si no está obligados a hacerlo. Los usuarios utilizan técnicas just-in-time (justo a tiempo) para la lectura de los manuales en base a sus necesidades de conocimiento. Lo realmente importante de todo esto es que no tendrás más remedio que diseñar tu software de un modo tal que no sea necesario la lectura del manual de usuario para poder empezar a utilizarlo. La única excepción a esta regla que se me ocurre es cuando los usuario no tienen ningún conocimiento del dominio -- no entienden qué se supone que el programa debe hacer, pero saben que es mejor aprender a utilizarlo. Un buen ejemplo de esto es el inmensamente popular programa de contabilidad para pequeñas empresas de Intuit, QuickBooks. Muchas de la personas que usan este programa son los propietarios de pequeños negocios, los cuales simplemente no tienen ni idea de los entresijos de la contabilidad. El manual de QuickBooks asume esto y asume que tendrá que enseñar los principios básicos de contabilidad a los usuarios. No hay otra forma de hacerlo. Además, si ya tienes conocimientos de contabilidad, QuickBooks es sencillo de usar sin necesidad de leer el manual. De hecho, los usuarios no leen nada. Esto puede sonar un poco fuerte, pero verás, cuando realizas tests de usabilidad, que hay unos cuantos usuarios que simplemente no leen las palabras que pones en la pantalla. Si abres una ventana de error del tipo que sea, simplemente no lo leerán. Esto puede ser muy desconcertante para ti como programador, porque tú te imaginas a ti mismo manteniendo un diálogo con el usuario. ¡Eh, usuario! ¡No puedes abrir este fichero, no soportamos su formato! De todas formas, la experiencia muestra que cuantas más palabras aparezcan en tus ventanas de diálogo, menos gente se parará a leerlas. El hecho de que los usuarios no lean los manuales hace que muchos diseñadores de software asuman que van a tener que educar a los usuarios a través de descripciones a lo largo de todo el programa. Este tipo de comportamiento lo verás por todas partes en distintos programas. En principio, no hay nada malo en actuar así, pero en realidad, la aversión que tiene la gente a la lectura implica que actuar de este modo siempre te meterá en algún problema. Los diseñadores UI experimentados tienen a minimizar al máximo el número de palabras en los diálogos para incrementar el número de posibilidades de que sean leídos. Cuando trabajé en Juno, la gente de UI comprendía este principio y trató de escribir textos cortos, claros y simples. Por desgracia, el CEO de la compañía había sido decano de Inglés en una universidad de la Liga Ivy; él no tenía ningún conocimiento en diseño de Interfaces de Usuario o en ingeniería del software, pero seguramente él pensó que era un buen editor de prosa. Por tanto, vetó el trabajo que habían realizado los diseñadores UI profesionales y añadió una gran cantidad de prosa propia. Un diálogo típico en Juno es como el siguiente: Compáralo con el diálogo equivalente de Windows: Por intuición podrías pensar que la versión de Juno, con 80 palabras de instrucciones, podría definirse como "superior" (es decir, más fácil de usar) que la versión de Windows, con 5 palabras de instrucciones. En realidad, cuando haces pruebas de usabilidad encontrarás que los usuarios avanzados obviarán las instrucciones. Asumirán que ya saben usarlo y que no tienen tiempo para leer complejas instrucciones. la mayoría de los nuevos usuarios obviarán las instrucciones. No les gusga leer demasiado y esperarán que la opción por defecto sea la correcta. el resto de los nuevos usuarios, los cuales intentarán, en serio, leer las instrucciones (algunos de ellos sólo lo harán porque están en un test de usabilidad y se sentirán obligados) normalmente se sentirán confundidos por la gran cantidad de palabras y conceptos. Por tanto, incluso aunque confiasen en que podían usar el diálogo cuando este apareció, las instrucciones que han leído consiguen confundirlos más aún. Claramente, Juno fue "micro-manejada" (micro-managed) más allá de toda razón. Volviendo al punto clave, si tu eres un decano de Inglés en Columbia, entonces estás en una liga literaria completamente diferente al del Joe medio, y deberías ser tremendamente cuidadoso cuando eliges las palabras para los diálogos que a ti te parecen que pueden ayudar. Acórtalos, hazlos para idiotas, simplifícalos, olvídate de las cláusulas complicadas entre paréntesis, y haz tests de usabilidad. Pero no escribas frases que parezcan tesis de una universidad de la Liga Ivy. Incluso añadir las palabras "por favor" al diálogo, lo cual podría parecer que ayuda además de ser cortés, va a hacer que la gente lea más despacio. Cuanto mayor sea el número de palabras más se reducirá, en porcentajes que podrás medir fácilmente, el número de la gente que leerá el texto. Otro punto importante es que mucha gente se intimida por los ordenadores. Probablemente esto ya lo sabes, ¿verdad? Pero no te das cuenta de las implicaciones que esto puede tener. Estaba mirando como una amiga intentaba salir de Juno. Por alguna extraña razón estaba teniendo problemas. Me di cuenta entonces que cuando intentas salir de Juno aparece el siguiente diálogo: Ella estaba pulsando No, y luego se quedaba sorprendida cuando Juno no se cerraba. El hecho de que Juno le estuviese realizando una pregunta le hacía asumir de forma automática que estaba haciendo algo mal. Normalmente, cuando los programas te solicitan confirmar un comando es porqué estás a punto de realizar una acción que no puede deshacerse. Ella tenía asumido que si el ordenador cuestionaba su juicio, entonces el ordenador debía tener la razón, porque, después de todo, los ordenador son ordenadores mientras que ella sólo es humana, por tanto, ella pulsaba "No". ¿Es demasiado pedir a la gente que lea 11 palabras? Bien, aparentemente si. Lo primero, si salir de Juno no tiene efectos de gran impacto, Juno debería dejarte salir sin pedir confirmación, como cualquier otro programa. Pero incluso si estás convencido de que es crucial que la gente confirme salir del programa, podrías haber usado estas dos palabras en vez de las anteriores 11: Sin el completamente innecesario agradecimiento ni la pregunta "¿estás seguro de que...?", este diálogo parece un poco menos propenso a causar problemas. Los usuarios ciertamente leerán las dos palabras, pensarán "mmmm, ¿quiero?", y pulsarán el botón "Si". El diálogo de confirmación de salida de Juno puede gustar a unos pocos, podrás pensar, pero ¿acaso es esto tan importante? Todo el mundo finalmente podrá salir del programa. Pero aquí está la diferencia entre un programa que es posible usar frente a un programa que es fácil de usar. Incluso los usuarios avanzados, inteligentes y experimentados apreciarán todo aquello que hagas para facilitar el trabajo para los nuevos usuarios, los distraídos y los que tienen poca experiencia. Las bañeras de los hoteles tienen grandes agarraderas. Estas agarraderas permiten a la gente con discapacidad a salir de la bañera, pero en realidad, todo el mundo las usa. Hacen la vida más fácil incluso para aquellos que físicamente no tienen discapacidades. En el siguiente capítulo, hablaré un poco acerca del ratón. Exactamente igual que nuestros usuarios no leen/leerán/pueden leer, algunos no son muy buenos usando el ratón, por lo tanto vas a tener que acomodarte a ellos.