En
varios sitios web se ha reabierto el debate sobre si es más adecuada la construcción de interfaces de usuario a través de herramientas de generación de código, o si por el contrario es mejor elegir una aproximación más artesana y construir todo el código manualmente.
La verdad es que este es un tema recurrente sobre el que creo que cualquiera pude opinar, ya que asumo que todos los que estamos en este mundillo del software hemos desarrollado algún interfaz de usuario en algún momento de nuestras carreras, ya sea hace años cuando los Visual Basic era una revolución a la hora de crear aplicaciones, ya sea más recientemente en Java con herramientas como
Matisse, o ya sea en el mundo web con los diseñadores visuales para frameworks Java Server Faces. Asimismo, probablemente todos hemos en algún momento determinado creado, o intentado crear, esas mismas interfaces de un modo manual, ya sea porque nos apetecía, porque no teníamos otra cosa a mano, o por cualquier otra razón.
Ante una situación como esta, donde cada cual tiene su propia opinión en base a su experiencia, creo que es un poco inútil el caer en discusiones sobre ésta u ésta otra tecnología es mejor, así que intentaré describir lo que en mi opinión son los tres factores más importantes a tener en cuenta, en orden de importancia, a la hora de elegir uno y otro camino:
- Experiencia de la gente que disponemos: Lo más importante que se debe tener en cuenta es el tipo de gente con la que contamos en el equipo de UI. Y ante este punto lo más importante es ser realistas y recordar que no debemos elegir en base a nuestras preferencias si no en base a su experiencia y habilidad.
Si en el equipo de UI cuento sólo con personas con poca experiencia, que no han hecho interfaces visuales previamente, o que vienen de otros lenguajes y no conocen Java, o .NET, o lo que sea, entonces en este caso no tendría demasiado sentido forzarles a programar todo manualmente, ya que les resultará muy complicado. Incluso aunque a nosotros nos parezca una tarea muy fácil, la realidad es diferente: para ellos no lo es.
Por otra parte, obligar a un grupo de expertos programadores a utilizar un diseñador gráfico puede ser contraproducente, ya que estas personas pueden no sentirse cómodas con estas herramientas, pueden tener ya una serie de procesos que los hagan más productivos y el añadir una herramienta nueva puede significar reemplazar todos esos procesos por algo totalmente nuevo, y finalmente esto puede llegar a causar frustración y desánimo en el equipo.
- Complejidad del interfaz de usuario: El siguiente punto a tratar sería la complejidad del interfaz que estamos planeando. Los diseñadores visuales suelen soportar un conjunto limitado de componentes, y en cuanto añades componentes que no esperan el resultado puede ser diferente al que no esperamos. Si nuestro interfaz va a utilizar componentes personalizados, entonces debemos plantearnos seriamente la posibilidad de utilizar una aproximación híbrida o simplemente olvidarnos de utilizar ninguna herramienta.
Mediante una aproximación híbrida, diseñariamos la mayor parte de componentes con herramientas visuales y posteriormente añadiriamos los componentes propios. El punto crítico aquí es que el proceso de añadir componentes propios debe ser lo menos intrusivo que sea posible, ya que de otro modo las probabilidades de que la herramienta gráfica sea incapaz de volver a recear nuestro interfaz son muy altas.
Si el número de componentes personalizados es alto; o si estos componentes personalizados se encuentran muy arriba en la jerarquía de componentes ( no es lo mismo personalizar un frame que un botón ), entonces lo mejor sera olvidar directamente las herramientas visuales.
- Valorar entre diseñadores visuales y frameworks: Hoy por hoy los diseñadores visuales son muy potentes. Por ejemplo, en Java, hay diseñadores excelentes tanto para Swing como para SWT. Por otra parte, tenemos que de manera alternativa siempre aparecen una serie de frameworks que ofrecen un enorme valor añadido, como pueda ser JGoodies en Java (o incluso los componentes de futuros jdk que van apareciendo en java.net). La mala noticia es que los diseñadores visuales no suelen soportar estos componentes, lo que significa que si realmente necesitamos alguno de estos componentes, entonces tendremos que abandonar la idea de utilizar el diseñador.
Si por el contrario, no hay ningún framework que nos ofrezca algo realmente valioso, entonces la opción de usar diseñadores vuelve a adquirir valor.
En esta lista los dos primeros puntos son excluyentes y decisivos. Si no tenemos gente experta, lo mejor es ir a las herramientas, mientras que si nuestro interfaz va a ser muy complejo y personalizado, lo mejor es ir al código manual. En caso de empate en esos dos puntos, el tercero debe decidir.
Me dejo muchos aspectos deliberadamente, porque la verdad es que este sería todo un tema para un libro. Otro aspecto importante podría ser la volativilidad del equipo. Por ejemplo, si hoy tengo un equipo muy bueno, y la gente se me va, mañana quizás un equipo menos experimentado tendrá que mantener el código del primer equipo, y en ese caso el trabajar con un diseñador visual facilita las cosas porque para los segundos les será sencillo ver lo que han hecho los primeros. Pero, por ejemplo, por el contrario, forzar a los programadores a no utilizar un diseñador, es equivalente a forzarlos a aprender como funciona una determinada API, lo que siempre es bueno porque aporta conocimiento sobre la plataforma.
En fin, sea como sea, ante todo lo más importante es ser consistente con la decisión tomada. Si elegimos utilizar una herramienta, debemos utilizarla y cuidarnos de que los interfaces se puedan seguir manteniendo con esa herramienta. Si comenzamos a crear pantallas, y posteriormente añadimos mucho código personalizado a estas pantallas, seguramente no las podramos volver a editar gráficamente. La consecuencia es que parte de nuestro interfaz gráfico se modificará con un editor y la otra parte se modificará manualmente, lo que no deja de ser un desastre.
Y para acabar me mojo. Yo prefiero no utilizar herramienta. Siempre que comienzo algún proyecto, intento empezar con alguna, pero al final acabo escribiendo todo a mano. Que se le va a hacer :)
