In den letzten 30 Jahren bin ich wohl „jeder Sau, die durchs Dorf getrieben wird“ auch hinterher gelaufen.
Angefangen vom eigenen Zeileneditor in Basic, den Masken von dBase, die nach meinen Bedürfnissen geänderte Maskenverwaltung von Clipper / xBase, den „SAA Tools für C“, der auch nach meinen Erfordernissen angepassten Fensteroberfläche von Microsoft VisualBasic for DOS, dem GUI von Windows in den verschiedenen Versionen, zwischendrin dem von OS/2, diversen Fensterverwaltungen unter X-Window, MVC, AWT, Swing „native“, Swing mit den Frameworks meiner verschiedenen Kunden, SWT, GWT und HTML habe ich auf dem PC wohl alles mitgemacht, was so kam und vielfach auch wieder ging.
Bei FAT-Clients und auch bei Clients, die „nur“ die Masken fest kodiert haben, entsteht ein sehr grosser Verteilungsaufwand. Mal eben schnell eine Maske ändern dauert 5 Minuten, das Verteilen, insbesondere mit den Vorbereitungen, eher 6 bis 8 Wochen.
Auf dem Grossrechner habe ich ISPF Masken in COBOL von Hand programmiert (war an der Hochschule) und verschiedene Tools und Generatoren genutzt, je nach dem, was der Kunde einsetzte.
Wirklich brauchbar war unter Siemens BS2000 das Benutzer-Interface von Siline-200, auf einem 9750 Terminal wurde lokal editiert, der DÜ-Taste die komplette Maske an den Rechner übertragen, dort sah der Entwickler die Daten in einer Struktur (Copystrecke), verarbeitete sie komplett, füllte die Struktur für die Folge-Maske und fertig.
GUIs, wenn sie heute neu konzipiert werden, nutzen HTML5. Die ersten HTML Masken waren nicht besonders sexy, mittlerweile ist die Benutzerinteraktion dank AJAX genauso gut wie bei Masken mit Swing oder SWT.
Ich sehe aber HTML kritisch.
Zum einen wird ein WebServer benötigt, also eine zustandsbehafteter Server, den sich viele Benutzer teilen und dessen Ausfall weite Kreise zieht. Also werden mehrere WebServer eingesetzt, die den jeweiligen Session-Zustand auf einen zentralen Speicher hinterlegen, damit beim nächsten Aufruf der Session der jetzt an der Reihe stehende Server den Session-Zustand einlesen kann.
Benutzer arbeiten nicht immer durch, es gibt Kundenanrufe, Kollegen, die Hilfe brauchen, die Mittagspause, … Der Zustand einer begonnenen Session muss vom WebServer verwaltet werden, und die vielen „toten“ Sessions belasten den Server. Die „toten“ Sessions werden nach einer Weile „entsorgt“, meist eine Sekunde, bevor der Anwender wieder mit der Anwendung arbeitet.
HTML nutzt http bzw. https als Transportprotokoll. Der Vorteil, die entsprechenden Ports sind in jeder Firewall offen, man muss keinen Antrag bei den Server-Administratoren stellen. Der Nachteil, die entsprechenden Ports sind offen. Bildlich gesprochen, wenn unsere Anwendung ein grosse Veranstaltung wäre und unsere Daten sind die VIPs, müssen sie zusammen mit der Masse der Besucher durch den Haupteingang, damit kein Antrag für die Benutzung des Nebeneingangs gestellt werden muss. Die Sicherheitskäfte der VIPs sind nicht gerade begeistert.
Für die Darstellung der Maske und der Benutzerinteraktion werden Standard-Tools, die WebBrowser, genutzt, dieses klingt erst einmal gut. Mittlerweile sind die WebBrowser weitgehend normiert, so dass die früher üblichen Browser-Weichen nur noch im geringen Mass benötigt werden.
Aber die Browser „gehören“ nicht uns, sondern Microsoft, Mozilla, Apple (Webkit) und Google (Chrome wurde auf Basis von WebKit entwickelt, vor einiger Zeit wollte Google aber die Kontrolle über seinen Fork von Webkit).
Browser werden auch in unsicheren Bereichen des Internets eingesetzt, ein Klick auf einem Links in der Email oder den Suchergebnissen von Google oder Bing, und schon strömt schädlicher Code auf den eigenen Rechner. Dann muss der Browser den Angriff abwehren.
Viele nützliche Eigenschaften des Browsers, die wir für die bessere Benutzerinteraktion verwenden, können auch von den „bösen Jungs“ etwas anders eingesetzt werden, und dann wird der Browser Hersteller die Lücke schliessen, gut so, aber unsere Anwendung läuft nicht mehr.
In HTML ist ein Literal oder ein Eingabefeld ein Literal oder ein Eingabefeld, weitere Zusammenhänge lassen sich zwar über „div“ / „span“ nachbilden, aber nicht in der Detailtiefe, die manchmal notwendig ist. Solange der Browser ausreichend Platz zum Rendern hat, kein Problem, auf einer mobilen Plattform werden die Inhalte zwar dargestellt, aber nicht in der Optik, die ein sinnvolles Arbeiten ermöglicht.
Statt eines WebBrowser sollte ein Generischer Client eingesetzt werden.
Das ist ein Stück Software, das von Unternehmen selber zusammengestellt und gewartet, also kontrolliert wird.
Die Anbindung an der Server kann deshalb entsprechend der Erfordernisse erfolgen, also statt eines http / https mit Load Balancers, Firewall und verschiedenen WebServern wird ein Messaging Server, also ein Asynchroner Transaktionsmonitor direkt vom Client angesprochen.
Der verwendete Port und die Verschlüsselung können selber festgelegt werden und damit wird es einem Angreifer erschwert, einzubrechen.
Die Transaktionsmonitore sind für eine hohe Performance und Verfügbarkeit ausgelegt, sie sind auch die Grundlage für die bekannten kommerziellen Application Server nach J2EE.
Lesende Zugriff (auf unkritische Daten) kann der Client auch direkt auf einer Datenbank durchführen.
Der Generische Client verwaltet seine Session, die Server sind also zustandslos. Falls ein Server ausfällt, kann ein anderer einfach weiterarbeiten. Bricht die Session ab, weil der Computer des Benutzers ein Problem hat, ist nur dieser Benutzer betroffen. Den Server ist die Anzahl der Benutzer egal, es geht nur um Anfrage pro Zeiteinheit. Ob die Anfrage von einem Benutzer oder einem anderen Server-Prozess kommt, bemerkt der Server nicht, es ist für ihn transparent.
Der Generische Client enthält keinen anwendungsspezifischen Code.
Er ist auch mit einem Auto-Update ausgestattet, regelmässig (täglich) fragt diese Basis-Komponente beim Server nach, ob es eine verbesserte Version gibt, lädt und installierte diese bei Bedarf.
Beim Start wird der Client vom Server mit der „Start-Maske“ versorgt, diese wird dargestellt.
Nach einer Aktion des Benutzers sendet der Client die Anfrage (XML) an den Server, dieser antwortet mit einer Nachricht (z.B. in XML).
Im Kopf der Nachricht ist der Name und die Version der jetzt benötigten Maske enthalten, der Client schaut in seinen Cache, ob die Maske dort schon vorhanden ist, falls nicht, wird sie beim Server angefordert.
Die Maske ist auch eine XML-Anwendung, ähnlich XHTML.
Einige Felder werden Auswahl-Felder (Drop-Down) sein, zu denen ein Wertebereich (Geschlecht, Mehrwertsteuer-Schlüssel, Kundensystematik, …), definiert ist. Diese Wertbereiche hat der Client auch unter einem Namen und einer Versionsnummer in seinem Cache gespeichert, beim Laden der Maske wird die Version mit der auf den Server abgeglichen und bei Bedarf ein Update angefordert.
Die Maske sind „Eingabe-Gruppen“, sie bestehen aus Literalen, Eingabe-Feldern und weiteren Eingabe-Gruppen. Diese sind logisch gruppiert sind, also nicht nach Zeile/Spalte.
Eingabe-Felder können eine Picture-Klausel, ähnlich wie in dBase, enthalten. Hierüber kann auch die Bildschirmtastatur auf einem Touch-Screen gesteuert werden.
Jeder Eingabe-Gruppe und jedes Eingabe-Feld hat für die Events (Init, Repaint, Get Focus, Edit, Lost Focus, Destroy, …) ein Standard-Verhalten, das über in der Maske hinterlegten Code (JavaScript) überschrieben werden kann.
Das Verhalten bei „Lost Focus“ kann zur Überprüfung der Benutzereingaben genutzt werden, z.B. kein Geburtsdatum in der Zukunft (Feld-Ebene) oder kein Vertragsbeginn vor der Volljährigkeit (Gruppe, Vergleich Vertragsdatum > Geburtsdatum plus 18 Jahre). Die Methode, die das Standardverhalten überschreibt, kann natürlich auch zuerst das Standardverhalten abfragen, um z.B. vorher den 29.02.2015 als Fehleingabe zu erkennen.
Der Anwender sieht den Arbeitsbereich, dort werden die Eingabe-Gruppen angezeigt und zwei Buttons „Abbrechen“ und „Speichern“. Es kann auch das Button-Paar „Beenden“ und „Ändern“ vorgeschaltet werden.
Falls notwendig kann auch eine Druck-Funktion über einen Button aufgerufen werden. Das Layout des Ausdrucks kann vom Layout auf dem Bildschirm abweichen und als Ausgabemedium bietet sich PDF an.
Der Arbeitsbereich kann in Tabs / Reitern unterteilt werden, dieses ist auf dem Desktop sinnvoll, auf einem mobilen Geräte geht die Übersichtlichkeit verloren.
Auf dem Desktop kann im Generischen Client auch mehrere Sessions angezeigt werden, bei einem 4 Zoll Bildschirm sollte auch hier die Bedienbarkeit geprüft werden.
Der Generische Client muss verschiedene Feldtypen anzeigen können.
Wenn das CAD-Programm weiterhin genutzt wird, braucht sicher nicht dessen Bildschirm in eine Eingabemaske gesteckt werden.
Interaktive Charts (z.B. Wertpapierkurs-Verläufe) können sinnvoll sein, die Bedienelemente sollten aber noch bedienbar sein.
Normale Bilder sind recht einfach zu platzieren, hier sollte eine Maximalgrösse in Bezug auf die zur Verfügung stehende Fläche angegeben werden.
Bei den Eingabefeldern für Tastatureingaben sind in zwei Gruppen einzuteilen, einzeilige und mehrzeilige Felder.
Mehrzeilige Felder sind eher die Ausnahme, hier können Notizen und vielleicht Briefe erfasst werden. Deshalb sollten neben einer reinen Text-Version auch eine Version für formatierte Texte vorhanden sein. Für die Formatierung bietet sich HTML an, es ist aber auch RTF denkbar. Spezielle Formate, z.B. Microsoft Word, sollten nur genutzt werden, wenn es auf allen Platzformen, die auch in ferner Zukunft genutzt werden könnten, zur Verfügung steht.
Bei den einzeiligen Eingabefeldern gibt es Texte, Zahlen mit oder ohne Komma, Datums- und Uhrzeit-Felder, Auswahl-Felder (Drop Down), Boolsche Werte (Radio-Buttons).
Die Anordnung der Eingabe-Gruppen, Literale und Eingabe-Felder sollte nach einfachen Regeln für die jeweilige Plattform erfolgen. Eine Regel, die auf dem Desktop, zum Beispiel Windows, OSX oder Linux, sehr gut ist, kann auf einer mobilen Plattform, Windows, iOS oder Android nicht sinnvoll sein. Beim Layout ist die Bildschirmgrösse wichtig, aber der Eingabe aber auch die Eingabemethode, also Tastatur / Maus gegenüber Touch-Screen.
Bei Auswahlfeldern und Boolschen Werten können je nach Plattform verschiedene Darstellungen und Eingabeverfahren sinnvoll sein. Hier sollte der Designer des Generischen Clients für eine Plattform eine Entscheidung treffen, der Entwickler, der die Maske (also für alle Plattformen) erstellt, sollte sich dessen bewusst sein.
Die Umsetzung des Generischen Clients ist eine sehr überschaubare Aufgabe, wenn nicht die Notwendigkeit der Verfügbarkeit des Know-Hows über eine längere Zeit wäre, könnte es ein Werkstudent umsetzen.