Capítulo 5: Consistencia y otros duendes

From The Joel on Software Translation Project

Jump to: navigation, search

Diseño de Interfaz de Usuario para Programadores
Capítulo 5: Consistencia y Otros Duendes

Por Joel Spolsky
22 de Abril de 2000
Traducido originalmente por: Angel García Cuartero
Editado por JM
Artículo original



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 Vi memorizaban ":q!" (y nada más) en caso de que se encontraran atascados por error usando vi, mientras que los usuarios de Emacs 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:


¿Salir de 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.


<< Capítulo 4: Invitaciones y Metáforas

>> Capítulo 6: Diseñar para gente que tiene cosas mejores que hacer con su vida


The Joel on Software Translation Project - Español

Personal tools