18.06.2004 :: Jaime Irurzun
Leyendo los primeros capítulos del User Interface Design for Programmers de Joel Spolsky traducidos al castellano me quedó muy clara una de las ideas más importantes que trata: hay que evitar frustrar al usuario. Sí, con esas pequeñas cosas que van irritándole a uno a lo largo del día. Algunas son inevitables, o al menos no son culpa del programador, como esa insoportable sensación de que la puta rueda del ratón no avanza, y tú lo arrastras una y otra vez sobre la alfombrilla, desesperado, y sin éxito. Ya puedes tirar de él y ya puedes limpiarle la cosa negra que se le pega por debajo de tanto usarlo, que al próximo intento volverá a quedarse atrancado; lo dice Murphy. Pero al menos, otras sí se pueden evitar, ya que están en manos del responsable del programa que el usuario está utilizando.
Uno de los elementos que más enfada son los mensajes de aviso, en todas sus variantes: con icono de interrogación, de alerta, de stop... todos igual. Acaba desesperando querer hacer algo y que los programas te saquen preguntas, advertencias o errores de cualquier tipo. Así que, mejor evitarlos en los casos en que sea posible. Trabajando con el Cuaderno de Bitácora ayer tuve la oportunidad de poner en práctica esto. Resulta que en la ficha de cada libro hay una pestaña que recoje datos sobre el préstamo de ese libro, y junto al nombre del prestatario y la fecha de préstamo, hay un botón que permite devolver el préstamo con solo pulsarlo. Me dí cuenta de que había un pequeño fallo, y es que cuando el libro no estaba prestado -prestatario y fecha vacíos-, el botón seguía permitiendo devolver el libro, realizando las acciones que tiene que llevar a cabo: vaciar esos dos datos, para que al guardar la ficha del libro se anote la devolución del préstamo. Lo primero que se me ocurrió fue sacar el mensaje de turno: "No se pueden devolver libros que no estén prestados". Pero después, pensándolo, me dí cuenta de que era un mensaje totalmente prescindible y que tenía que evitar.
¿Qué mejor solución que deshabilitar el botón de devolución cuando el libro no esté prestado? Sí, una tontería, pero que desgraciadamente no fue lo primero que se me ocurrió hacer... y eso que parece evidente.
comentarios (8) |
Jaime,
Muy buena observación. :-)
Siempre, cuando se diseña un interfaz de usuario, hay que tener varias cosas en cuenta y, a veces, la costumbre de programar de una forma nos lleva a no tener en cuenta otras soluciones.
La mejor postura, cuando se diseña una interfaz de usuario, es la de ponerse en su lugar y pensar como él. Nuestro error como programadores está en pensar que todo el mundo ve las cosas igual que nosotros.
Saludos.
Continuando con lo apuntado por Jose Alfonso, no hay nada como comer la propia comida para saber si está buena o no.
Lo mejor que puedes hacer para depurar un programa desde el punto de vista de usabilidad es .... utilizarlo diariamente en tus menesteres, y no limitarte a verificar que no da errores.
Otra cosa en la que me suelo fijar mucho es en la longitud de los mensajes, etiquetas, en definitiva, de los textos que ve el usuario, cuantas menos palabras mejor.
Tienes razon tú o Joe no se, sobre los mesnajes con un Stop, tipico "Cliente no encontrado", yo los odio en mis programas los tengo, a veces me he planteado quitarlos.
Posible solucion una barra de mensajes en el pie del dialogo, otra usar los bocadillos como hace Windiws XP, que te dejen trabajar y se oculte a los xSegundos.
Saludos.
Muchas veces los programadores olvidamos nuestra faceta de usuarios.
Hay que tenerla siempre presente, para así facilitar lo máximo posible la labor diaría a los usuarios reales de nuestras aplicaciones.
Es curioso, pero los usuarios no experimentados prefieren los mensajitos de error, porque de otra forma no se enteran. Lo digo por experiencia.
Salu2
Cek
Eso también es verdad, Cek, lo había pensado: puede que un usuario no entienda por qué no puede "hacer click" en ese botón... pero en este caso concreto, dudo que quiera pulsarlo viendo que el libro no está prestado :)
Hombre, además a esta técnica se le pude llamar "programación defensiva" ya que pretende evitar que el usuario cometa errores... si evitamos que el usuario cometa el error de devolver un libro no prestado ya no tenemos que preocuparnos por ese supuesto en el algoritmo "devolver libro" ;-) lo que simplifica las cosas y siempre que las cosas son más simples es más dificil cometer errores.
Exacto Fernando, le has dado en el clavo. Después de aplicar esto me he dado cuenta de que se simplificaba el código... precisamente, en el algoritmo "devolver libro" :)