Die Fehler bei den Fehlermeldungen

Gestern habe ich über die sprachlichen Herausforderungen geschrieben, die sich bei Texten über Tech-Themen oft stellen. Die gleichen Ursachen führen dazu, dass sich unsere Artikel oft sehr schwer bebildern lassen. Abstrakte Konzepte werden typischerweise in Symbolbildern ausgedrückt, die manchmal passen. Oft passen sie nicht, häufig sind sie ausgelutscht.

051003-fehlermeldung.jpg
Etwas schöner ausschneiden hätte man die auf Papier ausgedruckte Fehlermeldung ja können…

Beim Tagi unterstützt uns die Bildredaktion heute nach Kräften. Früher mussten wir uns oft selbst behelfen. So ist auch obiges Foto entstanden. Es wurde gewissermassen aus der Not geboren, um den Artikel «Tipps zur Absturzbekämpfung» vom 3. Oktober 2005 zu illustrieren. Auf dieses Meisterwerk bin ich noch heute stolz. Ich habe mich selbst mit der Nikon D70s geknipst, während ich eine vorher ausgedruckte Fehlermeldung vom Bildschirm entfernt habe. Beim Tipp ging es, natürlich, um die Frage, wie man Fehlermeldungen vom Bildschirm bekommt.

Fehlermeldungen – im Lexikon sollte neben dem Begriff «notwendiges Übel» obige Fehlermeldung abgebildet sein. Notwendig sind die Fehlermeldungen, weil Perfektion bei der Software ein unerreichbarer Wunschtraum bleibt. Die Entwickler sind so fehlbar wie wir alle. Und selbst wenn sie perfekten Code liefern würden, dann könnten problematische Rahmenbedingungen weiterhin die Programmausführung zum Stocken bringen. Was nun aber die Fehlermeldungen angeht, sind die alles andere als perfekt. Im Lauf der Jahre habe ich folgende Problembereiche isoliert:

Die Fehlermeldungen sind falsch, nichtssagend oder sogar irreführend.
Softwarehersteller machen es sich sehr oft einfach. Statt im Code jede einzelne Ausnahmesituation abzufangen, bauen Sie «Catch-all»-Exceptions,die diverse Ursachen haben können. Entsprechend vage sind dann die Beschreibungen, in denen von Ausnahme- oder Ausführungsfehlern die Rede ist. Oft fehlt eine Ursachenangabe, und es kommt auch vor, dass die angegebene Ursache falsch ist.

Ein Paradebeispiel ist die oben abgebildete Meldung. «Catastrophic failure» ist übertrieben. Es gab einen Absturz des Windows Media Players, was weiss Gott keine Seltenheit ist. Angemessen wäre diese Fehlermeldung, wenn das CD-Laufwerk beim Einzug den Finger des Nutzers abgetrennt hätte. Oder wenn sich das Modem bei einem russischen Atomkraftwerk eingeloggt und eine Kernschmelze ausgelöst hätte. Oder wenn der Browser auf die Idee gekommen wäre, in Eigenregie auf Facebook Pro-Pegida-Parolen zu posten.

Andererseits gibt die Meldung keinerlei Hinweis auf die Ursache oder die Art des Problems. Immerhin: Der Hex-Fehlercode bietet eine gute Recherchemöglichkeit. Codes sind ideal, weil sie bei Suchmaschinen- oder Wissensdatenbank-Recherchen sprachunabhängig Resultate liefern. Bei ausformulierten Meldungen muss man bei deutschen Softwareprodukten oft erst den englischen Wortlaut in Erfahrung bringen, weil die Quellen ergiebiger sind.

Von einer guten Fehlerangabe erwarte ich einen Fehlercode, eine Beschreibung, plus einen Link auf weiterführende Informationen.

150212-fehler01.png
Wtf?

Fehlermeldungen sind weg, bevor man sie zur Kenntnis genommen hat.
Das liegt natürlich daran, dass wir User schneller klicken als lesen. Es liegt aber oft auch daran, dass uns erst nach und nach klar wird, dass wir der schnell weggeklickten Meldung unsere Aufmerksamkeit hätten schenken müssen. Es braucht daher eine Möglichkeit, Fehlermeldungen nachträglich einzusehen – am besten über eine Benachrichtigungs-Historie oder ähnlich. Bei Windows gibt es die Ereignisanzeige (siehe Wie Windows sich nonstop selbst auf die Finger schaut). Das wäre eine gute Idee, wenn sich die Ereignisanzeige nicht nur an Administratoren, sondern auch an die normalen Nutzer wenden würde. So ist nutzt sie faktisch nichts, weil die meisten Nutzer sie nicht kennen und weil so viele Ereignisse geloggt werden, dass die relevanten kaum aufzufinden sind.

Das Wartungscenter könnte ein guter Ersatz sein. Meine Erfahrung ist jedoch, dass wirklich nützliche Informationen im Wartungscenter die Ausnahme und nicht die Regel sind. Beim Mac ist die Konsole auch nicht gerade der Inbegriff an Benutzerfreundlichkeit.

Fehlermeldungen brauchen einen klaren Urheber.
Man mag es kaum glauben, aber es ist tatsächlich so: Bei Windows sieht man recht häufig Fehlermeldungen, die sich noch nicht einmal einem Programm zuordnen lassen. Das ist vor allem beim Start der Fall: Da werden Treiber und Dienste geladen, Systemstartobjekte ausgeführt und über idiotische Mechanismen wie RunDLL und Svchost in Betrieb gesetzt. Wenn dabei etwas schief geht – und obwohl man sich das bei Microsoft anscheinend nicht vorstellen kann, geht dabei oft etwas schief – kommen so verquere Meldungen heraus, aus denen selbst erfahrene Windows-Anwender nicht schlau werden.

Mein Highlight: Meldungen, bei denen Pfad und Dateiname der betroffenen Datei aus Platzgründen abgeschnitten sind oder die Systemkomponenten aufführen, von denen der normale Anwender noch nie gehört hat. (Und nicht gehört haben muss, weil die fraglichen Komponenten nicht auf eine direkte User-Interaktion ausgelegt sind.

150212-fehler02.jpg
Perfect Zip mit einem Anflug von Sarkasmus.

Der Fehlerfall muss bei der Softwareentwicklung systematisch berücksichtigt werden.
Das ist das grösste Problem überhaupt, wie man bei Windows und bei Microsoft-Produkten häufig sieht. Microsoft baut Software selten aus einem Guss, sondern setzt lieber auf Frameworks und Schnittstellen. Alles wird in Komponenten zerlegt und über APIs genutzt. Das klingt in der Theorie wunderbar, weil Programme nicht isoliert werkeln, sondern interagieren und im Ganzen zu mehr als der Summe der Einzelteile werden.

In der Praxis ist diese Softwarearchitektur eine Quelle von unendlichen, schwer zu behebenden Problemen. Einige Beispiele:

  • Die Systembibliotheken (DLLs). Die Idee ist, Funktionen in Bibliotheken auszulagern, die dann von allen Programmen benutzt werden können. Die Probleme sind fehlende Bibliotheken, Versionskonflikte (DLL hell), DLL-Hijacking und schlechte Wartbarkeit der Programminstallationen.
  • .Net-Framework. Das soll plattformübergreifend internetaffine Anwendungen ermöglichen1. Unter Windows treten häufig Update- und Versionskonflikte auf. Für die Kummerbox habe ich unzählige Male die Anleitung verschickt, wie man Probleme mit Service Packs fürs .Net-Framework behebt – die sind sehr umfangreich, kompliziert und betreffen auch Leute, die noch nicht einmal .Net-Anwendungen einsetzen.
  • Messaging Application Programming Interface (Mapi). Dank dieser Schnittstelle kann man direkt aus Word oder aus anderen Programmen heraus Mails versenden. Oder auch nicht, denn Mapi macht häufig Ärger. Ältere und neuere Programmversionen harmonieren schlecht.
  • Add-ins, Add-Ons, Plug-Ins, Browserhilfsobjekte, Shell-Extensions und was es da auf Anwendungs- und Betriebssystemebene sonst noch gibt. Offenheit ist grundsätzlich zwar zu begrüssen, geht aber in der Praxis zu oft auf Kosten der Stabilität. Erweiterungen dürfen daher nie ohne Zustimmung des Benutzers installiert werden (was bei Windows gang und gäbe ist). Sie müssen jederzeit widerstandsfrei und rückstandslos entfernt werden können (was bei Windows nicht der Fall ist). Und sie müssen sollten so weit gekapselt ausgeführt werden, dass sie im Problemfall das Hauptprogramm nicht tangieren oder wenigstens leicht als Fehlerquelle identifiziert werden können.
  • ActiveX. Microsofts Softwarekomponentenmodell, mit dem sich Windows-Code im Browser ausführen liess. Dass eine solche Funktion nicht nur von wohlmeinenden Leuten benutzt werden würde, sondern auch von Cyberkriminellen, konnte sich Microsoft nicht vorstellen. In der Folge hat sich ActiveX zu einer einzigen gigantischen Sicherheitslücke entwickelt.

Wie ActiveX beweist, werden diese immer für den Betrieb unter Idealbedingungen entwickelt. Dem Missbrauchsfall wird während der Entwicklung keine Rechnung getragen und selbst die Auswirkungen mangelnder Qualität von Einzelkomponenten aufs ganze System nicht bedacht. Dabei müsste es umgekehrt sein. Solche Systeme müssen konsequent so gebaut werden, dass der Ausfall einzelner Komponenten verkraftbar sind. Und für den Nutzer sofort klar wird, welche Komponente versagt hat. Dann erhält der User seine Handlungsfreiheit zurück und kann entscheiden, was er tut: Aktualisieren, deinstallieren oder den Hersteller auf Schadenersatz verklagen. (Oder wenigstens jemanden an der Support-Hotline zusammenscheissen…)

150212-fehler03.jpg
Ein Outlook-Klassiker. Die richtige Übersetzung lautet: «Go fuck yourself.»

Footnotes

  1. Bill Gates hat seinerzeit .Net persönlich in der Schweiz vorgestellt. Am 11. Februar 2002 berichtete ich wie folgt im Tagesanzeiger. Die Quintessenz nehme ich schon mal vorneweg: Aus heutiger Sicht ist diese Beurteilung zu optimistisch. Die von Gates aufgeführten Beispiele haben wir nicht von Microsoft gesehen. Wir nutzen keine Desktop-Anwendungen mit Anbindung ans Web, sondern lieber gleich Smartphone- und Webapps. Serverseitig hat sich die Internetwelt für offene Systeme entschieden. .Net ist heute zwar Open-Source und läuft auch auf Linux, doch wegweisend wäre dieser Entscheid gewesen, wenn er 12 Jahre früher gefallen wäre.

    Microsoft plant die Zukunft
    Je vernetzter die Computerwelt, desto nebensächlicher das Betriebssystem: Microsoft rüstet sich für die Nach-Windows-Ära.
    Bill Gates persönlich trat letzten Dienstag in Zürich-Oerlikon vor die Schweizer Softwareentwickler, um die hiesige Programmierergemeinschaft auf eine neue Ära einzustimmen, die – wenn es nach Microsoft geht – mit .Net (sprich «Dot Net»; ursprünglich NGWS, d. h. «Next Generation Windows Services») bereits begonnen hat. Windows wird nicht ewig Paradepferd und Milchkuh bleiben. Das PC-Betriebssystem ist an einem Punkt angelangt, bei dem die Entwicklungsmöglichkeiten absehbar sind und kosmetische Korrekturen an der Desktop-Oberfläche je länger, je weniger teure Updates rechtfertigen.

    Mit der .Net-Strategie will Microsoft sich seine Vormachtstellung auch auf längere Frist sichern. Die Vision «The net is the computer» stammt zwar von Suns CEO Scott McNealy, aber es wäre nicht das erste Mal, dass Microsoft fremder Leute Geistesblitze zum Erfolg führt. .Net bringt ein Framework, d. h. eine technische Infrastruktur, mit der Software auf die Bedürfnisse und Möglichkeiten einer vernetzten Umgebung zugeschnitten werden kann. Aufsetzend auf diesem Framework können selbst einfache Anwendungen Funktionen nutzen, die bis jetzt nur proprietären Systemen oder überhaupt nicht zur Verfügung standen.

    .Net-Anwendungen haben weit reichende kommunikative Fähigkeiten und sollen gewährleisten, was als «Interoperabilität» ein zentrales Anliegen der Internetbranche ist. Dieses Kunstwort bezeichnet die Zusammenarbeit unterschiedlicher Systeme über eine genormte Sprache. Die Rolle als Lingua franca wird XML einnehmen. Die vom World Wide Web Consortium 1998 verabschiedete «eXtensible Markup Language» ist rundherum unbestrittener Standard für den Austausch von Datenobjekten zwischen verteilten Anwendungen.

    Gemeinsame Sprache für alle Systeme
    Wenn die nicht nur einfache, sondern laut Microsoft auch sichere Datenkommunikation zu den Kernkompetenzen einer Software gehört, spielt es keine Rolle, wo im Netz sie ausgeführt wird. Anwendungen können dezentral arbeiten und sind nicht an einen Server gebunden. Folgerichtig sind auch Client-to-Client-Dienste wie Musiktauschbörsen à la Napster mit dieser Architektur zu realisieren. Zugleich erwächst auch die zweite grosse Stärke von .Net aus der Möglichkeit der verteilten Anwendungen: Aufgaben lassen sich viel leichter als bisher auf mehrere Maschinen verteilen.

    Dieses «Clustering» genannte Verfahren gestattet den Einsatz relativ billiger Server, denn ist die Leistungsgrenze der Hardware erreicht, wird der Verbund durch einen weiteren Rechner verstärkt. Das Gesamtsystem gilt als «skalierbar». Auch die beiden anderen zentralen Anforderungen, welche Betreiber zu Recht an ihre Infrastruktur stellen, gelten bei Rechner-Cluster als erfüllt: die hohe Verfügbarkeit und die Fehlertoleranz.

    Dem Anwender – und dazu zählt Bill Gates nicht nur die Windows-Nutzer, sondern auch Besitzer smarter Telefone und PDA-Anwender – sollen durch .Net nicht mehr nur Internetseiten über «dumme Browser» sichten, sondern «reichhaltige Webdienste» in Anspruch nehmen jederzeit, an jedem Ort und auf jedem Gerät. .Net soll in der Vision von Bill Gates Informationen aus verschiedenen Quellen zusammenführen und daraus intelligente Dienstleistungen aus einem Guss schustern. Der deutsche TecChannel hält das folgende, orwellsch anmutende Beispiel für realistisch, bei der ein Tourist in einer fremden Stadt punkt zwanzig Uhr folgendes Angebot per Handy-Kurznachricht erhält: «Fünfzig Meter von hier ist ein italienisches Restaurant. Die Tagesspezialität ist Lasagne al forno. Soll ich Ihnen einen Tisch reservieren?»

    Gemischter Datensalat
    Der Web-Dienst konsultierte die Online-Agenda und stellte fest, dass der Tourist vermutlich Hunger, aber keine Termine hat, brachte beim Mobilfunkdienstleister dessen aktuellen Standort in Erfahrung, glich die programmierten kulinarischen Vorlieben mit den Tageskarten der Restaurants in der Umgebung ab und ermittelte so einen treffsicheren Menüvorschlag.

    Ganz so ausgeklügelt sind die ersten .Net-Dienste noch nicht, aber sie zeigen die Stossrichtung. Bei einer Lösung, die Microsoft mit Fleurop Schweiz realisierte, werden die in Microsofts Passport-Kalender gespeicherten Geburts- und Hochzeitstagdaten mit dem Angebot des Online-Blumenhändlers kombiniert, sodass sich der Benützer nicht mehr um ein Geschenk bemühen muss, sondern im Ereignisfall aufgefordert wird, die geeignete Schenkaktion in die Wege zu leiten.

    Die vielen Facetten der .Net-Strategie werden erst nach und nach konkreter werden. In Bill Gates’ Zeitplan werden dieses Jahr erst einige grosse Unternehmen auf .Net einschwenken, während der Umstieg der KMUs in drei Jahren einsetzen dürfte. Demnächst verfügbar ist das Entwicklungswerkzeug für .Net «Visual Studio.NET», das an der Developers Conference in Zürich einen guten Eindruck hinterliess.

    Wilde Entschlossenheit in Redmond
    Es ist klar: Microsoft ist es ernst, die Schlüsselstelle zu besetzen, um die sich im intelligenteren und dynamischeren Internet der Zukunft alles drehen wird. Microsoft beteuert, auf offene Standards und bekannte Protokolle setzen zu wollen und .Net nicht auf die Windows-Plattform zu beschränken. Doch Skeptiker werten dies als Versuch, den Einflussbereich auszudehnen und auch auf Linux- oder Unix-basierten Computersystemen eine entscheidende Rolle zu besetzen. .Net ist zudem eine offene Kampfansage an Sun und deren Konkurrenzarchitektur ONE («Open Net Environment»). Die Scharmüzel sind in vollem Gang; was der Beobachter daran erkennt, dass eine Windows-XP-Box kein Sun Java mehr enthält. Vergrössert werden die Bedenken, da Microsoft nicht nur die Technologie, sondern auch eine ganze Reihe von Diensten selber anbieten will. Die «.Net My Services» (auch bekannt unter dem Codenamen «Hailstorm») enthalten unter anderem eine Kalender-, Alarm- oder Buchzeichen-Funktion. Alle 15 Dienste können in weiteren Websites oder in Desktopanwendungen genutzt werden. Die Dienste versammeln eine Fülle von Informationen, über die Microsoft allein gebietet.

    Nachdem Bill Gates gesprochen hat, muss Microsoft Taten folgen lassen. Gelingt der Beweis, dass .Net eine solide Grundlage für funktionierende UMTS-Anwendungen liefert, dann werden die Investoren auf .Net setzen und die Anwender ebenso. Misstrauen und Microsoft-Antipathie hin oder her.

    ^top

Autor: Matthias

Diese Website gibt es seit 1999. Gebloggt wird hier seit 2007.

Kommentar verfassen