Please Stand-By

please_stand_byHoy día es habitual en los aplicativos restringir las posibles acciones de los usuarios cuando el sistema está realizando algún procesamiento. Esto es algo que ha ido evolucionando con el tiempo, pasando de mensajes de texto que titilaban en la pantalla a barras de progresos y animaciones, algunas muy creativas y otras muy molestas.

Con el advenimiento de la tecnología web, surgieron nuevos patrones de comportamiento de los usuarios y nuevos retos para los diseñadores y programadores para evitar que las acciones de éstos afectaran el comportamiento esperado del sistema.

Por ejemplo, uno de los patrones conductuales de los usuarios que eventualmente surgieron, especialmente con los sitios dinámicos y el e-commerce, fue el que se conocería como deja-vù.

Para entender este patrón conductual supongamos el siguiente escenario: un usuario accede a un aplicativo web y pulsa un botón (o un enlace), pero no percibe que el aplicativo esté haciendo algo y nuevamente pulsa el botón. Supongamos que el usuario es tan perceptivo como una oruga y nuevamente cree que el aplicativo no ha recibido su solicitud y se la pasa dándole varias veces al botón hasta que aparece un resultado, el cual muy probablemente sea producto de la primera vez que presionó el botón. En el mejor de los casos hasta allí habrá llegado el problema.

Continuando con el ejercicio, supongamos que el botón se encargaba de insertar alguna información (o más doloroso aún, realiza un debito irreversible a la cuenta bancaria del usuario). Entonces por cada vez que el usuario le dio al botón, el servidor recibió una solicitud de realizar esa acción, que en el mejor caso bien puede ignorar, o puede lanzar un error que el usuario verá a posteriori o simplemente repetirá dicha acción el número de veces que el usuario haya pulsado el botón.

Pero todo esto ocurre porque el aplicativo carecía de un mecanismo para expresar de forma clara y explícita que ha recibido la petición del usuario, más allá de lo que el explorador que esté empleando el usuario haga para indicar que está esperando una respuesta del servidor.

Claro que hoy día los usuarios están más acostumbrados a la latencia de los sistemas web, pero no existen garantías de que el patrón conductual se haya superado al ciento por ciento. Y más si en la actualidad todos los sistemas web están siendo implementados con algún tipo de framework de AJAX que hace que las páginas web no se tengan que cargar completamente para mostrar el resultado de la acción del usuario.

Y para empeorar las cosas, los usuarios ya no quieren el texto de ‘Por favor espere’ titilando en una esquina del monitor, lo que quieren es diseño, animación y color; algo que a veces no tenemos ni el tiempo, ni el dinero o las habilidades para proveer.

Por suerte, existen almas caritativas que recorren el mundo poniendo a su disposición estos tres escasos elementos, para que desarrolladores en general puedan hacer uso de ellos y proveer a los usuarios de sus sistemas de esa barrita que aparece cuando una sombra bloquea toda la pantalla para que no la anden $@#&*!§ por ahí insistiendo en que se haga algo de lo cual el servidor ya está enterado y en vías de procesar.

Y es entonces donde esta entrada les recomienda el siguiente enlace: www.ajaxload.info en el cual se ofrece imágenes tipo gif animados personalizables y de diferentes motivos para agregar como recursos de espera para que los usuarios de nuestros sistemas, hipnotizándolos y entreteniéndolos, no insistan en sus peticiones y simplemente esperen a que el sistema termine de hacer lo que tiene que hacer.

Lo mejor… es totalmente gratis.

Tautología

Iced PC

Desarrollar aplicaciones y andar por sobre el agua son dos cosas muy sencillas; siempre que el agua y los requisitos funcionales esten congelados

Edward V. Berard

Bienvenidos al front-end

The Architect
De la wikipedia extraemos la siguiente definición de front-end:

“El front-end es la parte del software que interactúa con el o los usuarios y el back-end es la parte que procesa la entrada desde el front-end.[…] La idea general es que el front-end sea el responsable de recolectar los datos de entrada del usuario, que pueden ser de muchas y variadas formas, y procesarlas de una manera conforme a la especificación que el back-end pueda usar”.

Se preguntarán, ¿qué tiene que ver una abstracción ampliamente conocida del diseño de software con un blog de arquitectura de soluciones, más allá de lo claramente evidente?

Pues de una simple analogía: que el arquitecto de soluciones de software suele ser el front-end técnico entre lo que el cliente desea y lo que el equipo de trabajo y la tecnología permiten realizar. En otras palabras, se convierte en la interfaz que traduce los deseos del cliente en especificaciones técnicas que su equipo de trabajo puede llevar a cabo con facilidad y efectividad, y retornar el resultado de dicho proceso nuevamente al cliente.

Como todo front-end, ofrece una serie de prestaciones que le hacen atractivo: conocimiento, oratoria, dialéctica, mística profesional, entre muchas que se pudieran citar. La mayoría de las veces simplemente nos quedamos en la función técnica del rol (ya que también es la que suele disfrutarse más) pero no por ello se pierden las otras. Pero lo importante en la arquitectura de software, es que el front-end que presentemos a los clientes y nuestra habilidad de transformar sus requerimientos en diseños que nuestros equipos puedan emplear efectivamente cambie acorde a los tiempos y las necesidades. Por ejemplo: un sistema operativo ofrece la mayoría de las veces más de un tipo de UI, ya sea gráfico, de consola o híbridos. Con cada necesidad,  y muchas veces gustos, se cambia el front-end aunque el back-end siga siendo el mismo.

Todo front-end, sin importar que tan perfecto y ergonómico esté diseñado, encontrará un individuo (o grupos de individuos) que no sabrán encontrar la forma de interactuar con él, por más que el mismo front-end se adapte. Este tipo de gorilas escudan su inaptitud a través de lo que al final llamaríamos política. Muchas veces se perderán proyectos increíbles y satisfactorios por las políticas internas de la corporación que formarán los obstáculos que a veces, contrario a lo que parezca, terminará con el alivio de la cancelación del proyecto. Pero un arquitecto no se decepciona de la política, sino que aprende de ella y de los restos que quedan del proyecto.

Ciertamente el arquitecto no es el único front-end que tiene una organización para con sus clientes, así como el equipo de desarrollo no es el único back-end. Existen otros actores que estoy seguro tienen en sus propios representantes, con sus respectivos blogs, y que serán muy interesantes de leer, pero en lo que a su servidor compete, este tratará de mis aventuras en el mundo de la arquitectura y una que otra cosa que creo les pueda gustar.

Espero les guste esta introducción y los futuros posts.