Quando un display touch ha bisogno di un sistema Windows?

Chiedi perché un dato display touch ha finito per eseguire Windows anziché Android, e un numero sorprendente di persone non riesce a rispondere con una ragione: è "ciò che ordiniamo sempre" o "ciò che utilizza il reparto IT" o un elemento pubblicitario che è stato copiato dalla scheda tecnica di un progetto precedente senza che nessuno ricontrollasse se fosse ancora applicato. Questo di solito indica che la decisione è stata presa in base all'abitudine piuttosto che a ciò di cui il software ha effettivamente bisogno per funzionare, ed è uno schema che si manifesta in settori molto diversi - vendita al dettaglio, sanità, banche, istruzione - perché il sistema operativo tende a essere scelto prima che qualcuno abbia effettivamente capito cosa deve essere eseguito sullo schermo. Quando il divario emerge, spesso l'hardware è già stato ordinato e riportarlo indietro costa tempo che nessuno aveva preventivato.

La modalità di fallimento non è drammatica quando si presenta. Nessuno se ne accorge in fase di proposta. Di solito emerge dopo qualche settimana dall'inizio di un progetto, quando qualcuno menziona - quasi per inciso - che lo schermo deve anche comunicare con qualche pezzo di software esistente: un sistema di record, uno strumento di pianificazione, un client di database interno che ha gestito silenziosamente l'attività per un decennio e non ha mai fatto parte della conversazione originale perché, dal lato del cliente, uno schermo è uno schermo e il software è un problema di qualcun altro.

Questa è davvero la domanda sotto "questo ha bisogno di Windows?" - non quale sistema operativo sia generalmente migliore, ma quale software specifico deve essere eseguito sulla scatola e se quel software ti dà una scelta.

La domanda non è "cosa è meglio" ma "cosa deve funzionare su di esso"

Ci viene chiesto, abbastanza spesso, di consigliare semplicemente l'uno o l'altro come predefinito. I clienti vogliono una risposta semplice e capiamo perché: nessuno vuole una deviazione di due settimane nell'architettura del sistema operativo prima di poter ordinare uno schermo. Ma trattandola come una domanda di preferenza generale si salta la parte che conta davvero, ed è la parte che determina quasi tutto il resto del progetto: prezzo, tempi di consegna, oneri di manutenzione e se la cosa funziona il primo giorno.

Android e Windows non competono sullo stesso asse qui. Android su hardware touch commerciale è progettato per eseguire bene un insieme abbastanza ristretto di cose: un'app nativa o basata su browser, un lettore multimediale, un'unica interfaccia bloccata che non richiede molto oltre l'input touch e una connessione di rete. Windows porta dietro di sé il peso di tre decenni di software aziendale (sistemi contabili, cartelle cliniche, software di controllo industriale, piattaforme POS, visualizzatori CAD, terminali bancari) la maggior parte dei quali non è mai stata scritta pensando a un sistema operativo di tipo mobile e non verrà riscritta presto e, in molti casi, non verrà mai riscritta, perché il fornitore che lo ha creato ha smesso di svilupparlo attivamente dieci anni fa e l'attività del cliente continua comunque a basarsi su di esso.

Quindi la vera prima domanda su qualsiasi progetto non è "Android o Windows". È: è necessario che qualcosa di specifico e non negoziabile venga eseguito su questa schermata e quel software esiste solo per una delle due piattaforme? Tutto il resto è una considerazione secondaria e trattarlo come primario è il modo in cui i progetti finiscono per aver bisogno di uno scambio hardware in fase avanzata.

Dove Windows guadagna effettivamente il suo mantenimento

Software legacy o specializzato

Questo è il momento più importante, ed è quello che tende a essere escluso dal brief originale finché il progetto non è già ben avviato. Molti software aziendali sono stati creati per Windows e sono rimasti lì. Sistemi informativi ospedalieri, client ERP, alcune piattaforme POS, software SCADA e HMI industriali, terminali assicurativi e bancari: gran parte di questo software ha quindici o vent'anni, viene ancora aggiornato, gestisce ancora l'attività e non ha un browser o un equivalente Android che svolga lo stesso lavoro. Se lo scopo effettivo di un display touch è quello di essere un front-end per uno di questi sistemi, Windows generalmente non è una preferenza. È l'unica opzione che esiste.

Lo schermo di assistenza del cassiere di una filiale bancaria ne è un chiaro esempio: potrebbe essere necessario eseguire il client bancario interno della banca, lo stesso software utilizzato dagli cassieri allo sportello, presentato semplicemente attraverso un'interfaccia touch per i clienti che controllano i saldi o richiedono un estratto conto stampato. Raramente c'è una vera decisione da prendere in quel caso. Il software ha una home e non è Android. La stessa logica si applica in una fabbrica, dove un pannello operatore spesso ha bisogno di eseguire il software SCADA esistente che è stato costruito e convalidato nel corso degli anni rispetto a uno specifico ambiente Windows: riscriverlo o sostituirlo non è quasi mai possibile solo perché un pannello a sfioramento viene aggiornato.

Lo schema che vale la pena osservare: se un cliente dice qualcosa del tipo "ha solo bisogno di connettersi al nostro sistema", quella frase richiede immediatamente una domanda di follow-up: su quale sistema e su cosa viene eseguito. Quel singolo follow-up ha salvato più progetti da una ripetizione in fase avanzata di quasi qualsiasi altra cosa in questo elenco, e chiedere richiede circa trenta secondi.

Flussi di lavoro multi-finestra o multi-app

Alcune interfacce necessitano effettivamente di più di un'applicazione aperta e interattiva allo stesso tempo: una reception che esegue un'app di pianificazione insieme a un'utilità per lo scanner di documenti, un bancone di vendita al dettaglio che esegue un software POS accanto a uno strumento di ricerca dell'inventario, un pannello della sala di controllo che mostra un dashboard live insieme a un'utilità di diagnostica. L'intera filosofia progettuale di Android si basa su un'app che riempie lo schermo alla volta. Puoi aggirare questo problema con trucchi a schermo diviso su alcuni dispositivi, ma sta combattendo la piattaforma piuttosto che lavorare con essa, e la soluzione alternativa tende a mostrare i suoi punti di forza la prima volta che un membro dello staff ha bisogno di passare rapidamente da una all'altra sotto pressione. Windows è stato creato esattamente per questo tipo di flusso di lavoro a più livelli e multi-applicazione, e dimostra che nel momento in cui un progetto ha bisogno di più di una singola interfaccia bloccata: copiare i dati tra due finestre aperte, eseguire un processo in background mentre un'app rivolta allo staff rimane in primo piano, quel genere di cose funziona proprio come le persone si aspettano.

Profonda integrazione di hardware e periferiche

Nel momento in cui un display touch deve comunicare con periferiche specializzate (lettori di codici a barre con SDK specifici, stampanti di ricevute, lettori di carte collegati a un particolare processore di pagamento, moduli I/O industriali, PLC in fabbrica) il driver e l'ecosistema di integrazione contano tanto quanto il sistema operativo stesso. Windows ha decenni di supporto per i driver alle spalle e un pool molto più ampio di documentazione di integrazione esistente e strumenti di terze parti, il che conta molto più di quanto sembri sulla carta quando sei tu quello che cerca di far comunicare uno scanner di codici a barre vecchio di quindici anni con un pannello touch nuovo di zecca in una scadenza ravvicinata. Il supporto delle periferiche Android è migliorato molto e per l'hardware comune rivolto ai consumatori come scanner o stampanti USB standard di solito ora va bene. Per le integrazioni genuinamente di livello industriale, tuttavia, del tipo con un SDK proprietario, un pacchetto di driver raramente aggiornato o un fornitore che ha sempre testato solo con Windows, rimane il percorso di minor resistenza il più delle volte, e combatterlo entro una scadenza raramente vale la pena risparmiare.

Dove Android vince silenziosamente

Niente di tutto ciò rende Windows la scelta "migliore" in generale, e vale la pena essere diretti al riguardo, perché molti progetti che richiedono Windows per abitudine sarebbero onestamente meglio serviti da Android.

Android si avvia più velocemente, si riprende da un'interruzione di corrente in modo più agevole ed è notevolmente più facile bloccarsi in una vera modalità chiosco monouso senza software di terze parti sovrapposto. Non è un bersaglio per il tipo di malware che circola specificamente per Windows, semplicemente perché ce n'è meno scritto per questa classe di dispositivi. La licenza è solitamente più semplice ed economica. Il consumo di energia tende ad essere inferiore, il che conta più di quanto la gente si aspetti su schermi che funzionano ininterrottamente per anni, a volte in luoghi in cui nessuno presta molta attenzione alla bolletta elettrica per uno schermo, ma il numero si somma al valore di un'intera catena di vendita al dettaglio. E per i contenuti che riguardano fondamentalmente la navigazione, la ricerca e la visualizzazione di contenuti multimediali (directory, cataloghi di prodotti, indicazioni stradali, la maggior parte della segnaletica di vendita al dettaglio e di ospitalità), nessuna delle funzionalità extra di Windows viene effettivamente utilizzata. Resta lì come complessità inutilizzata che qualcuno deve ancora patchare e mantenere, mese dopo mese, senza alcun beneficio funzionale.

Abbiamo visto clienti richiedere a Windows un chiosco di directory semplicemente perché "Windows sembra più professionale" o perché è ciò che eseguono i loro computer da ufficio, senza alcun reale requisito software dietro di esso. Di solito è questo il momento su cui vale la pena soffermarsi, perché tende a significare un costo hardware più elevato, un carico di manutenzione IT più pesante e un dispositivo più lento e più soggetto ad aggiornamenti per un lavoro che non ha mai avuto bisogno di tutto ciò. La risposta onesta alla domanda "quale software deve essere eseguito" è molto spesso semplicemente "nessuno, mostra solo il catalogo dei prodotti" e ottenere quella risposta ad alta voce, prima che venga effettuato l'ordine, di solito è ciò che fa risparmiare al cliente un costo di licenza ricorrente per tutta la durata dell'implementazione.

Una rapida lista di controllo dell'intestino

Prima di scegliere la scelta del sistema operativo, vale la pena esaminare un breve elenco di risposte effettive, non di ipotesi:

· È necessario che su questo dispositivo sia eseguito un software aziendale o legacy specifico e non esiste un equivalente Android o basato su browser?

· L'interfaccia necessita che più di un'applicazione sia aperta e interagisca contemporaneamente?

· Ha bisogno di connettersi a periferiche specializzate (terminali di pagamento, I/O industriali, hardware specifico per scanner o stampanti) che dispongono solo di driver Windows maturi?

· Il team IT del cliente gestisce già un ambiente Windows, con patch e processi di supporto esistenti, oppure Windows introdurrà per loro una categoria di manutenzione completamente nuova?

· L'effettiva attività sullo schermo riguarda fondamentalmente la navigazione, la ricerca o la visualizzazione di contenuti, senza alcuna dipendenza dal software più profonda?

Se le risposte oneste si orientano verso le prime tre, Windows è probabilmente la scelta giusta, indipendentemente dal costo. Se si orientano verso l'ultimo, Android di solito porta a termine il lavoro con meno soldi e meno manutenzione a lungo termine - e "sembra più professionale" non appartiene affatto a questo elenco.

Il compromesso che nessuno menziona in anticipo

I confronti dei costi tra i due tendono a concentrarsi sul prezzo adesivo della licenza, che è solo una parte del quadro. La differenza più grande si manifesta nella durata operativa del display, nelle patch, nell'esposizione alla sicurezza e nella quantità di tempo impiegato dal personale.

Nessuna di queste righe ha lo scopo di dichiarare un vincitore assoluto. Hanno lo scopo di rendere visibile il reale compromesso prima che venga presa una decisione in base all'abitudine o al sentimento invece che in base a ciò di cui il progetto ha bisogno.

Cosa succede quando i clienti scelgono quello sbagliato

Abbiamo visto la situazione andare storta in entrambe le direzioni, e vale la pena descriverla onestamente perché entrambi gli errori sono comuni e nessuna delle due parti ne è più colpevole dell'altra.

La versione Android-quando-ne hai bisogno-Windows di solito assomiglia al modello descritto all'inizio di questo articolo: un progetto incentrato sul contenuto e sulla navigazione, con un requisito software che emerge solo una volta che l'approvvigionamento è già in corso. La soluzione a quel punto è o uno scambio di hardware, che costa tempo e talvolta denaro a seconda di quanto è lungo l'ordine, o il tentativo di inserire un'applicazione solo Windows in un ambiente Android attraverso una sorta di soluzione desktop remota, che tecnicamente funziona ma aggiunge latenza, complessità e dipendenza dalle condizioni di rete che un'installazione nativa non avrebbe mai avuto. Questa soluzione alternativa al desktop remoto si presenta come un ripiego abbastanza spesso in questa situazione, e non è mai veramente la risposta che qualcuno voleva: è ciò che accade quando una ripetizione adeguata non è possibile sulla sequenza temporale attuale e qualcosa deve essere spedito comunque.

La versione di Windows quando non ne hai bisogno è più silenziosa ma altrettanto comune e non produce un fallimento drammatico come fa la mancata corrispondenza di Android, il che è parte del motivo per cui passa inosservata per così tanto tempo. Un cliente ordina a Windows una directory o una schermata di segnaletica perché è ciò a cui è abituato e un anno dopo si trova a dover affrontare cicli di aggiornamento imprevisti che interrompono lo schermo a metà giornata, conflitti occasionali di driver dopo un aggiornamento di Windows e un team IT che ora ha un altro endpoint Windows da applicare e monitorare per un dispositivo che dovrebbe solo mostrare una mappa. Non succede nulla di catastrofico. Si tratta semplicemente di un sovraccarico che un sistema operativo più semplice non avrebbe mai creato in primo luogo, accumulandosi silenziosamente nel carico di lavoro di manutenzione mensile di qualcuno per uno schermo a cui non è mai stato chiesto di fare qualcosa di specifico per Windows per cominciare.

Adattare il sistema operativo al progetto, non all'abitudine

Il modo affidabile per risolvere questo problema è porre la domanda sul software in anticipo e in modo specifico, non in generale. "Ha bisogno di connettersi a qualcosa?" è troppo vago: le persone dicono di no perché pensano alle cose ovvie e dimenticano lo strumento interno a cui la loro reception accede ogni mattina senza pensarci due volte, quello che è lì da così tanto tempo che nessuno lo menziona più perché è semplicemente parte del modo in cui funziona l'ufficio. Domande migliori sembrano più simili a: con quali applicazioni il personale o il pubblico interagiranno effettivamente attraverso questa schermata, qualcuna di esse esiste già come software Windows senza altra versione e chi, dal lato del cliente, sarà responsabile di mantenere il sistema operativo aggiornato una volta installato.

Le capacità IT esistenti contano più di quanto le persone inizialmente credano. Un cliente con un team IT interno che già gestisce macchine Windows può assorbire un ulteriore endpoint Windows senza troppi attriti: si tratta di un dispositivo in più con una pianificazione di patch già esistente. Un cliente senza supporto IT dedicato, che ordina uno schermo per un singolo negozio o sala d'attesa, spesso si sottoscrive per un onere di manutenzione maggiore di quanto si renda conto se Windows viene installato senza una vera ragione software dietro, perché ora qualcuno - spesso chiunque si trovi in ​​negozio quella settimana - è di fatto la persona IT per una macchina Windows che nessuno di loro sa effettivamente come manutenere.

Anche il tempismo è importante ed è la parte più facile da saltare quando un progetto si muove velocemente. La domanda sul software necessita di una risposta prima che l'hardware venga ordinato, non dopo e sicuramente non dopo l'installazione. Ogni versione di questo pezzo in cui le cose andavano male è iniziata con la domanda posta troppo tardi, una volta che qualcuno era già impegnato in una configurazione che non si adattava a ciò di cui il progetto aveva effettivamente bisogno.

Dove si inserisce FVASEE

Poiché questa decisione dipende realmente dal progetto piuttosto che da una preferenza fissa, costruiamo display touch screen montati a parete sia in configurazioni Android che Windows, su pannelli da 42/43 pollici, 49/50 pollici, 55 pollici e 65 pollici, quindi la scelta del sistema operativo non deve essere dettata dalla configurazione presente in magazzino. La decisione giusta viene innanzitutto dai requisiti software e di integrazione: le dimensioni dello schermo e le specifiche hardware vengono decise in base a questi, e non viceversa.

La versione breve

Windows guadagna il suo posto quando un display deve eseguire specifici software aziendali o legacy, destreggiarsi tra più applicazioni contemporaneamente o integrarsi profondamente con periferiche specializzate che dipendono dal supporto di driver maturi. Android guadagna il suo posto quasi ovunque – segnaletica basata sui contenuti, directory, indicazioni stradali, semplici chioschi di vendita al dettaglio e di ospitalità – dove la sua semplicità, i costi inferiori e il blocco più semplice funzionano effettivamente a favore del progetto piuttosto che contro di esso. L'errore che vale la pena evitare non è quello di scegliere il sistema operativo "sbagliato" in senso astratto. Ne sceglie uno per abitudine prima che qualcuno abbia effettivamente risposto all'unica domanda che lo decide: di cosa ha bisogno questo schermo per funzionare.