Aplicaciones de escritorio para empresas

El navegador va bien para consultar y para un trámite corto. Es un mal sitio para archivos locales, atajos que la gente ya tiene en la mano y un aparato enchufado por cable. Forzar eso a una web “porque así se actualiza solo” traslada el problema al operador, que acaba con tres ventanas y un pendrive.

La aplicación de escritorio se justifica cuando el puesto es el lugar de trabajo, no un visor. Quien está en el taller no quiere iniciar sesión en un portal para marcar una pieza. Quiere la ventana que ya estaba abierta, con el pedido de ayer todavía ahí si se fue la luz.

También se justifica cuando el dato no puede salir del equipo. No es una preferencia de interfaz. Es una regla de la empresa o del cliente. El diseño parte de esa regla: qué se calcula en local, qué se sincroniza cuando hay red y qué no se sincroniza nunca.

El primer día en el puesto tiene tres pruebas: instalarse sin que sistemas improvise, actualizarse sin borrar el trabajo a medias y abrir el último expediente. Parecen obvias y son las que fallan cuando el escritorio se trata como un prototipo de feria.

El instalador, la firma y el canal de actualización forman parte del encargo, no de un apéndice. Si el parque es solo Windows, no pagamos la complejidad de otro sistema para enseñar un icono en una diapositiva. Si de verdad hay macOS y Windows en los mismos puestos, se decide al principio y se prueba en los dos.

Una versión mala se puede revertir. El turno no debería descubrir el cambio a mitad de un parte. La ventana de actualización se acuerda con quien lleva el puesto, no con el calendario de quien compila.

La conexión con el ERP, el correo o la carpeta de red se dibuja como un borde: qué sale, qué entra, qué pasa si el otro lado no responde. La aplicación no se queda congelada. Dice qué ha guardado en local y qué está pendiente. Un parte “enviado” que no salió es peor que un parte pendiente, porque la oficina cree que el trabajo está hecho.

El antivirus, el usuario sin permisos de administrador y la carpeta de red que se cae a las tres de la tarde forman parte de la prueba. La guía de instalación los nombra. Un PDF de “siguiente, siguiente, finalizar” que no menciona el parque real no es una entrega.

El código, el instalador y la forma de compilar quedan en manos de la empresa. Otro equipo puede seguir dentro de un año sin pedirnos la llave del puesto. La firma del binario se decide con sistemas: quién firma, dónde vive el certificado y cómo se revoca.

El encargado quiere el informe. La persona del puesto quiere no repetir el parte. Esas dos necesidades se escriben por separado. Si solo se diseña el informe, el puesto sigue en el papel y el informe sigue vacío. El primer uso que cuenta es el del turno, no el del cuadro.

Quien instala es sistemas o un proveedor interno. Recibe requisitos, permisos, cómo se revierte una versión y a quién avisar. La aplicación no se “deja en un escritorio” esperando que alguien con prisa la copie en un recurso compartido sin procedimiento.

Si el mismo expediente tiene que consultarse luego en el móvil o en la web, se dice cuál manda. Duplicar la lógica en tres sitios sin esa frase es cómo aparecen dos verdades del mismo parte y nadie sabe cuál cerró el pedido.

No convertimos una hoja compleja en una aplicación solo porque la hoja da miedo. Si la usan tres personas, el dato no sale del equipo y el miedo es de formato y no de operación, lo decimos antes de presupuestar. El escritorio se justifica por el puesto, el aparato o la norma, no por el deseo de “tener un programa”.

Tampoco prometemos que sea más barato que una web porque “es solo para dentro”. El puesto, el instalador y la prueba en máquinas reales cuestan. Lo que ahorra es el tiempo del operador y el riesgo de sacar datos que no debían salir.