Diseño de Interfaz de Usuario para Programadores ... - Willy .Net

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:
1. 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.
2. 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.
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.
Esté articulo apareció originalmente en Inglés con el nombre User Interface Design for
Programmers Chapter 4: Affordances and Metaphors