Wanneer heeft een aanraakscherm een ​​Windows-systeem nodig?

Vraag waarom een ​​bepaald aanraakscherm uiteindelijk Windows draaide in plaats van Android, en een verrassend aantal mensen kan eigenlijk niet met een reden antwoorden: het is 'wat we altijd bestellen', of 'wat de IT-afdeling gebruikt', of een regelitem dat is gekopieerd van het specificatieblad van een eerder project zonder dat iemand opnieuw heeft gecontroleerd of het nog steeds van toepassing is. Dat is meestal de reden dat de beslissing eerder op basis van gewoonte is genomen dan op basis van wat de software eigenlijk moet draaien, en het is een patroon dat in heel verschillende sectoren opduikt (de detailhandel, de gezondheidszorg, het bankwezen, het onderwijs) omdat het besturingssysteem vaak wordt gekozen voordat iemand daadwerkelijk heeft uitgezocht wat er op het scherm moet draaien. Tegen de tijd dat dat gat ontstaat, is de hardware vaak al besteld, en het terughalen ervan kost tijd waar niemand op had gerekend.

De faalmodus is niet dramatisch als deze zich voordoet. Niemand merkt het in de voorstelfase. Meestal komt het na een paar weken van een project naar boven wanneer iemand – bijna terzijde – vermeldt dat het scherm ook moet communiceren met een bestaand stuk software: een archiefsysteem, een planningstool, een interne databaseclient die al tien jaar stilletjes het bedrijf runt en nooit deel uitmaakte van het oorspronkelijke gesprek, omdat, van de kant van de klant, een scherm een ​​scherm is en software het probleem van iemand anders.

Dat is eigenlijk de vraag hieronder: "Heeft dit Windows nodig" - niet welk besturingssysteem over het algemeen beter is, maar welke specifieke software er op de doos moet draaien, en of die software je überhaupt een keuze geeft.

De vraag is niet ‘wat is beter’ – het is ‘wat ermee te maken heeft’

We worden vrij vaak gevraagd om de een of de ander standaard aan te bevelen. Klanten willen een eenvoudig antwoord, en wij begrijpen waarom: niemand wil een omweg van twee weken in de OS-architectuur voordat ze een scherm kunnen bestellen. Maar als je dit als een algemene voorkeursvraag behandelt, wordt het deel overgeslagen dat er werkelijk toe doet, en het is het deel dat bijna al het andere aan het project bepaalt: prijs, doorlooptijd, onderhoudslast en of het ding überhaupt op de eerste dag werkt.

Android en Windows concurreren hier niet op dezelfde as. Android op commerciële touch-hardware is gebouwd om een ​​vrij beperkt aantal dingen goed te kunnen uitvoeren: een browsergebaseerde of native app, een mediaspeler, een enkele vergrendelde interface die niet veel meer nodig heeft dan aanraakinvoer en een netwerkverbinding. Windows draagt ​​het gewicht van drie decennia aan bedrijfssoftware achter zich – boekhoudsystemen, medische dossiers, industriële besturingssoftware, point-of-sale-platforms, CAD-viewers, bankterminals – waarvan het grootste deel nooit is geschreven met een mobiel besturingssysteem in gedachten en niet snel zal worden herschreven, en in veel gevallen zelfs nooit zal worden herschreven, omdat de leverancier die het heeft gebouwd tien jaar geleden is gestopt met de actieve ontwikkeling ervan en het bedrijf van de klant er nog steeds op draait.

De echte eerste vraag bij elk project is dus niet 'Android of Windows'. Het is: moet er iets specifieks en ononderhandelbaars op dit scherm draaien, en bestaat die software alleen voor één van de twee platforms? Al het andere is een secundaire overweging, en als je dit als de primaire overweging beschouwt, hebben projecten uiteindelijk een hardware-swap in een laat stadium nodig.

Waar Windows daadwerkelijk zijn geld verdient

Oudere of gespecialiseerde software

Dit is de grote, en het is degene die de neiging heeft buiten de oorspronkelijke opdracht te blijven totdat een project al in volle gang is. Veel bedrijfssoftware is voor Windows gebouwd en is daar gebleven. Ziekenhuisinformatiesystemen, ERP-clients, bepaalde POS-platforms, industriële SCADA- en HMI-software, verzekerings- en bankterminals – een groot deel van deze software is vijftien of twintig jaar oud, wordt nog steeds gepatcht, runt nog steeds het bedrijf en heeft geen browser- of Android-equivalent dat hetzelfde werk doet. Als het werkelijke doel van een aanraakscherm is om als front-end voor een van deze systemen te dienen, heeft Windows over het algemeen geen voorkeur. Het is de enige optie die bestaat.

Een kassierassistentiescherm van een bankfiliaal is hier een duidelijk voorbeeld van: het kan nodig zijn om de eigen interne bankcliënt van de bank te gebruiken, dezelfde software die tellers aan de balie gebruiken, alleen gepresenteerd via een aanraakinterface voor klanten die hun saldo kunnen controleren of een afgedrukt afschrift kunnen opvragen. In dat geval is er zelden een echte beslissing te nemen. De software heeft één thuis, en dat is niet Android. Dezelfde logica is van toepassing op een fabrieksvloer, waar een bedieningspaneel vaak bestaande SCADA-software moet draaien die in de loop der jaren is gebouwd en gevalideerd voor een specifieke Windows-omgeving. Herschrijven of vervangen ervan ligt bijna nooit op tafel, alleen maar omdat een aanraakpaneel wordt vernieuwd.

Het patroon dat de moeite waard is om op te letten: als een klant zoiets zegt als "hij hoeft alleen maar verbinding te maken met ons systeem", heeft die zin onmiddellijk een vervolgvraag nodig: welk systeem en waar draait het op. Die ene follow-up heeft meer projecten gered van een herhaling in een laat stadium dan bijna al het andere op deze lijst, en het kost ongeveer dertig seconden om het te vragen.

Workflows met meerdere vensters of meerdere apps

Voor sommige interfaces is het echt nodig dat er meer dan één applicatie tegelijkertijd open is en met elkaar communiceert: een receptie met een planningsapp naast een documentscannerhulpprogramma, een winkelbalie met POS-software naast een tool voor het opzoeken van inventaris, een controlekamerpaneel met een live dashboard naast een diagnostisch hulpprogramma. De hele ontwerpfilosofie van Android is opgebouwd rond één app die het scherm tegelijk vult. Op sommige apparaten kun je dat omzeilen met split-screen-trucs, maar het is eerder vechten tegen het platform dan ermee werken, en de oplossing heeft de neiging zijn nadelen te laten zien de eerste keer dat een personeelslid onder druk snel tussen de twee moet schakelen. Windows is gebouwd voor precies dit soort gelaagde, multi-applicatie workflow, en het laat zien dat een project meer nodig heeft dan een enkele vergrendelde interface: het kopiëren van gegevens tussen twee open vensters, het uitvoeren van een achtergrondproces terwijl een personeelsgerichte app op de voorgrond blijft, dat soort dingen werkt gewoon zoals mensen dat verwachten.

Diepe hardware- en randintegratie

Op het moment dat een aanraakscherm moet communiceren met gespecialiseerde randapparatuur – barcodescanners met specifieke SDK’s, bonprinters, kaartlezers die zijn gekoppeld aan een bepaalde betalingsprocessor, industriële I/O-modules, PLC’s op de fabrieksvloer – zijn het driver- en integratie-ecosysteem net zo belangrijk als het besturingssysteem zelf. Windows heeft decennialange ondersteuning voor stuurprogramma's en een veel grotere verzameling bestaande integratiedocumentatie en tools van derden, wat veel belangrijker is dan het op papier lijkt als je degene bent die probeert een vijftien jaar oude barcodescanner te krijgen die met een gloednieuw aanraakscherm praat op een krappe deadline. De ondersteuning voor Android-randapparatuur is veel verbeterd, en voor gewone consumentenhardware zoals standaard USB-scanners of printers is het nu meestal prima. Voor echt industriële integraties – het soort met een eigen SDK, een zelden bijgewerkt stuurprogrammapakket of een leverancier die alleen maar met Windows testte – blijft dit vaker wel dan niet de weg van de minste weerstand, en het bestrijden daarvan op een deadline is zelden de besparingen waard.

Waar Android stilletjes wint

Niets van dit alles maakt Windows over het algemeen de "betere" keuze, en het is de moeite waard daar direct over te zijn, omdat veel projecten die uit gewoonte om Windows vragen eerlijk gezegd beter door Android zouden worden bediend.

Android start sneller op, herstelt soepeler van een stroomstoring en is aanzienlijk gemakkelijker in te stellen op een echte kioskmodus voor één doel, zonder dat er software van derden bovenop zit. Het is minder een doelwit voor het soort malware dat specifiek voor Windows circuleert, simpelweg omdat er minder van is geschreven voor deze klasse apparaten. Licenties zijn doorgaans eenvoudiger en goedkoper. Het stroomverbruik is meestal lager, wat belangrijker is dan mensen verwachten op displays die jarenlang continu aan staan, soms op locaties waar niemand goed op de elektriciteitsrekening voor één scherm let, maar het getal telt op voor de waarde van een hele winkelketen. En voor inhoud die fundamenteel gaat over het bladeren, zoeken en weergeven van media (gidsen, productcatalogi, bewegwijzering, de meeste bewegwijzering in de detailhandel en de horeca) wordt geen van de extra mogelijkheden van Windows daadwerkelijk gebruikt. Het zit daar gewoon als ongebruikte complexiteit die iemand maand na maand nog steeds moet patchen en onderhouden, zonder enig functioneel voordeel.

We hebben gezien dat klanten Windows om een ​​directorykiosk vroegen puur en alleen omdat "Windows professioneler aanvoelt" of omdat hun kantoorcomputers daar op draaien, zonder dat daar daadwerkelijk software voor nodig is. Dat is meestal het moment dat de moeite waard is om even bij stil te staan, omdat het doorgaans hogere hardwarekosten, een zwaardere IT-onderhoudslast en een langzamer, meer updategevoelig apparaat met zich meebrengt voor een klus waarvoor dat überhaupt nooit nodig was. Het eerlijke antwoord op de vraag "welke software moet hierop draaien" is vaak gewoon "geen, het toont alleen de productcatalogus" - en dat antwoord hardop uitspreken, voordat de bestelling binnenkomt, bespaart een klant meestal terugkerende licentiekosten gedurende de levensduur van de implementatie.

Een snelle darmchecklijst

Voordat u een besturingssysteemkeuze vastlegt, is het de moeite waard om een ​​korte lijst met feitelijke antwoorden door te nemen, geen aannames:

· Moet er een specifiek stukje bestaande bedrijfs- of oudere software op dit apparaat draaien, en is er geen Android- of browsergebaseerd equivalent?

· Moet er voor de interface meer dan één applicatie tegelijkertijd open zijn en met elkaar communiceren?

· Moet er verbinding worden gemaakt met gespecialiseerde randapparatuur (betaalterminals, industriële I/O, specifieke scanner- of printerhardware) die alleen over volwassen Windows-stuurprogramma's beschikken?

· Beheert het IT-team van de klant al een Windows-omgeving, met bestaande patch- en ondersteuningsprocessen, of zou Windows een geheel nieuwe onderhoudscategorie voor hen introduceren?

· Gaat de feitelijke taak op het scherm in wezen over het bladeren, zoeken of weergeven van inhoud, zonder dat er sprake is van diepere softwareafhankelijkheid?

Als de eerlijke antwoorden in de richting van de eerste drie neigen, is Windows waarschijnlijk de juiste keuze, ongeacht de kosten. Als ze naar het laatste neigen, klaart Android de klus meestal voor minder geld en minder onderhoud op de lange termijn - en "het voelt professioneler aan" hoort eigenlijk helemaal niet op deze lijst thuis.

De afweging die niemand vooraf vermeldt

Kostenvergelijkingen tussen de twee concentreren zich meestal op de stickerprijs van de licentie, die slechts een deel van het plaatje is. Het grotere verschil komt naar voren tijdens de levensduur van het beeldscherm, wat betreft patching, blootstelling aan beveiliging en hoeveel personeelstijd het in beslag neemt.

Geen van deze rijen is bedoeld om een ​​algehele winnaar aan te duiden. Ze zijn bedoeld om de daadwerkelijke afweging zichtbaar te maken voordat een beslissing wordt genomen op basis van gewoonte of onderbuikgevoel in plaats van op basis van wat het project nodig heeft.

Wat er gebeurt als klanten de verkeerde kiezen

We hebben gezien hoe dit in beide richtingen fout ging, en het is de moeite waard om het eerlijk te beschrijven, omdat beide fouten vaak voorkomen en geen van beide partijen zich daar schuldiger aan maakt dan de andere.

De Android-wanneer-je-nodig-Windows-versie ziet er meestal uit als het patroon dat aan het begin van dit stuk wordt beschreven: een project dat zich richt op inhoud en navigatie, met een softwarevereiste die pas aan de oppervlakte komt als de aanbesteding al aan de gang is. De oplossing op dat moment is óf een hardware-swap, wat tijd en soms geld kost, afhankelijk van hoe ver de bestelling is, óf een poging om een ​​Windows-applicatie in een Android-omgeving te plaatsen via een soort externe desktop-oplossing, die technisch gezien werkt, maar latentie, complexiteit en een afhankelijkheid van netwerkomstandigheden toevoegt die een native installatie nooit zou hebben gehad. Deze oplossing voor een extern bureaublad verschijnt in deze situatie vrij vaak als een noodoplossing, en het is nooit echt het antwoord dat iemand wilde - het is wat er gebeurt als een goede herhaling niet mogelijk is op de huidige tijdlijn en er toch iets moet worden verzonden.

De Windows-wanneer-je-het-niet-nodig-had-versie is stiller maar net zo gebruikelijk, en veroorzaakt geen dramatische mislukking zoals de Android-mismatch dat doet - wat een deel is van de reden waarom het zo lang onopgemerkt blijft. Een klant bestelt Windows voor een directory- of bewegwijzeringsscherm omdat ze dat gewend zijn, en een jaar later hebben ze te maken met onverwachte updatecycli die de weergave halverwege de dag onderbreken, incidentele driverconflicten na een Windows-update, en een IT-team dat nu nog een Windows-eindpunt moet patchen en controleren op een apparaat dat alleen maar een kaart moet weergeven. Er gebeurt niets catastrofaals. Het is gewoon een voortdurende overhead die een eenvoudiger besturingssysteem überhaupt nooit zou hebben gecreëerd, en die zich stilletjes opstapelt in iemands maandelijkse onderhoudswerklast voor een scherm dat om te beginnen nooit is gevraagd om iets specifieks voor Windows te doen.

Het besturingssysteem afstemmen op het project, niet op de gewoonte

De betrouwbare manier om dit te doen is door de softwarevraag vroeg en specifiek te stellen, en niet in het algemeen. "Moet het ergens mee verbonden zijn?" is te vaag – mensen zeggen nee omdat ze aan de voor de hand liggende dingen denken en de interne tool vergeten waar hun receptie elke ochtend zonder nadenken op inlogt, de tool die er al zo lang is dat niemand er meer over spreekt, omdat het gewoon onderdeel is van de manier waarop het kantoor werkt. Betere vragen klinken meer als: met welke applicaties zal het personeel of het publiek daadwerkelijk communiceren via dit scherm, bestaan ​​deze al als Windows-software zonder een andere versie, en wie aan de kant van de klant verantwoordelijk zal zijn voor het gepatcht houden van het besturingssysteem zodra het is geïnstalleerd.

Bestaande IT-capaciteiten zijn belangrijker dan mensen in eerste instantie denken. Een klant met een intern IT-team dat al Windows-machines beheert, kan zonder veel problemen nog een Windows-eindpunt overnemen: het is nog een apparaat op een patchschema dat al bestaat. Een klant zonder speciale IT-ondersteuning, die een scherm bestelt voor een enkele winkelpui of wachtkamer, tekent vaak voor meer onderhoudslasten dan hij of zij beseft als Windows inschakelt zonder dat er een echte softwarereden achter zit, omdat nu iemand (vaak degene die die week ook in de winkel aanwezig is) de feitelijke IT-persoon is voor een Windows-machine die niemand van hen eigenlijk weet te onderhouden.

Timing is ook belangrijk, en het is het onderdeel dat je het gemakkelijkst kunt overslaan als een project snel vordert. De softwarevraag heeft een antwoord nodig voordat hardware wordt besteld, niet erna, en zeker niet na de installatie. Elke versie van dit stuk waarin de zaken verkeerd gingen, begon met het feit dat die vraag te laat werd gesteld, zodra iemand zich al had vastgelegd op een configuratie die niet paste bij wat het project eigenlijk nodig had.

Waar FVASEE in past

Omdat deze beslissing echt afhangt van het project en niet van een vaste voorkeur, bouwen we aan de muur gemonteerde touchscreen-displays in zowel Android- als Windows-configuraties, verdeeld over 42/43-inch, 49/50-inch, 55-inch en 65-inch panelen, zodat de keuze voor het besturingssysteem niet hoeft te worden bepaald door welke configuratie dan ook op voorraad is. De juiste beslissing komt eerst voort uit de software- en integratievereisten: de schermgrootte en hardwarespecificaties worden daaromheen bepaald, en niet andersom.

De korte versie

Windows verdient zijn plek wanneer een beeldscherm specifieke bedrijfs- of oudere software moet draaien, meer dan één applicatie tegelijk moet gebruiken of diep moet integreren met gespecialiseerde randapparatuur die afhankelijk is van volwassen stuurprogramma-ondersteuning. Android verdient zijn plaats vrijwel overal – op inhoud gebaseerde bewegwijzering, telefoongidsen, bewegwijzering, eenvoudige winkel- en horecakiosken – waar de eenvoud, lagere kosten en gemakkelijkere vergrendeling eerder in het voordeel van het project werken dan in het nadeel. De fout die het vermijden waard is, is niet het "verkeerde" besturingssysteem in abstracte zin kiezen. Het is een keuze uit gewoonte voordat iemand daadwerkelijk de enige vraag heeft beantwoord die de beslissing bepaalt: wat moet dit scherm uitvoeren.