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 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.



> Capítulo 4

Esté articulo apareció originalmente en Inglés con el nombre User Interface Design for Programmers Chapter 3: Choices  

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