Zuhause > Über uns > Blogs > Wann braucht ein Touch-Display ein Windows-System?

Wann braucht ein Touch-Display ein Windows-System?

Zeit: 2026-09-14
Ansichten: 2

Auf die Frage, warum auf einem bestimmten Touch-Display schließlich Windows statt Android lief, können überraschend viele Leute nicht wirklich eine Begründung nennen: „Was wir immer bestellen“ oder „Was die IT-Abteilung verwendet“ oder ein Einzelposten, der aus dem Datenblatt eines früheren Projekts kopiert wurde, ohne dass jemand noch einmal überprüft hat, ob er noch zutrifft. Das ist in der Regel ein Hinweis darauf, dass die Entscheidung aus Gewohnheit und nicht danach getroffen wurde, was die Software tatsächlich ausführen muss, und dieses Muster zeigt sich in sehr unterschiedlichen Branchen – Einzelhandel, Gesundheitswesen, Banken, Bildungswesen –, da das Betriebssystem in der Regel ausgewählt wird, bevor irgendjemand tatsächlich herausgefunden hat, was auf dem Bildschirm ausgeführt werden muss. Wenn Lücken entstehen, ist die Hardware oft bereits bestellt, und die Rücksendung kostet Zeit, die niemand eingeplant hat.

Der Fehlermodus ist nicht dramatisch, wenn er auftritt. Niemand bemerkt es im Angebotsstadium. Gewöhnlich taucht es ein paar Wochen nach Beginn eines Projekts auf, wenn jemand – fast nebenbei – erwähnt, dass der Bildschirm auch mit einer vorhandenen Software kommunizieren muss: einem Aufzeichnungssystem, einem Planungstool, einem internen Datenbank-Client, der seit einem Jahrzehnt stillschweigend das Geschäft leitet und nie Teil der ursprünglichen Konversation war, weil aus Sicht des Kunden ein Bildschirm ein Bildschirm und Software das Problem eines anderen ist.

Das ist eigentlich die Frage unter „Braucht man dafür Windows?“ – nicht, welches Betriebssystem im Allgemeinen besser ist, sondern welche spezielle Software auf dem Gerät laufen muss und ob diese Software Ihnen überhaupt eine Wahl lässt.

Die Frage lautet nicht „Was ist besser“, sondern „Was muss darauf laufen?“

Wir werden ziemlich oft gebeten, nur das eine oder andere als Standard zu empfehlen. Kunden wollen eine einfache Antwort, und wir verstehen, warum – niemand möchte einen zweiwöchigen Abstecher in die Betriebssystemarchitektur machen, bevor er einen Bildschirm bestellen kann. Aber wenn man dies als allgemeine Präferenzfrage behandelt, wird der Teil übersprungen, der tatsächlich zählt, und der Teil, der fast alles andere über das Projekt bestimmt: Preis, Vorlaufzeit, Wartungsaufwand und ob das Ding am ersten Tag überhaupt funktioniert.

Android und Windows konkurrieren hier nicht auf der gleichen Achse. Android auf handelsüblicher Touch-Hardware ist darauf ausgelegt, eine relativ begrenzte Anzahl von Dingen gut auszuführen: eine browserbasierte oder native App, einen Mediaplayer, eine einzige gesperrte Schnittstelle, die nicht viel außer Touch-Eingabe und einer Netzwerkverbindung benötigt. Windows trägt das Gewicht von drei Jahrzehnten Unternehmenssoftware in sich – Buchhaltungssysteme, Patientenakten-Clients, industrielle Steuerungssoftware, Point-of-Sale-Plattformen, CAD-Viewer, Bankterminals –, von denen die meisten nie mit Blick auf ein mobiles Betriebssystem geschrieben wurden und auch nicht so schnell neu geschrieben werden, und in vielen Fällen auch nie, weil der Hersteller, der sie entwickelt hat, vor einem Jahrzehnt aufgehört hat, sie aktiv weiterzuentwickeln, und das Geschäft des Kunden läuft ohnehin immer noch darauf.

Die eigentliche erste Frage bei jedem Projekt lautet also nicht „Android oder Windows“. Es geht darum: Muss auf diesem Bildschirm etwas Bestimmtes und Nichtverhandelbares laufen, und existiert diese Software nur für eine der beiden Plattformen? Alles andere ist zweitrangig, und wenn man es als primär betrachtet, kommt es dazu, dass Projekte letztendlich einen Hardware-Austausch in der Spätphase benötigen.

Wo Windows tatsächlich seinen Unterhalt verdient

Legacy- oder Spezialsoftware

Dies ist das große Problem, und es ist das Problem, das im ursprünglichen Briefing oft außen vor bleibt, bis ein Projekt bereits in vollem Gange ist. Viele Unternehmenssoftware wurde für Windows entwickelt und blieb dort bestehen. Krankenhausinformationssysteme, ERP-Clients, bestimmte POS-Plattformen, industrielle SCADA- und HMI-Software, Versicherungs- und Bankterminals – viele dieser Softwareprogramme sind fünfzehn oder zwanzig Jahre alt, werden immer noch gepatcht, steuern immer noch das Geschäft und verfügen über kein browserbasiertes oder Android-Äquivalent, das die gleiche Aufgabe erfüllt. Wenn der eigentliche Zweck eines Touch-Displays darin besteht, als Frontend für eines dieser Systeme zu fungieren, ist Windows im Allgemeinen keine Option. Es ist die einzige Option, die es gibt.

Der Kassiererbildschirm einer Bankfiliale ist ein klares Beispiel hierfür: Er muss möglicherweise den internen Kernbank-Client der Bank ausführen, die gleiche Software, die Kassierer am Schalter verwenden, die den Kunden lediglich über eine Touch-Oberfläche angezeigt wird, um ihren Kontostand zu überprüfen oder einen gedruckten Kontoauszug anzufordern. Eine wirkliche Entscheidung muss in diesem Fall selten getroffen werden. Die Software hat ein Zuhause und ist nicht Android. Die gleiche Logik gilt in einer Fabrikhalle, wo auf einem Bedienpanel häufig vorhandene SCADA-Software ausgeführt werden muss, die über Jahre hinweg für eine bestimmte Windows-Umgebung erstellt und validiert wurde – ein Umschreiben oder Ersetzen ist fast nie in Frage, nur weil ein Touchpanel aktualisiert wird.

Das Muster, auf das es sich zu achten lohnt: Wenn ein Kunde etwas sagt wie „Es muss nur eine Verbindung zu unserem System hergestellt werden“, erfordert dieser Satz sofort eine Folgefrage – welches System und auf welchem ​​System läuft es? Dieses einzige Follow-up hat mehr Projekte vor einer Wiederholung in der Spätphase gerettet als fast alles andere auf dieser Liste, und die Frage dauert etwa dreißig Sekunden.

Multi-Window- oder Multi-App-Workflows

Bei manchen Schnittstellen muss tatsächlich mehr als eine Anwendung gleichzeitig geöffnet sein und interagieren – eine Rezeption, auf der eine Terminplanungs-App neben einem Dokumentenscanner-Dienstprogramm läuft, eine Verkaufstheke, auf der eine POS-Software neben einem Tool zur Bestandssuche läuft, ein Kontrollraumpanel mit einem Live-Dashboard neben einem Diagnosedienstprogramm. Die gesamte Designphilosophie von Android basiert darauf, dass jeweils eine App den Bildschirm ausfüllt. Auf manchen Geräten kann man das mit Split-Screen-Tricks umgehen, aber das ist eher ein Kampf gegen die Plattform, als dass man mit ihr arbeitet, und die Problemumgehung zeigt meist ihre Nähte, wenn ein Mitarbeiter zum ersten Mal unter Druck schnell zwischen den beiden wechseln muss. Windows wurde für genau diese Art von mehrschichtigem Workflow mit mehreren Anwendungen entwickelt und zeigt den Moment an, in dem ein Projekt mehr als eine einzelne gesperrte Schnittstelle benötigt – das Kopieren von Daten zwischen zwei geöffneten Fenstern, das Ausführen eines Hintergrundprozesses, während eine mitarbeiterorientierte App im Vordergrund bleibt – so etwas funktioniert genau so, wie die Leute es erwarten.

Tiefe Hardware- und Peripherieintegration

In dem Moment, in dem ein Touch-Display mit speziellen Peripheriegeräten kommunizieren muss – Barcode-Scanner mit bestimmten SDKs, Belegdrucker, an einen bestimmten Zahlungsprozessor gebundene Kartenleser, industrielle I/O-Module, SPS in einer Fabrikhalle – sind das Treiber- und Integrationsökosystem genauso wichtig wie das Betriebssystem selbst. Windows verfügt über jahrzehntelange Treiberunterstützung und einen viel größeren Pool an vorhandener Integrationsdokumentation und Tools von Drittanbietern, was viel wichtiger ist, als es auf dem Papier klingt, wenn Sie versuchen, einen fünfzehn Jahre alten Barcodescanner innerhalb einer engen Frist mit einem brandneuen Touchpanel kommunizieren zu lassen. Die Unterstützung von Android-Peripheriegeräten hat sich erheblich verbessert und ist für gängige Hardware für den Verbraucherbereich wie Standard-USB-Scanner oder -Drucker jetzt normalerweise in Ordnung. Bei wirklich industrietauglichen Integrationen – solche mit einem proprietären SDK, einem selten aktualisierten Treiberpaket oder einem Anbieter, der nur gegen Windows getestet hat – bleibt dies jedoch in den meisten Fällen der Weg des geringsten Widerstands, und es lohnt sich selten, ihn innerhalb einer bestimmten Frist zu bekämpfen, um die Einsparungen zu erzielen.

Wo Android leise gewinnt

Nichts davon macht Windows im Allgemeinen zur „besseren“ Wahl, und es lohnt sich, das direkt zu sagen, denn viele Projekte, die aus Gewohnheit nach Windows fragen, wären ehrlich gesagt mit Android besser bedient.

Android startet schneller, erholt sich nach einem Stromausfall reibungsloser und lässt sich wesentlich einfacher in einen echten Einzweck-Kioskmodus versetzen, ohne dass darüber hinausgehende Software von Drittanbietern erforderlich ist. Es ist weniger ein Ziel für die Art von Malware, die speziell für Windows im Umlauf ist, einfach weil weniger davon für diese Geräteklasse geschrieben wurde. Die Lizenzierung ist in der Regel einfacher und günstiger. Der Stromverbrauch ist tendenziell geringer, was bei Displays, die jahrelang ununterbrochen laufen, von größerer Bedeutung ist, als man es erwartet, manchmal an Orten, an denen niemand genau auf die Stromrechnung für einen Bildschirm achtet, sich die Zahl aber über den Wert einer ganzen Einzelhandelskette summiert. Und für Inhalte, bei denen es im Wesentlichen um das Durchsuchen, Suchen und Anzeigen von Medien geht – Verzeichnisse, Produktkataloge, Wegweiser, die meisten Beschilderungen im Einzelhandel und im Gastgewerbe – wird keine der zusätzlichen Funktionen von Windows tatsächlich genutzt. Es liegt einfach als ungenutzte Komplexität da, die noch immer von jemandem Monat für Monat gepatcht und gewartet werden muss, ohne dass es einen funktionalen Nutzen bringt.

Wir haben gesehen, dass Kunden Windows nach einem Verzeichnis-Kiosk gefragt haben, nur weil „Windows sich professioneller anfühlt“ oder weil das auf ihren Bürocomputern läuft, ohne dass dahinter tatsächliche Softwareanforderungen stecken. Das ist normalerweise der Moment, an dem es sich lohnt, innezuhalten, denn das bedeutet tendenziell höhere Hardwarekosten, einen größeren IT-Wartungsaufwand und ein langsameres, updateanfälligeres Gerät für einen Job, der so etwas überhaupt nicht brauchte. Die ehrliche Antwort auf die Frage „Welche Software muss das ausführen?“ lautet sehr oft einfach „Keine, es wird nur der Produktkatalog angezeigt“ – und diese Antwort laut auszusprechen, bevor die Bestellung eingeht, ist in der Regel das, was einem Kunden die wiederkehrenden Lizenzkosten für die gesamte Lebensdauer der Bereitstellung erspart.

Eine kurze Darm-Checkliste

Bevor Sie sich für ein Betriebssystem entscheiden, lohnt es sich, eine kurze Liste mit tatsächlichen Antworten und nicht mit Annahmen durchzugehen:

· Muss ein bestimmter Teil bestehender Unternehmens- oder Legacy-Software auf diesem Gerät ausgeführt werden und verfügt es über kein Android- oder browserbasiertes Äquivalent?

· Muss die Schnittstelle mehr als eine Anwendung gleichzeitig öffnen und interagieren?

· Muss eine Verbindung zu speziellen Peripheriegeräten hergestellt werden – Zahlungsterminals, Industrie-E/A, bestimmte Scanner- oder Druckerhardware –, die nur über ausgereifte Windows-Treiber verfügen?

· Verwaltet das IT-Team des Kunden bereits eine Windows-Umgebung mit vorhandenen Patch- und Supportprozessen oder würde Windows für sie eine völlig neue Wartungskategorie einführen?

· Geht es bei der eigentlichen Aufgabe auf dem Bildschirm im Wesentlichen um das Durchsuchen, Suchen oder Anzeigen von Inhalten, ohne dass eine tiefere Abhängigkeit von der Software besteht?

Wenn die ehrlichen Antworten zu den ersten drei tendieren, ist Windows unabhängig von den Kosten wahrscheinlich die richtige Entscheidung. Wenn sie sich für Letzteres entscheiden, erledigt Android die Arbeit normalerweise für weniger Geld und weniger langfristige Wartung – und „es fühlt sich professioneller an“ gehört überhaupt nicht auf diese Liste.

Der Kompromiss, den niemand im Voraus erwähnt

Kostenvergleiche zwischen beiden konzentrieren sich in der Regel auf den Aufkleberpreis der Lizenz, der nur ein Teil des Bildes ist. Der größere Unterschied zeigt sich im Laufe der Nutzungsdauer des Displays, beim Patchen, beim Sicherheitsrisiko und beim Personalaufwand.

Faktor

Windows

Android

Softwarekompatibilität

Führt Legacy- und Unternehmensanwendungen aus, auf die die meisten Unternehmen bereits angewiesen sind

Am besten für browserbasierte, App-basierte oder speziell erstellte Inhalte geeignet

Lizenzkosten

Höhere Lizenz pro Einheit erforderlich

Niedriger, oft im Lieferumfang der Hardware enthalten

Sperr-/Kioskmodus

Möglich, erfordert normalerweise Kiosksoftware eines Drittanbieters

Nativ und im Allgemeinen einfacher zu konfigurieren

Patchen und Wartung

Regelmäßige Updates auf Betriebssystemebene, größere Angriffsfläche

Geringerer Update-Footprint, kleinere Angriffsfläche

Bootzeit und Wiederherstellung

Langsamerer Start, anfälliger für updatebedingte Verzögerungen

Schneller Start, saubere Wiederherstellung nach Stromausfall

Peripherie- und Treiberunterstützung

Breites, ausgereiftes Ökosystem

Verbessernd, aber schmaler für Hardware in Industriequalität

Keine dieser Zeilen soll einen Gesamtsieger bekannt geben. Sie sollen den tatsächlichen Kompromiss sichtbar machen, bevor eine Entscheidung aus Gewohnheit oder Bauchgefühl statt aufgrund der Anforderungen des Projekts getroffen wird.

Was passiert, wenn Kunden das Falsche auswählen?

Wir haben beobachtet, wie dies in beide Richtungen schiefging, und es lohnt sich, es ehrlich zu beschreiben, denn beide Fehler kommen häufig vor und keine Seite trägt mehr Schuld daran als die andere.

Die Android-Windows-Version bei Bedarf sieht normalerweise wie das zu Beginn dieses Artikels beschriebene Muster aus – ein Projekt, das sich auf Inhalt und Navigation konzentriert und eine Softwareanforderung aufweist, die erst auftaucht, wenn die Beschaffung bereits im Gange ist. Die Lösung an diesem Punkt ist entweder ein Hardware-Austausch, der Zeit und manchmal auch Geld kostet, je nachdem, wie weit die Bestellung bereits fortgeschritten ist, oder der Versuch, eine reine Windows-Anwendung über eine Art Remote-Desktop-Workaround in eine Android-Umgebung zu schleusen, was technisch funktioniert, aber Latenz, Komplexität und eine Abhängigkeit von Netzwerkbedingungen mit sich bringt, die bei einer nativen Installation nie gegeben gewesen wäre. Dieser Remote-Desktop-Workaround erscheint in dieser Situation ziemlich oft als Notlösung und ist nie wirklich die Antwort, die irgendjemand wollte – er passiert, wenn eine ordnungsgemäße Wiederherstellung auf der aktuellen Zeitachse nicht möglich ist und etwas trotzdem geliefert werden muss.

Die Windows-When-you-didn't-need-it-Version ist leiser, aber genauso häufig und führt nicht zu einem dramatischen Ausfall wie die Android-Nichtübereinstimmung – was einer der Gründe dafür ist, dass sie so lange unbemerkt bleibt. Ein Kunde bestellt Windows für einen Verzeichnis- oder Beschilderungsbildschirm, weil er daran gewöhnt ist, und ein Jahr später hat er mit unerwarteten Update-Zyklen zu kämpfen, die die Anzeige mittags unterbrechen, gelegentlichen Treiberkonflikten nach einem Windows-Update und einem IT-Team, das jetzt einen weiteren Windows-Endpunkt patchen und überwachen muss, um ein Gerät zu überwachen, das nur eine Karte anzeigen soll. Es passiert nichts Katastrophales. Es handelt sich lediglich um einen fortlaufenden Overhead, den ein einfacheres Betriebssystem von vornherein nie verursacht hätte und der sich stillschweigend in der monatlichen Wartungsarbeitslast eines Bildschirms ansammelt, der von vornherein nie aufgefordert wurde, etwas Windows-spezifisches zu tun.

Passen Sie das Betriebssystem an das Projekt an, nicht an die Gewohnheit

Der zuverlässige Weg dorthin besteht darin, die Softwarefrage frühzeitig und konkret zu stellen, nicht allgemein. „Muss es mit irgendetwas verbunden werden?“ ist zu vage – die Leute sagen „Nein“, weil sie über das Offensichtliche nachdenken und das interne Tool, in das sich ihre Rezeption jeden Morgen einloggt, ohne einen zweiten Gedanken zu vergessen, das schon so lange existiert, dass es niemand mehr erwähnt, weil es einfach ein Teil der Art und Weise ist, wie das Büro funktioniert. Bessere Fragen lauten eher wie folgt: Mit welchen Anwendungen werden Mitarbeiter oder die Öffentlichkeit tatsächlich über diesen Bildschirm interagieren, sind einige davon bereits als Windows-Software ohne andere Version vorhanden und wer auf Kundenseite ist dafür verantwortlich, das Betriebssystem nach der Installation auf dem neuesten Stand zu halten?

Vorhandene IT-Fähigkeiten sind wichtiger, als man zunächst annimmt. Ein Kunde mit einem internen IT-Team, das bereits Windows-Rechner verwaltet, kann ohne große Reibung einen weiteren Windows-Endpunkt übernehmen – es handelt sich um ein weiteres Gerät in einem bereits vorhandenen Patch-Plan. Ein Kunde ohne dedizierten IT-Support, der einen Bildschirm für ein einzelnes Schaufenster oder einen Warteraum bestellt, muss sich oft mit einem höheren Wartungsaufwand begnügen, als ihm bewusst ist, wenn Windows ohne einen echten Softwaregrund eingesetzt wird, weil jetzt jemand – oft wer auch immer gerade in dieser Woche in der Werkstatt ist – de facto der IT-Mitarbeiter für einen Windows-Rechner ist, von dem keiner wirklich weiß, wie man ihn wartet.

Auch das Timing spielt eine Rolle, und es ist der Teil, den man am einfachsten überspringen kann, wenn ein Projekt schnell voranschreitet. Die Software-Frage muss vor der Bestellung der Hardware beantwortet werden, nicht erst nach und schon gar nicht nach der Installation. Jede Version dieses Artikels, bei der die Dinge schief liefen, begann damit, dass diese Frage zu spät gestellt wurde, als sich jemand bereits auf eine Konfiguration festgelegt hatte, die nicht zu den tatsächlichen Anforderungen des Projekts passte.

Wo FVASEE hineinpasst

Da diese Entscheidung wirklich vom Projekt und nicht von einer festen Präferenz abhängt, bauen wir wandmontierte Touchscreen-Displays sowohl in Android- als auch in Windows-Konfigurationen auf 42/43-Zoll-, 49/50-Zoll-, 55-Zoll- und 65-Zoll-Panels, sodass die Wahl des Betriebssystems nicht von der gerade auf Lager befindlichen Konfiguration bestimmt werden muss. Die richtige Entscheidung ergibt sich zunächst aus den Software- und Integrationsanforderungen – Bildschirmgröße und Hardwarespezifikation werden danach entschieden, nicht umgekehrt.

Die Kurzversion

Windows verdient seinen Platz, wenn auf einem Display bestimmte Unternehmens- oder Legacy-Software ausgeführt, mehr als eine Anwendung gleichzeitig ausgeführt oder eine umfassende Integration in spezielle Peripheriegeräte erfolgen muss, die auf ausgereifte Treiberunterstützung angewiesen sind. Android verdient seinen Platz fast überall sonst – inhaltsgesteuerte Beschilderung, Verzeichnisse, Wegweiser, unkomplizierte Einzelhandels- und Gastgewerbekioske –, wo seine Einfachheit, geringere Kosten und einfachere Sperrung tatsächlich eher für das Projekt als gegen es wirken. Der Fehler, den es zu vermeiden gilt, besteht nicht darin, im abstrakten Sinne das „falsche“ Betriebssystem auszuwählen. Es geht darum, aus Gewohnheit einen auszuwählen, bevor irgendjemand die entscheidende Frage tatsächlich beantwortet hat: Was muss dieser Bildschirm zum Ausführen haben?