Bewegung mit Zuschauer

Moderne Strategien der Fortschrittsbalkentechnologie

Für den Anwender hat sich seit Jenkins' Durchbruch im Jahre 1979 wenig geändert: wenn ein Prozess dargestellt wird, der zwar nicht auf dem Bildschirm nach zu verfolgen ist, dessen Ablauf für den Anwender aber als zu langwierig erscheinen könnte, erscheint ein kleiner Balken, der sich allmählich von links nach rechts füllt.

Schon 1972 hatte Jenkins dieses Bild vor Augen, als er seinen ersten Entwurf mit der Schreibmaschine realisierte (wir berichteten). Dieser Entwurf enthält in groben Zügen bereits alles, was auch den modernen Balken ausmacht: Seitenbegrenzungen links und rechts, dazwischen ein Zwischenraum, der in Einzelschritten aufgefüllt werden kann. Der Fortschritt berechnet sich - wie heute noch - aus dem Quotienten aus den tatsächlich ausgefüllten und den im Ganzen auffüllbaren Schritten. Im Falle dieses ersten Entwurfs sind von fünf möglichen Ausfüllflächen vier ausgefüllt (mit einem "x"): der Fortschrittsbalken steht also bei 4/5*100 = 80%.

Jenkins' jahrelange Studien gipfelten schließlich 1979 in der Entwicklung des bewegten Fortschrittsbalkens, der sich von links nach rechts füllt (wir berichteten), und der für uns heute den Normalfall dieser für die Computergeschichte epochemachenden Erfindung darstellt. Die Wirkung seiner ersten, noch in Algol programmierten und seinerzeit auf den größten Rechenanlagen der Michigan State University (MSU) implementierten Routine, können Sie auf dem kleinen, nachgestellten Bild rechts nachvollziehen. Es handelt sich hier jedoch nicht um die vom Washington Museum of Computer History zurückgehaltene Originalimplementierung, sondern um eine von Studenten der Technischen Universität Berlin unter der Leitung von Prof. Ken Warten nachgebaute Version, die auf modernen Computern lauffähig ist.

Als die Weiterentwicklung des Fortschrittsbalkens 1982 von der US-Computerindustrie übernommen wurde, kam es zu unzähligen Abwandlungen und Modifikationen, von denen hier nur einige vorgestellt werden können.

Bereits 1984 entwickelte die Association for Humble Software Movement einen Standard für Fortschrittsbalken, bei denen der Übergang von einem Balkenglied zum anderen auf je mindestens 14 Sekunden beschränkt war, um langsame Prozessoren nicht zu sehr zu benachteiligen und einer Monopolisierung des Prozessormarktes vorzubeugen. Dieser Standard wurde bereits ein Jahr später von der United Sinister Processor Industries Association USPI durchbrochen, die Fortschrittsbalken ohne Geschwindigkeitsbeschränkung durchsetzte. Von nun an waren der Weiterentwicklung von Jenkins' genialer Erfindung keine Schranken mehr gesetzt.

N. Durance von Scrolling Systems Inc. entwickelte 1987 einen Balken, dessen Fortschrittsglieder im Zwei-Sekunden-Abstand aufeinander folgten (Abb. rechts), sein Vetter Curth konnte dieser Variante gar zu einer solchen Geschwindigkeit verhelfen, dass die Bewegung mit bloßem Auge nicht mehr nachvollziehbar war. Erst 1989 konnten zwei Forschergruppen in Berkeley und am MIT in Cambridge unabhängig voneinander nachweisen, dass in diesem praktisch unsichtbaren Balken tatsächlich eine Bewegung von links nach rechts stattfand. Trotz dieses enormen Geschwindigkeitsgewinns konnte sich diese Variante bis heute nicht auf dem Markt durchsetzen.

Heute finden sich, vornehmlich als Teil unterschiedlicher Installationsroutinen, insbesondere zwei Bewegungsarten:

Die reale Variante ("R-Bar")

Die Bewegung des Balkens entspricht tatsächlich grob dem Ablauf des Installationsprogramms. Wegen kleinerer Unwägbarkeiten kommt es jedoch beim R-Bar vor, dass der Balken zwischen 90% und 99% stockt und eine ganze Weile lang (ca. 6-14 min.) stecken bleibt, bis er zum Schluss kommt. Untersuchungen zufolge haben viele Menschen jedoch bis dahin die Geduld verloren und die Installation bereits abgebrochen.

Die realistische Variante ("R2-Bar")

Das Installationsprogramm läuft unabhängig vom Fortschrittsbalken ab. Erst wenn das Programm abgelaufen ist, startet der Balken seine allmähliche, verzögerte Bewegung. Der Gesamtablauf wird dadurch zwar etwas länger, diese Variante wirkt jedoch viel realistischer und ungezwungener als die erste und weist keine Verzögerung innerhalb der letzten zehn Prozent auf. Der R2-Bar hat sich inzwischen bei fast allen Programmen durchgesetzt. Nicht nur bei Installationsprogrammen, auch beim Hoch- und Herunterfahren von Betriebssystemen konnte er sich mittlerweile bewähren.

Fortschritt ohne Absturzgefahr

Eine letzte Variante soll nicht unerwähnt bleiben: der von der Organization for Downslowing and Upspeeding Hermeneutics ODUH vorgeschlagene "R3-Bar". Wegen der nachweislich hohen Absturzgefahr unmittelbar nach dem Starten eines Programms soll der Fortschrittsbalken erst eingeblendet werden, wenn die Installation beendet ist und die Anwendung bereits vom Anwender im Verlauf mehrerer Monate wiederholt verwendet wurde. Hierdurch soll sichergestellt werden, dass es während der Einblendungszeit des Fortschrittsbalkens nicht zu Verzögerungen kommen kann. Wenn die Anwendung nach vier bis fünf Monaten Nutzungsdauer in den Arbeitsalltag des Anwenders eingegangen ist, sei eine Verzögerung des Fortschritts - so die ODUH - statistisch so unwahrscheinlich, dass die Balkenbewegung mit höchster Wahrscheinlichkeit kontinuierlich ("smooth") ablaufen kann. Diese Variante hat bislang lediglich RFC-Status (Request for Comments), es steht jedoch zu erwarten, dass sie in nächster Zeit von der Softwareindustrie mit großer Mehrheit angenommen wird.

[Eine Metapher des Fortschritts]