newXYZ: Das "mal ganz andere" Software-Interface für ABC

Veröffentlicht alsEinblick
von Joschi Kuphal am

HINWEIS: Wir haben diesen Artikel nachträglich dahingehend abgeändert, so dass keine Unternehmens- oder Produktnamen mehr darin vorkommen. Wir reagieren damit auf die Bedenken unseres Kunden, durch diesen Artikel könnten Mitbewerber zu viel Einblick in die konzerninternen Prozesse gewinnen. Wir finden jedoch das Projekt weiterhin berichtenswert, weshalb wir uns entschieden haben, dann zumindest eine anonymisierte Version zu veröffentlichen. Bitte wundern Sie sich also nicht über die Unternehmens- / Produktnamen "ABC", "ACME" und "XYZ" – das sind einfach Pseudonyme.

Es war von Anfang an klar, dass dieses Projekt ziemlich aus der Reihe fallen wird, verglichen mit ungefähr allen Projekten, die uns in der letzten Zeit oder jemals bisher beschäftigt haben. Vielleicht war aber auch gerade das der spontane Reiz, dem wir so schnell erlegen waren, als uns die IT-Abteilung der ABC-Konzerns das Projekt im Frühjahr angetragen hat.

Für uns bestand ein wesentlicher Teil der Aufgabe darin, überhaupt zu verstehen, womit wir es eigentlich zu tun haben – vor allem, um uns dann an die vergleichsweise ungewöhnlichen technischen Gegebenheiten und Beschränkungen anpassen zu können. Um die Natur und Besonderheiten des Projekts herausstellen zu können, muss ich auch an dieser Stelle zunächst etwas ausholen.

Als ein weltweit führenden Anbieter bestimmter Elektronikbauteile – vornehmlich für die Automobilindustrie – unterhält der ABC-Konzern etliche Fertigungsstandorte auf der ganzen Welt. Als Logistiksystem kommt unter anderem XYZ zum Einsatz, das bis in die 90er Jahre vom badenwürtembergischen Software-Unternehmen ACME entwickelt wurde. Als ACME die Weiterentwicklung von XYZ (wohl auch angesichts der wachsenden Popularität von SAP) schließlich aufgab, hatte der ABC-Konzern bereits erheblich in die individuelle Anpassung und Erweiterung investiert, so dass ein Abschied von XYZ nicht realistisch schien. ABC erwarb den XYZ-Quellcode samt aller notwendigen Lizenzen, um die Software in eigener Regie weiterzuentwickeln.

In den folgenden Jahren wurden weiterhin konzernspezifische Ergänzungen zu XYZ entwickelt, aber auch der Anwendungskern wurde laufend an neue Anforderungen angepasst, sobald dies notwendig wurde. Im vergangenen Jahr hatten sich schließlich die Rahmenbedingungen soweit verschoben, dass es erstmals unausweichlich schien, einen ganz neuen Hebel anzusetzen ...

XYZ ist eine Terminal-Anwendung

XYZ ist kein Programm, dass auf einzelnen Arbeitsstationen installiert ist, sondern es läuft zentral auf dedizierten Servern, auf die von allen Standorten weltweit aus zugegriffen wird. Dabei kommt die Benutzeroberfläche von XYZ technikbedingt nicht direkt so »schick« daher, wie wir es alle aus unserer täglichen Arbeit mit Windows-, Mac- oder grafischen Linux-Systemen kennen. Der Zugriff auf die XYZ-Server findet über einen sogenannten Terminal Emulator (konkret: Reflection von Attachmate) statt. Das Ganze sieht dann in etwa so aus, wie es selbst manch unbedarftem Windows-Nutzer aus grauen DOS-Urzeiten noch bekannt vorkommen dürfte. Besondere Erwähnung verdient, dass Anwendungen dieser Art regelmäßig nur über die Tastatur zu steuern sind – eine Computermaus ist hier nutzlos.

Vermutlich zählen auch Sie zu den Lesern, denen sofort klar ist, was genau an dieser Programmoberfläche so gar nicht ins Zeitalter von Web 2.0 (oder wieviel auch immer) passen mag ;). Zur Verteidigung der in die Jahre gekommenen, technischen Basis von XYZ muss ich allerdings sagen: Ich kenne keine neuzeitliche und moderne Oberfläche, die auch nur annähernd so effektiv funktioniert, sobald man erst mal die 487 Tastaturkürzel einer solchen Terminal-Anwendung verinnerlicht hat ... Ernsthaft!

Dass »zeitgemäß« jedoch anders geht, war längst auch bei ABC bewusst geworden. Der Schulungsaufwand, der betrieben werden muss, um neuen Mitarbeitern die rein tastaturorientierte Bedienung von XYZ nahe zu bringen, ist enorm. Die Tatsache, dass XYZ ein Terminal-Programm ist, ist der wohl zentralste Aspekt des ganzen Projekts, und ich werde später nochmals darauf zurückkommen.

XYZ spricht nur Deutsch und Englisch

Konkret: XYZ beschränkt sich auf den westlichen Zeichensatz, der zur Darstellung der deutschen Schrift inklusive Umlauten geeignet ist, und bietet daneben keine Unterstützung für sogenannte »Multibyte-Zeichensätze«. Die Programmoberfläche steht nur in Deutsch und Englisch zur Verfügung.

Nun engangiert sich ABC gerade in den letzten Jahren verstärkt in China, so dass inzwischen auch chinesische Mitarbeiter mit XYZ arbeiten müssen. Zusätzlich zum ohnehin immensen Schulungsaufwand entstehen gerade in dieser Region erhebliche Personal-Mehrkosten durch den Umstand, dass Englisch-Kenntnisse für die Bedienung von XYZ unerlässlich sind und somit nur entsprechend qualifiziertes chinesisches Personal in Frage kommt. Die Implementierung einer chinesischen Programmoberfläche ist aufgrund der mangelnden Unterstützung für Multibyte-Zeichensätze seitens der technischen Basis von XYZ ausgeschlossen.

Ein erster Ansatz: XYZ-GUI

Vor dem geschilderten Hintergrund entstand die Idee, eine alternative Nutzeroberfläche für XYZ zu schaffen. Das neue Interface sollte das Sprachproblem lösen und gleichzeitig auch die Lernkurve verbessern, indem es auf einen herkömmlichen Web-Browser als grundsätzliche Anwendungsbasis setzt – und damit auf ein Bedienkonzept, das den meisten Anwendern längst vertraut sein dürfte.

Die größte Herausforderung am Unterfangen, XYZ in den Browser zu bringen, ist die ureigene Natur von XYZ selbst: Neben der Reflection-Oberfläche existiert keine Schnittstellen, die einen (womöglich gar direkten) Zugriff auf die hinterliegenden Datenbanken zulassen oder ermöglichen würde. Die Anpassung des XYZ-Kerns selbst wäre – ebenso wie die komplette Umstellung auf ein anderes ERP-System - mit nicht zu rechtfertigendem Aufwand verbunden. Zur Steuerung des XYZ-Servers führt letztlich kein Weg an der Reflection-Oberfläche vorbei. Der erste Schritt auf dem Weg zum Ziel bestand also darin, einen Adapter zwischen dem Reflection-Interface und dem Web-Browser herzustellen.

Die ABC-IT-Spezialisten meisterten diese Herausforderung durch die Entwicklung einer Middleware auf der Basis von Apache Tomcat und dem javabasierten Web-Framework Apache Tapestry. Bei genauerer Betrachtung leistet diese wirklich Erstaunliches (spätestens jetzt wird es technisch): Die Middleware »simuliert« einen menschlicher Benutzer und arbeitet über eine reguläre Terminal-Sitzung. Die vom XYZ-Server ausgegebenen Bildschirmansichten (jeweils 25 Zeilen à 80 Zeichen, insgesamt also stets 2000 Zeichen / Bytes je Bildschirm) werden unter Zurhilfenahme eines parallel empfangenen »Metadatenstroms« analysiert, in sinnvolle Informationseinheiten zerlegt und schließlich in Java-Objekte übersetzt. Diese werden als Datenquellen genutzt, um in einem Templating-Prozess HTML-Dokumente zu erzeugen, die dann an den Web-Browser ausgeliefert werden. Umgekehrt nimmt die Middleware Formulardaten vom Browser entgegen, transformiert sie zurück zu terminalkompatiblen 80x25-Zeichen-Masken und sendet diese an den XYZ-Server. Die Middleware agiert quasi als »Fernsteuerungs-Adapter« zwischen Web-Browser und Reflection-Interface.

So gut dieser Vermittlungsansatz zwischen Web-Browser und Reflection-Oberfläche grundsätzlich funktioniert, so problematisch bleibt jedoch die enorme Differenz der Funktionsweisen und grundsätzlichen Bedienansätze der beiden:

Für jede aktive Benutzersitzung befindet sich der XYZ-Server bzw. das Reflection-Interface zu jedem Zeitpunkt in genau einem ganz bestimmten Andwendungszustand, der vollständig durch die aktuelle Bildschirmdarstellung beschrieben werden kann.

Die tatsächliche Reichweite dieser simplen Feststellung wird einem erst bei intensiver Beschäftigung mit der Materie deutlich: Was beim Browser als eines der nativsten und generischsten Merkmale ist – nämlich das Scrollen – existiert für den XYZ-Server nicht einmal als Konzept. Um Daten anzuzeigen, die nicht Bestandteil des aktuell sichtbaren 80x25-Zeichen-Bildschirms sind, muss ein anderer Anwendungszustand angenommen werden – doch dann stehen die zuvor betrachteten Inhalte nicht mehr zur Verfügung. Ein einfacher Vergleich verdeutlicht die tatsächliche Komplexität vielleicht:

Stellen sie sich vor, Sie möchten ein Buch lesen, und müssen sich dazu jede Seite einzeln aus der Bibliothek holen. Jedesmal, wenn Sie eine neue Seite erhalten möchten, müssen Sie die vorige zurückgeben und dann das Bibliotheksgebäude verlassen.

So stehen viele, im normalen Web-Kontext absolut übliche Bedientechniken für dieses Projekt einfach nicht zur Verfügung. Wiederum andere Browser-Funktionalitäten, wie etwa der Seitenverlauf samt seiner zugehörigen Zurück- und Vor-Schaltflächen, stellen eine ernsthafte Gefährdung der Synchronizität zwischen Browser- und Reflection-Sitzung dar und müssen »mit Gewalt« blockiert werden. Alles in allem fordert die tatsächliche Ausgestaltung der Browser-Bedienoberfläche ein radikales Umdenken für jeden Web-Designer und -Entwickler und eine Menge »sonderbarer Kreativität«.

Der erste Interface-Ansatz der ABC-IT-Spezialisten wurde unter dem Arbeitstitel XYZ-GUI entwickelt und erreichte im Frühjahr 2012 das Beta-Stadium. Die Umsetzungsmaxime lautete in dieser Phase: Die Reflection-Oberfläche & -Funktionalitäten 1:1 abbilden, inklusive aller Tastaturkürzel, so dass auch »Umsteiger« mühelos mit der neuen Oberfläche zurecht kommen können.

Die Evaluierung machte bald jedoch auch die größten Schwierigkeiten dieses ersten Ansatzes deutlich:

  • Die browserbasierte Oberfläche war – verglichen mit dem Reflection-Interface – nicht besonders performant. Zum Teil ist dieses Problem systemimmanent: Latenz entsteht unter anderem durch die zusätzlichen, unvermeidlich an der Kommunikation zwischen Browser und XYZ-Server beteiligten Zwischeninstanzen. In Kombination mit nicht auf möglichst geringe Übertragungsmengen abgestimmtem Quellcode zeichnete sich zudem ab, dass es gerade in Regionen mit langsamer Internetanbindung zu zusätzlichen Hindernissen kommen würde.
  • Nahezu unmittelbar abgeleitet vom terminalbasierten XYZ erfüllte das Web-Interface nicht die Erwartungen hinsichtlich Benutzerfreundlichkeit und »User Experience«, was der Lust zur Nutzung nicht gerade zuträglich war (zumal ja auch technologiebedingt auf so gut wie alle modernen Browser-Funktionalitäten verzichtet werden musste, die ansatzweise hätten Spaß machen könnten).
  • Schließlich – da es sich bei XYZ-GUI tatsächlich um eine 1:1-Abbildung der Reflection-Oberfläche handelte, mit allen (terminaltypischen) Bedienkonzepten, Tastaturkürzeln usw. – stellte sich die Frage, welchen Fortschritt die neue Oberfläche denn nun wirklich brachte. »Umsteiger« vom terminalbasierten Reflection-XYZ würde es nicht geben, denn die würden allenfalls unter dem vergleichsweise unperformanten webbasierten Interface leiden, und für Neueinsteiger würde sich keine Änderung der Lernkurve ergeben, solange die Bedienung der Browser-Oberfläche identisch mit dem herkömmlichen System war.

Zeit für einen Neustart – mit dediziertem Interface-Design

Im Frühjahr 2012 trat die ABC-IT schließlich mit uns in Verbindung, um uns mit dem Interface-Design für XYZ-GUI zu beauftragen. Zwischenzeitlich hatte intern ein Paradigmenwechsel stattgefunden: Anstatt direkt die Reflection-Oberfläche abzubilden, sollte die browserbasierte Oberfläche ihren eigenen Weg gehen, zuvor als unveränderliche Gegebenheit angenommene Grundlagen hinterfragen und die optimale »User Experience« aus den Möglichkeiten herauskitzeln.

In mehreren Treffen und Workshops wurden zunächst Grundlagen ausgetauscht und wir versuchten, die im Vergleich mit unseren sonstigen Projekten doch deutlich anderen Rahmenbedingungen zu verinnerlichen. Außergewöhnlich bei diesem Projekt ist auch, dass tatsächlich »nur« das Design der Oberfläche unsere offizielle Aufgabe ist. Die Umsetzung – insbesondere auch die Implementierung der Middleware – ist fest in den professionellen Händen der ABC-IT und wird zwischen verschiedenen Standorten in Deutschland – darunter Nürnberg – und Tunesien umgesetzt. Dennoch dürfte die obige Darlegung der Projektnatur verdeutlicht haben, dass dieses Projekt ohne einen engen Schulterschluss mit den Umsetzern und einem fundamentalen Wissen der technischen Zusammenhänge nicht zu erfüllen wäre.

newXYZ – ein letzter Zwischenschritt

Als deutlich wurde, wie tief das Re-Design der neuen XYZ-Oberfläche ansetzen muss, um erfolgreich zu sein, wurden ABC-intern ein letztes Mal die Zielsetzungen für das Projekt leicht geändert: Um möglichst schnell zumindest Linderung für die dringlichsten Probleme zu erreichen, wurde entschieden, zunächst die bereits bestehende Beta-Version von XYZ-GUI fertigzustellen, bevor das »große« Re-Design beginnt. Im Zuge dieser Entscheidung wurde das Projekt zu newXYZ umgetauft.

Für uns ergab sich so ein zusätzliches Interims-Projekt, dessen Thema es war, aus dem funktional fixierten Anwendungsstand an der Oberfläche das bestmögliche Nutzererlebnis herauszuholen. Auch, wenn unser Gestaltungsspielraum dabei nicht gerade üppig war, so konnten durch ein paar Raffinessen doch noch einiges herausholen, wie wir finden.

Nun, nach diesem schier endlosen Vorwort, endlich auch mal ein paar erlösende Bildchen! ;) Da es sich bei newXYZ um ein reines Intranetprojekt handelt, gibt's diesmal keine Live-Version im Netz zu sehen. Am Rande sei noch erwähnt, dass als verbindliche Browser-Plattform konzernweit der Internet Explorer zum Einsatz kommt – wie noch immer in vielen (oder gar den meisten?) großen Unternehmen. Dem geneigten Insider dürfte damit schlagartig klar werden, welcher zusätzliche Teil an potenziell coolen Features allein durch diese unveränderliche Voraussetzung nochmals ausfällt ...

  1. Screenshot des Anmeldebildschirms
    newXYZ-Anmeldebildschirm
  2. Screenshot einer typischen Eingabemaske
    Typische newXYZ-Eingabemaske
  3. Screenshot einer Ergebnisliste
    Ergebnislistendarstellung nach Suchvorgang in newXYZ

Das Ergebnis in Stichpunkten

  • Komplette Quellcode-Umstellung auf HTML5
  • Reduktion der Gesamtdatenmenge pro geladenem Dokument auf durchschnittlich ca. 30% durch betont schlanken Quellcode, optimierte JavaScripts und den Einsatz von CSS-Sprites
  • Intuitive User Experience durch Nutzung etablierter Interface-Techniken wie z.B. »Tabs« anstelle von Dropdowns
  • Innovativer Wechsel zwischen Bildschirmen durch »simuliertes Scrolling« (u.a. auch gekoppelt an Mausrad-Aktionen)

Und wie geht's weiter?

Für uns ist mit dieser Projektphase zunächst »nur« das erste Interimsprojekt rund um XYZ zu Ende gegangen. Den aktuellen Planungen zu Folge soll noch in diesem Winter das »eigentliche« Projekt beginnen: Das Design eines von Grund auf neuen, überarbeiteten browserbasierten Interfaces für XYZ. Bleibt es bei dem bereits eingeschlagenen Weg, so werden dann auch

  • die Entwicklung eines XML-basierten Dialekts zur Notation von Transformationen zwischen Reflection- und HTML-Masken sowie
  • die Entwicklung eines browserbasierten Formular-Editors

zu unseren Aufgaben zählen. Wir freuen uns schon jetzt auf diese neuen Herausforderungen – und das werden sie werden, da haben wir keinen Zweifel.

Wir wollen an dieser Stelle auch keinesfalls verpassen, uns bei unseren Projektpartnern bei ABC zu bedanken! Danke für das wirklich außergewöhnliche Projekt, für das Vertrauen in unsere Fertigkeiten und für die tolle Zusammenarbeit, auch und gerade mit den Entwicklern in Tunesien.