Top 10 de los errores en el diseño de aplicaciones
Publicado el Martes 19 de Febrero del 2008 @ 22:04 por Armonth.
Jakob Nielsen hoy ha lanzado otra alertbox: Top-10 Application-Design Mistakes y como las entradas “por puntos” nos gustan más que un lápiz a un tonto… pues toca mencionarlo }:P
El resumen es de puro sentido común y los puntos mencionados también pero pese a ello continuamente son ignorados y los resultados rara vez son buenos…
Cabe mencionar que el contexto se refiere a “aplicaciones web” pero sin embargo es perfectamente aplicable a aplicaciones comunes para escritorio ya que muchos controles son comunes: campos de selección, barras de scroll, “checkbox”, etcétera.
La “usabilidad” en aplicaciones funciona cuando los usuarios saben cómo usar la interfaz y ésta los guía para realizar el trabajo.
Los puntos a evitar, resumidos (recomiendo leer el original que profundiza en cada punto) son:
- Controles de la interfaz gráfica que no son estándares.
- Inconsistencia. Entre otras llamar a dos cosas iguales de distinta forma.
“No Perceived Affordance”. O en cristiano y sin hacer traducciones literales (y malas): que las acciones que hagas sean entendibles viendo el estado de los controles. Vamos que los controles deben ser intuitivos.
Suele verse este error cuando se tiene que hacer una tarea de “arrastrar y soltar” y en el proceso no se puede saber fácilmente si esta acción es posible de realizar.
No ofrecer información (feedback) del estado.
Un ejemplo que se me ocurre que me dejo claro lo grave de este error es un viejo grabador de CDs que utilice con mi primera grabadora de CDs (a 2x, ¡WOW! :D) que era muy bueno en no ofrecer nada de información: ni te decía si estaba grabando, ni a que velocidad, ni si había dado algún error.
Mensajes de error “malos”.
Aquí creo que podemos poner muchos ejemplos pero destacan algunos errores de compilación que dan/daban algunos programas en GNU/Linux y por encima de todos los BSOD de Windows que no dan nada de información salvo un valor hexadecimal que con suerte te responden en Internet.
- Pedir más de una vez la misma información al usuario.
- No poner valores por defecto.
Lanzar a los usuarios a la aplicación. No hay que asumir que los usuarios van a saber usar tu aplicación, en realidad ni siquiera entender para qué sirve.
Además los usuarios no leen por lo que el recurso del tocho de instrucciones es necesario para los pocos que sí lo hacen pero no debe ser el único. Se hace necesario ofrecer un buen resumen muy conciso y sobretodo corto.
- No indicar para qué se va a usar la información proporcionada. El ejemplo clásico es el del “nick” en un foro, la gente no sabe que este nick va a ser usado para identificarlos a la hora de escribir durante el resto de sus vidas y suelen usar algo inapropiado.
- Características demasiado centradas al sistema. Demasiadas aplicaciones exponen su ropa sucia ofreciendo características que reflejan la forma interna que usa el sistema para tratar la información.
4 Comentarios (feed)
-
bcdeas nos comenta:
la BSOD no solo da un error exadecimal, tambien crea un minidump de lo que estaba pasando en el SO.
-
Pedro Iniesta nos comenta:
Todo lo que acabas de describir le pasa a autocad…
-
Zeioth nos comenta:
Todo lo que acabas de describir le pasa a autocad…
Y a 3D max…
Y a maya…
Autodesk es lo mas xD. -
Armonth nos comenta:
bcdeas cierto, pero cuando no se puede acceder al sistema por culpa de algo que provoca la BSOD a menudo no sirve de nada el minidump (y a veces aunque puedas acceder a él tampoco) por lo que la única solución pasa por pillar otro PC y tirar de Google usando el hexadecimal.
Con lo fácil que sería ofrecer una descripción +/- detallada.