¿Cuándo una pantalla táctil necesita un sistema Windows?

Pregunte por qué una pantalla táctil determinada terminó ejecutando Windows en lugar de Android, y un sorprendente número de personas en realidad no pueden responder con una razón: es "lo que siempre ordenamos", o "lo que usa el departamento de TI", o una línea de pedido que se copió de la hoja de especificaciones de un proyecto anterior sin que nadie volviera a verificar si todavía se aplicaba. Por lo general, eso indica que la decisión se tomó por hábito y no por lo que el software realmente necesita para ejecutarse, y es un patrón que se muestra en industrias muy diferentes (comercio minorista, atención médica, banca, educación) porque el sistema operativo tiende a ser elegido antes de que alguien haya resuelto qué debe ejecutarse en la pantalla. Para cuando aparece la brecha, el hardware a menudo ya se ha pedido, y recuperarlo cuesta un tiempo que nadie presupuestaba.

El modo de falla no es dramático cuando aparece. Nadie se da cuenta en la etapa de propuesta. Por lo general, surge a las pocas semanas de iniciado un proyecto, cuando alguien menciona (casi como comentario aparte) que la pantalla también necesita comunicarse con alguna pieza de software existente: un sistema de registros, una herramienta de programación, un cliente de base de datos interna que ha estado manejando silenciosamente el negocio durante una década y nunca fue parte de la conversación original porque, desde el lado del cliente, una pantalla es una pantalla y el software es el problema de otra persona.

Esa es realmente la pregunta debajo de "¿esto necesita Windows?"; no qué sistema operativo es generalmente mejor, sino qué software específico debe ejecutarse en la caja y si ese software le da alguna opción.

La pregunta no es "cuál es mejor", sino "qué tiene que funcionar con él"

Con bastante frecuencia, nos piden que recomendemos uno u otro como predeterminado. Los clientes quieren una respuesta simple y entendemos por qué: nadie quiere un desvío de dos semanas hacia la arquitectura del sistema operativo antes de poder pedir una pantalla. Pero tratar esto como una pregunta de preferencia general omite la parte que realmente importa, y es la parte que determina casi todo lo demás sobre el proyecto: precio, tiempo de entrega, carga de mantenimiento y si algo funciona desde el primer día.

Android y Windows no compiten en el mismo eje aquí. Android en hardware táctil comercial está diseñado para ejecutar bien un conjunto bastante limitado de cosas: una aplicación nativa o basada en navegador, un reproductor multimedia, una única interfaz bloqueada que no necesita mucho más que una entrada táctil y una conexión de red. Windows lleva detrás el peso de tres décadas de software empresarial (sistemas de contabilidad, clientes de registros médicos, software de control industrial, plataformas de punto de venta, visores CAD, terminales bancarias), la mayor parte del cual nunca se escribió con un sistema operativo de estilo móvil en mente y no se reescribirá en el corto plazo, y en muchos casos, no se reescribirá nunca, porque el proveedor que lo construyó dejó de desarrollarlo activamente hace una década y el negocio del cliente todavía funciona con él de todos modos.

Entonces, la verdadera primera pregunta en cualquier proyecto no es "Android o Windows". Es: ¿es necesario ejecutar algo específico y no negociable en esta pantalla, y ese software solo existe para una de las dos plataformas? Todo lo demás es una consideración secundaria, y tratarla como la principal es la forma en que los proyectos terminan necesitando un cambio de hardware en la última etapa.

Donde Windows realmente se gana el sustento

Software heredado o especializado

Este es el más importante y el que tiende a quedar fuera del encargo original hasta que el proyecto ya está en marcha. Gran parte del software empresarial se creó para Windows y permaneció allí. Sistemas de información hospitalaria, clientes ERP, ciertas plataformas POS, software industrial SCADA y HMI, terminales bancarias y de seguros: gran parte de este software tiene quince o veinte años, todavía recibe parches, aún administra el negocio y no tiene un equivalente basado en navegador o Android que haga el mismo trabajo. Si el propósito real de una pantalla táctil es ser una interfaz para uno de estos sistemas, Windows generalmente no es una preferencia. Es la única opción que existe.

La pantalla de asistencia al cajero de una sucursal bancaria es un claro ejemplo de esto: podría necesitar ejecutar el propio cliente bancario central interno del banco, el mismo software que usan los cajeros en el mostrador, pero que se presenta a través de una interfaz táctil para que los clientes revisen sus saldos o soliciten un estado de cuenta impreso. En ese caso, rara vez hay que tomar una decisión real. El software tiene una casa y no es Android. La misma lógica se aplica en una fábrica, donde un panel de operador a menudo necesita ejecutar software SCADA existente que ha sido creado y validado durante años en un entorno Windows específico; reescribirlo o reemplazarlo casi nunca está sobre la mesa simplemente porque se está actualizando un panel táctil.

El patrón que vale la pena observar: si un cliente dice algo como "solo necesita conectarse a nuestro sistema", esa oración necesita una pregunta de seguimiento de inmediato: qué sistema y en qué se ejecuta. Ese único seguimiento ha salvado más proyectos de una rehacer en la última etapa que casi cualquier otra cosa en esta lista, y preguntar cuesta unos treinta segundos.

Flujos de trabajo de múltiples ventanas o múltiples aplicaciones

Algunas interfaces realmente necesitan más de una aplicación abierta e interactuando al mismo tiempo: un mostrador de recepción que ejecuta una aplicación de programación junto con una utilidad de escáner de documentos, un mostrador minorista que ejecuta un software POS junto a una herramienta de búsqueda de inventario, un panel de sala de control que muestra un tablero en vivo junto con una utilidad de diagnóstico. Toda la filosofía de diseño de Android se basa en una aplicación que llena la pantalla a la vez. Puedes solucionar esto con trucos de pantalla dividida en algunos dispositivos, pero es luchar contra la plataforma en lugar de trabajar con ella, y la solución tiende a mostrar sus costuras la primera vez que un miembro del personal necesita cambiar entre las dos rápidamente bajo presión. Windows fue creado exactamente para este tipo de flujo de trabajo en capas y de múltiples aplicaciones, y muestra el momento en que un proyecto necesita más de una única interfaz bloqueada: copiar datos entre dos ventanas abiertas, ejecutar un proceso en segundo plano mientras una aplicación orientada al personal permanece en primer plano, ese tipo de cosas simplemente funciona de la manera que la gente espera.

Integración profunda de hardware y periféricos

En el momento en que una pantalla táctil necesita comunicarse con periféricos especializados (escáneres de códigos de barras con SDK específicos, impresoras de recibos, lectores de tarjetas vinculados a un procesador de pagos en particular, módulos de E/S industriales, PLC en una fábrica), el controlador y el ecosistema de integración son tan importantes como el propio sistema operativo. Windows tiene décadas de soporte de controladores detrás y un conjunto mucho mayor de documentación de integración existente y herramientas de terceros, lo cual importa mucho más de lo que parece en el papel una vez que eres tú quien intenta lograr que un escáner de código de barras de quince años de antigüedad se comunique con un panel táctil nuevo en una fecha límite ajustada. La compatibilidad con periféricos de Android ha mejorado mucho y, para el hardware común de consumo, como impresoras o escáneres USB estándar, suele estar bien ahora. Sin embargo, para integraciones genuinamente de nivel industrial (del tipo que tiene un SDK propietario, un paquete de controladores que rara vez se actualiza o un proveedor que solo prueba con Windows) la mayoría de las veces sigue siendo el camino de menor resistencia, y luchar contra eso en una fecha límite rara vez vale la pena ahorrar.

Donde Android gana silenciosamente

Nada de esto hace que Windows sea la "mejor" opción en general, y vale la pena ser directo al respecto, porque muchos proyectos que solicitan Windows por costumbre, honestamente, serían mejor atendidos por Android.

Android arranca más rápido, se recupera de un corte de energía con mayor facilidad y es considerablemente más fácil de bloquear en un modo quiosco genuino de propósito único sin software de terceros superpuesto. Es menos objetivo para el tipo de malware que circula específicamente para Windows, simplemente porque hay menos escrito para esta clase de dispositivo. La concesión de licencias suele ser más sencilla y económica. El consumo de energía tiende a ser menor, lo que importa más de lo que la gente espera en pantallas que funcionan continuamente durante años, a veces en lugares donde nadie presta mucha atención a la factura de electricidad de una pantalla, pero el número se suma en toda una cadena minorista. Y para el contenido que tiene que ver fundamentalmente con la navegación, la búsqueda y la visualización de medios (directorios, catálogos de productos, orientación, la mayoría de los carteles minoristas y hoteleros), no se utiliza ninguna de las capacidades adicionales de Windows. Simplemente permanece ahí como una complejidad no utilizada que alguien todavía tiene que parchear y mantener, mes tras mes, sin ningún beneficio funcional.

Hemos visto clientes solicitar a Windows un quiosco de directorio simplemente porque "Windows se siente más profesional" o porque eso es lo que ejecutan sus computadoras de oficina, sin ningún requisito de software real detrás de ello. Generalmente, ese es el momento en el que vale la pena detenerse, porque tiende a significar un mayor costo de hardware, una mayor carga de mantenimiento de TI y un dispositivo más lento y más propenso a actualizaciones para un trabajo que nunca necesitó nada de eso en primer lugar. La respuesta honesta a "qué software necesita ejecutarse" es muy a menudo simplemente "ninguno, solo muestra el catálogo de productos", y obtener esa respuesta en voz alta, antes de que se entregue el pedido, suele ser lo que le ahorra al cliente un costo de licencia recurrente durante la vida útil de la implementación.

Una lista rápida de control visceral

Antes de elegir un sistema operativo, vale la pena repasar una breve lista de respuestas reales, no suposiciones:

· ¿ Se debe ejecutar una pieza específica de software empresarial o heredado existente en este dispositivo y no tiene Android o un equivalente basado en navegador?

· ¿ La interfaz necesita más de una aplicación abierta e interactuando al mismo tiempo?

· ¿ Necesita conectarse a periféricos especializados (terminales de pago, E/S industriales, hardware específico de escáner o impresora) que solo tienen controladores de Windows maduros?

· ¿ El equipo de TI del cliente ya administra un entorno Windows, con parches y procesos de soporte existentes, o Windows introduciría una categoría de mantenimiento completamente nueva para ellos?

· ¿ La tarea real en pantalla es fundamentalmente navegar, buscar o mostrar contenido, sin ninguna dependencia profunda del software?

Si las respuestas honestas se inclinan hacia las tres primeras, Windows probablemente sea la decisión correcta, independientemente del costo. Si se inclinan por el último, Android normalmente hace el trabajo por menos dinero y menos mantenimiento a largo plazo, y "se siente más profesional" no pertenece en absoluto a esta lista.

La compensación que nadie menciona de antemano

Las comparaciones de costos entre los dos tienden a centrarse en el precio de etiqueta de la licencia, que es solo una parte del panorama. La mayor diferencia aparece en la vida útil de la pantalla, en los parches, la exposición a la seguridad y la cantidad de tiempo del personal que consume.

Ninguna de estas filas pretende declarar un ganador general. Están destinados a hacer visible la compensación real antes de que se tome una decisión basada en el hábito o la intuición en lugar de lo que necesita el proyecto.

¿Qué sucede cuando los clientes eligen el equivocado?

Hemos visto que esto va mal en ambas direcciones y vale la pena describirlo honestamente porque ambos errores son comunes y ninguna de las partes es más culpable que la otra.

La versión Android-cuando-necesitas-Windows generalmente se parece al patrón descrito al comienzo de este artículo: un proyecto centrado en el contenido y la navegación, con un requisito de software que solo surge una vez que la adquisición ya está en marcha. La solución en ese momento es un cambio de hardware, lo que cuesta tiempo y a veces dinero dependiendo de qué tan avanzado esté el pedido, o intentar calzar una aplicación exclusiva de Windows en un entorno Android a través de algún tipo de solución alternativa de escritorio remoto, que técnicamente funciona pero agrega latencia, complejidad y una dependencia de las condiciones de la red que una instalación nativa nunca habría tenido. Esa solución alternativa de escritorio remoto aparece como una solución provisional con bastante frecuencia en esta situación, y en realidad nunca es la respuesta que nadie quería: es lo que sucede cuando no es posible rehacer adecuadamente en la línea de tiempo actual y algo tiene que enviarse de todos modos.

La versión de Windows cuando no lo necesitas es más silenciosa pero igual de común, y no produce una falla dramática como lo hace la falta de coincidencia de Android, lo cual es parte de por qué pasa desapercibido durante tanto tiempo. Un cliente solicita a Windows un directorio o una pantalla de señalización porque es a lo que está acostumbrado, y un año después se enfrenta a ciclos de actualización inesperados que interrumpen la pantalla al mediodía, conflictos ocasionales de controladores después de una actualización de Windows y un equipo de TI que ahora tiene un punto final de Windows más para parchear y monitorear un dispositivo que se supone que solo debe mostrar un mapa. No sucede nada catastrófico. Es simplemente una sobrecarga continua que un sistema operativo más simple nunca habría creado en primer lugar, acumulándose silenciosamente en la carga de trabajo de mantenimiento mensual de alguien para una pantalla a la que, para empezar, nunca se le pidió que hiciera nada específico de Windows.

Hacer coincidir el sistema operativo con el proyecto, no con el hábito

La forma confiable de resolver esto es hacer la pregunta sobre el software de manera temprana y específica, no de manera general. "¿Necesita conectarse a algo?" es demasiado vago: la gente dice que no porque están pensando en las cosas obvias y olvidando la herramienta interna en la que su recepción inicia sesión todas las mañanas sin pensarlo dos veces, la que ha estado allí durante tanto tiempo que ya nadie la menciona porque es solo parte de cómo funciona la oficina. Las mejores preguntas suenan más como: con qué aplicaciones interactuará el personal o el público a través de esta pantalla, si alguna de ellas ya existe como software de Windows sin otra versión, y quién del lado del cliente será responsable de mantener el sistema operativo parcheado una vez instalado.

La capacidad de TI existente importa más de lo que la gente cree inicialmente. Un cliente con un equipo de TI interno que ya administra máquinas con Windows puede absorber un punto final de Windows más sin mucha fricción: es un dispositivo más en un programa de parches que ya existe. Un cliente sin soporte de TI dedicado, que solicita una pantalla para un solo escaparate o sala de espera, a menudo se suscribe a una carga de mantenimiento mayor de la que cree si Windows entra sin una razón real de software detrás, porque ahora alguien (a menudo quienquiera que esté en el taller esa semana) es la persona de TI de facto para una máquina con Windows que ninguno de ellos sabe realmente cómo mantener.

El tiempo también importa, y es la parte que es más fácil omitir cuando un proyecto avanza rápido. La pregunta sobre el software necesita una respuesta antes de ordenar el hardware, no después y definitivamente no después de la instalación. Cada versión de esta pieza donde las cosas salieron mal comenzó con esa pregunta que se hizo demasiado tarde, una vez que alguien ya estaba comprometido con una configuración que no se ajustaba a lo que el proyecto realmente necesitaba.

Dónde encaja FVASEE

Debido a que esta decisión realmente depende del proyecto en lugar de una preferencia fija, construimos pantallas táctiles montadas en la pared en configuraciones de Android y Windows, en paneles de 42/43 pulgadas, 49/50 pulgadas, 55 pulgadas y 65 pulgadas, por lo que la elección del sistema operativo no tiene que estar dictada por cualquier configuración que esté disponible. La decisión correcta surge primero de los requisitos de integración y software: el tamaño de la pantalla y las especificaciones del hardware se deciden en torno a eso, y no al revés.

La versión corta

Windows gana su lugar cuando una pantalla tiene que ejecutar software empresarial o heredado específico, hacer malabarismos con más de una aplicación a la vez o integrarse profundamente con periféricos especializados que dependen de un soporte de controladores maduro. Android se gana su lugar en casi todos los demás lugares (señalización basada en contenido, directorios, orientación, quioscos minoristas y hoteleros sencillos) donde su simplicidad, menor costo y bloqueo más fácil realmente funcionan a favor del proyecto y no en contra. El error que vale la pena evitar no es elegir el sistema operativo "incorrecto" en algún sentido abstracto. Es elegir uno por costumbre antes de que alguien haya respondido la única pregunta que lo decide: ¿qué necesita esta pantalla para ejecutarse?