WYSITA - What You See Is The Application

Hay dos tipos de personas, los que creen que se puede clasificar a las personas en dos tipos y los que creen que no. Yo soy del tipo de los que creen que no. Pero a veces es útil para determinados argumentos, dividir imaginariamente a la gente en dos grupos.

Para el argumento que nos ocupa, consideremos el grupo de las personas que desarrollan software y el grupo de las que no. Me interesa esta diferenciación porque lo que quiero explicar viene precisamente de la comunicación entre estos dos grupos. En esta comunicación hay algo que ocurre con relativa frecuencia y es que una persona que no desarrolla expresa poca apreciación por determinado software, lo ve como algo sencillo o poco elaborado, por ejemplo, y la persona que sí desarrolla siente la necesidad de justificarse.

En esos casos, seguramente la justificación más habitual es que el no-desarrollador no ve todo lo que hay por detrás, no es consciente de la enorme complejidad y el esfuerzo necesario, bla, bla y bla. Y es cierto, todo ese esfuerzo y complejidad existe y el usuario no es consciente de ello.

A partir de aquí lo que ocurre, y de ello viene el problema, es que el programador se justifica con todo ese esfuerzo y complejidad oculto. Lo que debería hacer es comprender que para el usuario todo eso simplemente no existe, y no lo va a ver por mucho que justifiquemos y expliquemos.

Es duro admitir esto. Es duro porque significa admitir que todo ese trabajo que hay detrás, un trabajo que existe y que es complejo y ha requerido un esfuerzo por nuestra parte, nunca va a ser apreciado. Pero es importante asumirlo pronto y de forma profunda si queremos en algún momento llegar a producir software que el usuario aprecie y use.

Es duro también porque en muchos entornos empresariales hay cierta tendencia a relegar todo lo que tiene que ver con Frontend a una consideración inferior. O a ascender el desarrollo de Backend a una posición superior. Y lo que ocurre es que, en realidad, estas personas en esa situación elevada al usuario no le importan nada.

Lo que ves es lo que hay

Podríamos decir que esta es la máxima por la que se rige la percepción de las personas que no programan. Esas estructuras de datos, esas jerarquías de objetos, los diseños de arquitectura, el código limpio del que te sientes orgulloso, todo eso es invisible para el usuario.

Para el usuario la aplicación es sólo lo que sale en su pantalla. Los formularios, botones, gráficos. No le importa nada más. Si lo que se ve le gusta, si se maneja bien y cómodamente, si es agradable a la vista y es fácil de entender, entonces la aplicación es buena. Si tu interfaz es feo, incómodo, confuso y complejo, le dará igual que estés usando correctamente una estructura en capas. Es irrelevante para él que hayas aplicado las soluciones óptimas a cada problema de arquitectura. No le importa que tengas un sistema de plugins que te permite añadir nueva funcionalidad en menos tiempo. De hecho, ¿para qué, para sacar más pantallas feas?

No despidas aún a tus desarrolladores de backend, pero...

Lógicamente todo esto no quiere decir que esas cosas no importen. Lo que quiere decir es que no le importan al usuario. Es más, de algunas de ellas puede llegar a admitir que existen. Normalmente, eso sí, esto ocurre cuando algo va mal. Por ejemplo, si el software tarda o es lento, el usuario entonces reconoce que debe haber algo más de lo que se ve a simple vista. "Le doy y parece que se queda un rato pensando hasta que responde" - dice. O "es como si estuviera haciendo algo...".

De modo que -espero que nadie lo dudara ;)- aún es necesario desarrollar el backend. Aunque sea para que parezca que la aplicación hace algo. Lo que debemos tener claro es qué importancia tiene cada cosa. No se trata de dejar de aplicar buenas prácticas, sino de no seguir descuidando el interfaz como algo en lo que ya pensaremos después.

El arquitecto de frontend

La arquitectura de frontend es algo distinta a la de backend. Sigue siendo necesario analizar la estructuración del código, siguen utilizándose buenas prácticas y sigue siendo necesario definir una guía de estilo de código. Pero existen otros asuntos que también es necesario cubrir. Es necesario realizar una estructuración de la información, pero no orientándola a su almacenamiento y procesado sino a su presentación y consumo. Hay que tener en cuenta conceptos como la usabilidad, la adaptación del interfaz al público objetivo, el diseño gráfico, el tono del lenguaje, el color...

Y es precisamente a estos temas a los que me voy a dedicar en adelante. En la medida de lo posible en mi trabajo, pero más explícitamente aquí, en TinselCity, la Ciudad de Oropel, donde no sólo hay que mirar más allá de lo que se ve, sino que también hay que mirar lo que se ve. La mayor parte estará centrada en aplicaciones web, pero en algún caso se tratarán también temas en otros entornos y, de todos modos, muchas de las ideas serán aplicables en cualquier caso.

Otros temas

Eso sí, esta es una página personal y eso significa que, de vez en cuando, también surgirán otros temas que me interesen. Así que también habrá temas que sean plenamente de programación y otros que traten sobre robots o electrónica o sobre fotografía o libros o lo que me apetezca.