Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

17 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
lunes, 16 de noviembre de 2009

¡Programadiseñadores al poder! Ya sabemos lo que suele ocurrir cuando los programadores diseñamos interfaces de usuario ;-). Para seguir profundizando en este curioso e inevitable fenómeno, Ian Voyce ha publicado hace unas semanas el divertido post The 7 signs your UI was created by a programmer, en el que recoge pistas que nos ayudarán a determinar si el interfaz de la aplicación que usamos a diario está creado por un diseñador experto en usabilidad, o ha sido el propio desarrollador el encargado de dichas tareas.

Bueno, en realidad se trata más bien de una lista con malos hábitos en el diseño de interfaces, y no necesariamente creados por programadores, pero ciertamente me he reconocido en alguno de los puntos y me han hecho gracia. Los cito y comento a continuación:

  • Iconos de exclamación en cuadros de diálogo
    Efectivamente, cuando incluimos una exclamación en un cuadro de diálogo no pensamos en que es posible que el usuario vea el mensaje 50 veces al día, con lo que dejaría de ser ese mensaje asombroso y puntual que pensamos en un principio. Hoy en día, muchas aplicaciones utilizan un tono mucho más neutral y cercano para enviar mensajes al usuario.

  • Mensajes con dobles negaciones en cuadros de diálogo, del tipo “¿Seguro de que no quieres perder tus cambios?” -- Hmm… sí… digooo, no…  También son muy propias construcciones más complejas de la cuenta, paradójicas o inesperadas, como “Su mensaje no se ha enviado, ¿desea descartarlo?”, que ponen a prueba los reflejos de cualquier usuario.

  • Orden de tabulación inexistente, o incorrecto, que fuerzan a que la navegación se realice exclusivamente a golpe de ratón. Y especialmente en aplicaciones de entrada masiva de información, el cambio de teclado a ratón y viceversa es terrible. Y paraGroupboxes para todo.. porque mola hacernos conscientes de ello, nada como dar vacaciones un rato al animalito y ver lo bien que manejamos determinadas aplicaciones.

  • Groupboxes rodeándolo todo… porque hay sitios donde queda bonito, aunque no esté agrupando nada ;-). Me confieso: durante años, he rodeado de groupboxes todo lo que se me ponía por delante, porque me parecía más agradable a la vista. Ahora lo estoy dejando ;-)

  • IconoIconos creados en el IDE, je, este es otro de mis puntos fuertes: soy un fiera diseñando iconos desde el editor de Visual Studio. El problema es que, a pesar de lo orgulloso que estoy siempre de mis creaciones artísticas, no quedan bien e incluso introducen un cierto tufillo a cutre en las aplicaciones.

  • Utilización de grids, debido a lo que llama Voyce “la enfermedad de considerar que Excel es lo máximo en diseño de interfaces de usuario”, que fomenta la creación de rejillas con controles de lo más potentes y variopintos en las filas de datos (calendarios, gráficos, etc.).

  • Message Boxes no implementados, el equivalente en los interfaces de usuario a los TODO en el código fuente :-DD. Buena analogía. Algo parecidos serían los mensajes del tipo “Este mensaje no debería aparecer nunca” que alguna vez he encontrado por ahí, auténticos actos de rebeldía contra sus respectivos creadores.

  • Uso excesivo de cuadros de diálogo, incluso en situaciones en las que perfectamente podríamos obviarlos por no ofrecer información útil para el usuario, que no va a poder entender, o donde no se requieren decisiones por su parte.

    Los componentes necesarios han sido detectados. Accediendo...Esto es algo muy frecuente de ver. Por ejemplo, el otro día accediendo a una aplicación web para la que es necesario contar con certificado digital, me saltó la alerta que muestro a la derecha:

    Sí, probablemente los componentes Java necesarios para la autenticación y firma electrónica hayan sido detectados con éxito, pero… ¿realmente era necesario interrumpir mi navegación para informarme de ello? ¿Un usuario, sabrá interpretar el mensaje? Y en cualquier caso, ¿le aporta algo? No sé, no sé… me da que es un alert() creado por un desarrollador durante las pruebas y que al final se quedó ahí para la posteridad.

Hasta aquí las citadas en el post original, aunque siguiendo en la misma línea, puedo añadir algunas más de propia cosecha:

  • Cuadros de diálogo con mensajes y botones inconsistentes. Mensajes del tipo “¿desea cancelar la operación?” en cuyo pie aparece un botón “Aceptar” y otro “Cancelar” siempre me dejan pensando un rato. Si pulso aceptar, ¿estoy aceptando la cancelación, o justo lo contrario?… Muchas veces, parece que sólo podemos confiar en el azar.

  • Cuadros de mensaje con demasiados (o demasiados pocos) botones. No siempre atendemos a la Ley de Hick, que nos dice que “el tiempo que se tarda en tomar una decisión aumenta a medida que se incrementa el número de alternativas”, y eso nos lleva a crear cuadros de diálogo con muchos, demasiados, botones que el usuario debe estudiar.

    Y justo en el lado contrario, pero igualmente desconcertantes, son los cuadros de diálogo de introducción de datos sin ningún botón de aceptación, en los que su cierre (con la X de la esquina superior) implica el salvado de datos.

  • Interfaz descuidado. Y no hablo de bonito o feo, términos bastante subjetivos, sino de descuidado: controles sin alinear, con tamaños no proporcionales al contenido pretendido, sensación de desorden, faltas de ortografía… Esto no es un problema de interfaces creados por desarrolladores, sino creados por gente que no pone el más mínimo cariño en lo que hace, independientemente de su puesto de trabajo.

  • Interfaces monocromos, mi especialidad. Como inútil reconocido en temas de diseño, me considero absolutamente incapaz de crear algo medio aparente con más de un color (eso sí, empleando distintas tonalidades ;-)). Nunca he entendido la compleja lógica que hay detrás del “eso no pega con aquello”, que algunos/as parecen dominar de serie.

  • Controles con trastorno de personalidad. Un clásico es encontrar un grupo de checkboxes actuando como un grupo de radios. A ver, si sólo vamos a poder elegir una de las opciones, ¿por qué no usamos directamente el control específicamente ideado para ello? ¿Y un desplegable con las opciones "Activar" y "Desactivar"? ¿No sería más claro poner un checkbox?

Artículo original: The 7 signs your UI was created by a programmer

Publicado en: Variable not found.

5 Comentarios:

Jorge Garmilla dijo...

Joder!!! que post más bueno... la verdad es que ha veces dan ganas de vomitar con "mierdas" (con respeto por supuesto) que se ven por ahí. Por ejemplo con mis primeros desarrollos ;-)

Jbot dijo...

Bueno.. algunas me parece bien , pero otras visto desde el punto "corporativo", no tanto...
Lo de los groupbox, si, los uso, pero mas a la hora de desarrollar, es mas para tener agrupado y tabindexado los controles (en .NET es mas facil para aquellas interfaces complejas).
Los dialogos, vale, pero es que el usuario final (hablo de empresas "importantes", donde los usuarios, se creen mas importantes aun y necesitan "explicacion de todo", incluso, mostrar los errores de oracle para controlar mejor un error futuro.. si, como lo ois).
Lo de los colores, no se... seguimos en la primera decena del siglo XXI y la tecnologia a usar es: VB6 o VBA con excel 2003... el color sigue siendo el gris, blanco, amarillo (info), azul clarito.. aunque ahora con el XAML (en .NET) usado en wpf (futuros interfaces) o silverlight, no veais como abuso de la degradacion coloril... que conste, que son momentos de extasis tras estar currando durante todo el dia en aplicaciones vb6 monotematicas.
En resumen... que llevo años con Microsoft (desde vb4) hasta ahora (vs2010 beta 2), y en el curro, en todos aquellos donde he estado, segun los estamentos corporativos, hemos de hacer todo eso que aqui "criticas" de manera sana, por que asi, esta acostumbrando el usuario ,que ha veces va de moderno, con su movil de ultima generacion, su PC mas y mejor (mientras nosotros, tenemos que abrir los entornos y cerrar otros, por que no tenemos ni memoria, ni velocidad , ni placa para soportarlo).
Y no te digo en la ONCE, donde la accesibilidad, condicion "ESENCIAL" y siguen manteniendo los mismos interfaces del 98 :o)))

Eusebio Reyero dijo...

Hola, un post buenísimo, me ha encantado. Creo que lo del interfaz del Excel lo citare.

Existe una situación en la que todo esto queda patente, el día que arranca el proyecto de re-diseño del interfaz, cuando todo el mundo empieza a mirarse, con cara de haber quien lo dice.

Un saludo.

josé M. Aguilar dijo...

Hola! Gracias a todos por comentar :-)

@jorge, todos tenemos un oscuro pasado que es mejor olvidar :-DD

@jbot, no es malo usar groupboxes, pero probablemente sí lo es usarlo como elemento meramente decorativo, como reconozco que era mi caso ;-). Tampoco es malo utilizar cuadros de diálogo, pero sí abusar de ellos....

Es cierto que determinados entornos corporativos, como comentas, pueden ser bastante restrictivos. Si usamos VBA en Office 2003, difícilmente vamos a poder conseguir efectos visuales como los que tenemos con WPF, pero aún así, seguro que se pueden diseñar buenos interfaces con esas herramientas (de hecho, en el post, la mayoría de "malas prácticas" serían aplicables a diseños de escritorio clásico como Winforms, o formularios de VB3).

Quizás el problema sea que la interfaz es uno de los aspectos a los que menos atención prestamos antes y durante el desarrollo de un sistema, y sin embargo, es la herramienta con la que trabajará el usuario todos los días...

@Eusebio, jejeje, en esas ocasiones hay que tirar por usar mensajes con corrección política... Un "se han detectado algunos aspectos mejorables en el interfaz" siempre es muy resultón. ;-DD

Saludos.

Marc Rubiño dijo...

Una gran Verdad !!!
Muy bueno José.