Uno de los problemas a los que siempre me enfrento a la hora de diseñar una aplicación es la interfaz de usuario. Cada vez creo más cierto que hay que empezar a pensar en la arquitectura de la aplicación a partir de lo que los usuarios de ella quieren/necesitan. Y no soy el único sino mira.
Pero este post no va de eso. En todos los estados previos de definición de la aplicación siempre nos encontramos rodeados de folios sacados de la impresora donde hacemos bocetos de lo que será la aplicación de usuario. Incluso para tener las ideas más claras se opta a realizar una página web en HTML simple sólo para ver cómo se relacionarán los distintos elementos, y si tienes un diseñador gráfico a mano ;-) que te la haga en photoshop/gimp. Pero siempre me he encontrado con el problemita de no encontrar gráficos hechos para hacer algo rápido (¿cómo hacéis si queréis meter un calendario o un reloj, por ejemplo?)
Pues bien, hoy buceando en los entresijos de la web he encontrado una pequeña joyita: denim
Está realizado en java (cómo no! ;-P) y permite realizar bocetos en pantalla de lo que queremos/creemos va a ser la GUI de la aplicación. Como muestra un bocetillo chorra:
La interfaz me resulta hasta divertida (en vez de pantallas distintas lo que tienes es zooms de tu boceto), y viene con algunos componentes ya hechos que sólo tienes que arrastrar a tu boceto.
Me ha gustado la idea y la propia UI de denim me ha dado algunas ideas interesantes. No sé tal vez debería mirarme mi nivel de frikismo ;-)
Genial! Ahora mismo me pongo a probarlo. !Gracias ibon!
Hola,
El sistema que comentan en el articulo es parecido al que usamos nosotros, por el que nos basamos fuertemente en el prototipado HTML para complementar y finalizar los requerimientos y el esquema de datos de las aplicaciones web. De hecho en muchos proyectos me NIEGO a empezar a programar hasta que los requerimientos y el prototipo hayan tenido el visto bueno, y a veces hasta consigo que cuele (es que cuando me pongo a malas… jejeje)
Aunque creo que sigue siendo necesario transcribir a lenguaje tecnico y detallado esos requerimientos, de forma que puedan ser entendidos exactamente y verificado su cumpliemiento. Eso si, como dicen ellos, no hacerlo al principio como algo “fijo” que determine “eso es lo que haremos y punto” si no como parte más técnica de la especificación a través del prototipado.
Como dificultades, decir que los jefes y otros personal de otros departamentos técnicos más tradicionales no acaban de pillarle la idea, y que se adapta bien a proyectos web, pero no a otros (con menor carga de UI) por lo que los defensores de “un sistema para todo” pues se te echan encima. Es dificil de explicar a desarrolladores que estan acostumbrados a que el cliente se coma “lo que le echen” y “ya se leeran el manual de usuario”… pero bueno.
Eso si, yo siempre he tenido buenos resultados con este tipo de aproximación, con usuarios satisfechos y yo con menos trabajo de modificaciones a posteriori.
Un esquema del modelo que seguimos ya lo mostre en el Congreso JavaHispano, y se puede ver aquí:
http://www.greeneyed.org/guide/java/doc/ModeloDesarrollo.png, para los que se durmieron a media charla
Epa ge,
No quería entrar en polémicas sobre el artículo (puede que otro día ;-)) y por eso lo he pasado por encima en el post. Sólo te digo que una de las ideas en las que basamos linking paths es hacer software que se acomode a los clientes, no clientes que se acomoden al software ;-D
A veces creo que los programadores damos por supuestas muchas cosas (el menú tiene que tener esto, esto y lo otro) y adecuamos nuestras interfaces a lo que nosotros entendemos por usabilidad.
Hace años un cliente me abrió los ojos: cuando le enseñé una aplicación web, se río y me dijo: “Todos los ingenieros sois iguales, ponéis la etiqueta más grande que su valor”. Y tenía razón por qué a la hora de hacer pruebas a mí no me importaban tanto los valores como el hecho de que aparecieran, así que mi inconsciente hizo el resto ;-)
Por otro lado la interfaz es lo único que realmente va a ver un cliente, y puede ser la diferencia entre un cliente satisfecho al 100% o sólo al 60%
Salu2 (y a ver si nos incluyes en el rincón de java, que nos lo merecemos ;-))
En mi caso no es que me iluminara así una luz y me viniera la inspiración o que los usuarios nos lo dijeran (tenemos de los usuarios mas pasotas que he visto nunca) si no que ha sido una evolución “forzada” por las circunstancias.
Un equipo pequeño para hacer muchos proyectos pequeños/medianos te obliga a intentar “hacer las cosas bien” cuanto antes mejor, para evitar que te llamen para modificar cosas cuando tu ya has pasado a otro proyecto y estas metido en otra cosa… y como dice el dicho… “a la fuerza ahorcan” :-)
En cuanto al Rincon Java… tiene un bonito enlace llamado “Añadir referencias” donde os podeis añadir… lo de sitios amigos tendre que pensarlo, jejejeje.