¿De verdad está usted seguro de irse?

Una de las costumbres que solemos tener los que escribimos aplicaciones informáticas es darle al usuario una "última oportunidad" para si decide arrepentirse de algo antes de cerrar la aplicación. Es lo que en el argot se denomina "diálogo de salida" y que incluso hasta algunas RADs (como Delphi) implementan entre sus eventos (el de cierre).

Este diálogo era bastante habitual (y útil) en aquellos programas escritos para DOS (o para ordenadores con un entorno no gráfico, en general), principalmente procesadores de textos. En ellos era costumbre el manejo mediante atajos de teclado ya que el ratón era más lento (y tedioso) de usar. Era común que el usuario, a veces por costumbre, otras por inercia y/o sin querer, enviase el atajo de teclado de salir antes de que se guardasen las modificaciones introducidas en el documento.




En cuanto se empezó a introducir y enriquecer el entorno gráfico, con elementos visuales que nos advertían del cambio de estado de la aplicación, el cometer ese error ya era menos habitual. Curiosamente a mí es algo que me ocurre a veces en herramientas gráficas, pero no cuando trabajo con texto (lo de salir sin guardar, me refiero).

Una solución media para evitar ese problema es el guardado automático. Muchos procesadores lo tienen (desde luego los más famosos lo incorporan), y yo también lo añadí en algunos de mis programas.

Claro, el guardado automático es muy útil, cuando lo pones cada medio o cada minuto, cuando escribes mucho y lo tienes activo cada cinco minutos la cosa cambia, porque en cinco minutos podemos escribir mucho texto. Hay gente que lo pone activado cada quince minutos, lo cual me parece una tontería, es como jugar a la ruleta rusa o a los dados: puede ser que haya un corte de energía o un "accidente" en el minuto 16, y entonces tengas suerte porque casi todo tu trabajo que hiciste se habrá salvado, pero puede que éso ocurra en el minuto 8, 10 o 12, y en doce minutos podemos haber escrito mucho y realizado muchos cambios, con lo cual sería un drama tremendo.

El otro inconveniente de este sistema de "autoguardado" es el lapsus que lleva realizarlo. En pequeños o medianos documentos en txt apenas se nota, y podemos seguir trabajando tranquilamente en el editor de textos, pero en procesadores complejos con mucha carga, como Word u Openoffice, el autoguardado puede ser una molestia, al quedarse el documento "congelado" unas centésimas de segundo cada minuto (o cada equis tiempo, dependiendo el intervalo que le hayamos puesto).

Otra alternativa que surgió entonces a este inconveniente son los archivos automáticos de backup o respaldo. Son útiles en algunos casos concretos, pero no son la panacea: a veces el documento que el programa recupera por sí mismo tras un "crash" es más reciente que el guardado en disco en backup porque, conviene recordar, ese backup no es constante, y se realiza también cada cierto tiempo que, si hemos hecho muchas modificaciones sin guardar, puede quedarse corto.

No es ninguna de ellas soluciones ideales, pero al menos nos pueden servir en determinados momentos.


Una tercera solución es tener un respaldo en línea de contexto, es decir, según determinadas acciones. Por mi experiencia ese sistema es muy valioso, y de hecho lo tengo implementado en el editor de posts que uso para mis blogs. Se trata de que tras una acción de limpieza o borrado del editor principal, éste no se elimine totalmente, sino que esos datos se acumulan en un segundo editor. Para evitar sobrecarga, ese segundo editor se renueva con cada una o dos limpiezas del principal. Gracias a este sistema he podido evitarme algunos sustos y recuperar información que, debido a que la había retirado del editor principal, ni el backup ni el autoguardado la habrían salvado.

Lo que veo innecesario y totalmente banal es incluir cuadros de confirmación de cierre en otro tipo de programas, como los visualizadores de imágenes o, peor aún, los navegadores de internet. Para mí no tiene ningún sentido ponerle a un navegador la pregunta de si realmente el usuario quiere salir. ¿Cuantas veces os habrá ocurrido que, al salir, hemos elegido la opción de "no" diciéndonos "bueno, voy a ver esta otra cosa"? Me parece una estrategia para aumentar nuestra adicción a la red. Creo que, aunque esa opción de confirmación de salida para ciertos momentos puede sernos de ayuda, sería también más útil un botón u opción que nos permitiera salir "ipso facto" del programa. No solo que no pidiera confirmación, sino que ni tan siquiera nos dijera nada si tenemos cosas sin guardar.

Hace tiempo que le añadí al editor de posts que os hablaba antes un botón de este tipo, que sale y cierra el programa al instante, y tengo que confesar que lo uso muchísimo. A veces empiezo a escribir un post, o copio o pego algo de información en el editor y, luego, tras haberla usado o decidir que ya no voy a seguir con ese post, cierro el programa.

Antes tenía que pasar por el proceso: "¿quiere usted de verdad salir sin guardar..., etc., etc...?". Ahora con esa opción puedo salir sin perder tiempo, lo que aporta no solo comodidad, sino que reduce el estrés al que te someten algunas aplicaciones.

Como todo, los "query" de cierre son muy útiles, pero mal usados o implementados pueden acabar convertidos en un agobio y creo que en algunas aplicaciones son absolutamente innecesarios, como en los navegadores que os comentaba antes. Un botón de salida inmediata y sin preguntar me parece una buena opción porque nos da la oportunidad de cerrar al instante, sin tonterías, pérdidas de tiempo ni cortapisas.

Sí, es cierto que -en algunos programas- tenemos la opción de desactivarle el diálogo de salida, pero a veces sí nos viene bien tenerlo. Claro que si nos habituamos a usar siempre el botón de salida rápida, podemos acabar metiendo la pata y un día perder datos o salir sin querer, ¿no deberíamos dejarle al usuario el derecho o, al menos, la posibilidad de que pueda correr ese riesgo? Los desarrolladores de aplicaciones a veces nos empeñamos demasiado en que el usuario vaya obligatoriamente por donde queremos en el manejo del programa, buena parte de culpa la tienen los "sesudos" departamento de diseño de aplicaciones, que nos obligan y nos mantienen en unas directrices estrictas que hay que seguir, pero el error forma parte de lo cotidiano.

De hecho, y aunque en la informática se tienda a eso, a evitar el error, ser tan perfeccionista no solo no es bueno a veces, sino que en ciertas ocasiones llega a ser molesto e incluso llega a ser contraproducente. Así se crean programas muy rutinarios y apáticos que, de acuerdo, no es nuestro cometido al crear, por ejemplo, un editor de texto, entretener a nadie, pero sí darle varias posibilidades que aporten algo "de chispa". Hoy si metes un botón de "salida rápida" y sin detenerse, en una aplicación, (incluso en apps de móviles) la gente se echa las manos a la cabeza, y puede que hasta te lleves una bronca del cliente o de quien te haya encargado esa app, por eso ese tipo de cosas rara vez se ven, a excepción de en aplicaciones personales o echas para uno mismo, como es mi caso con el editor de posts.


Y no solamente podemos nombrar la salida inmediata como un ejemplo, también un botón de cierre mas cómodo y visible (que también lo uso mucho en algunos programas que hago, y que sin embargo casi nunca veo en aplicaciones "comerciales") o la posibilidad de ofertar una versión de la aplicación sin iconos y "boberías" visuales como pieles o animaciones, que quedan bonitas pero útiles son muy poco, y sobrecargan a lo tonto el sistema.

Quizá estemos viviendo un paradigma en el mundo de la programación en donde, mientras que antiguamente se mostraba tanta atención a la eficiencia, hoy se ha dado un cambio radical y es completamente al revés, y a costa de elementos accesorios, frameworks y demás artificios, para hacer lo que se hacía antes una aplicación requiere ahora una demanda de memoria y recursos bestial. Por supuesto, no hay que irse a los extremos y programar todo en ensamblador, pero tampoco es bueno que ahora todo se haga para que sea bonito, y la practicidad quede en un último lugar e, incluso, ni siquiera se la tenga en cuenta.

| Redacción: Bianamaran.blogspot.com