XML » SVG Presenter - Carto:net

XML » SVG PRESENTER | STRUKTURIERTE MULTIMEDIA-PRÄSENTATION IM WEB 71
Bei einer Aktualisierungsgeschwindigkeit von ungefähr 1% pro Woche dauert es etwa ein Jahr, bis die
Mehrheit der Nutzer auf die Möglichkeiten der von ihnen eingesetzten […] Technologie zugreifen kann –
und gar zwei Jahre, bevor jeder diese Technologie hat.
[Niel00b:34]
3.5.4.1 Plug-In-Problematik
3.5.4.1.1 Unzählige Problembereiche
Neben der im Zuge der Plug-In-Diskussion noch hinzukommenden Problematik, dass aufgrund der speziellen
Browser- Schnittstelle für jedes Betriebssystem ein separates Plug-In zu entwickeln ist, erschwert überdies
die Tatsache, dass die von Netscape entwickelte „Plug-In-API“ keinen offenen Standard, sondern
ein auf den Communicator gemünztes Programmmodul darstellt [vgl. Blei96:68], die Entwicklung allgemeingültiger
Plug-In-Komponenten, da somit auch die Kompatibilität mit anderen Browsern keinesfalls
gewährleistet ist. Da überdies auch der Internet-Nutzer „nur selten willens ist, sich ein entsprechendes Plug-
In herunterzuladen“ [Star01:1] erscheint „der Einsatz von Techniken, die zusätzliche Plug-Ins verwenden,
ohnehin fragwürdig.“ [Rieh01:68].
Vor der Verwendung sollte überprüft werden, wie verbreitet die betreffenden Plug-Ins bei den Nutzern
sind, um nicht zu viele potentielle Nutzer auszuschließen. Daher sind derartige Technologien in der Regel
erst dann zu verwenden, wenn sie sich als Standard durchgesetzt haben, d.h. eine längere Zeit auf dem
Markt erprobt sind.
[Niel01]
3.5.4.1.2 Vollständige Abdeckung: Praktisch unmöglich
Aufgrund dieser Erkenntnis überrascht es daher nur wenig, dass es keinem der soeben genannten Multimedia-Tools
schließlich gelang, eine ausreichende Verbreitung des jeweiligen Plug-Ins zu erreichen. Aufgrund
der diese Problematik noch verschärfenden Stagnation des CD-ROM-basierten Offline-Marktes versank ein
Grossteil der noch Anfang der 90er Jahre boomenden Authoring-Softwares rasch in Bedeutungslosigkeit
oder konzentrierte sich, wie etwa Asymetrix’ Toolbook, auf kleinere Marktnischen wie Internet-Lernsoftware
[vgl. Musi02]. Das positive Beispiel HyperCards, das schließlich dennoch aufgrund schwindender Unterstützung
von Seiten des Mutterkonzerns 1 die Waffen strecken musste, 2 macht dennoch zugleich die eigentliche
Redundanz der entsprechenden Plug-In-Abhängigkeit deutlich: Da sämtliche, oben genannten Multimedia-Lösungen
ebenso wie das HTML zugrunde liegende Strukturprinzip auf einer recht statischen Hypertext-Architektur
nach dem Dexter-Modell 3 [vgl. HaSc94] basieren, ist, wie etwa die rein Server-seitige
Lösung LiveCard [Roya96] deutlich macht, eine relativ exakte, aber dennoch dem Hypertext-Prinzip vollends
entsprechende Überführung prinzipiell durchaus „sauber“ möglich. Daher erscheint es auch im Hinblick
auf die Kompatibilitätsbezogenen Vorzüge einer möglichen Server-Lösung mitunter nahezu unverständlich,
warum dennoch größtenteils auf den (wie soeben diskutiert) „problematischen“ 4
Plug-In-Ansatz
zurückgegriffen und somit zumindest in Teilen zum Scheitern dieses (wie in [2.1] beleuchtet, strukturell
durchaus überzeugenden) so genannten Frame-based Paradigmas [vgl. Bole98] beigetragen wurde.
3.5.4.1.3 Sinnvolle Plug-In-Verwendung
Weitaus plausibler erscheint dagegen die Plug-In-Notwendigkeit des dem HTML-Prinzip grundsätzlich eher
entgegenstehenden Modells des „Timeline-basierten“ Authoring-Paradigmas [vgl. Bole98], dessen Animations-Basiertheit
eine direkte Konvertierung an dieser Stelle freilich unmöglich macht. Da ebendieses Grund-
1 vgl. hierzu Jim Stephensons abschließenden Kommentar zu dessen „HyperCard Heaven“-Projekt vom 17. November 2001:
http://members.aol.com/hcheaven/inactive.html [3.2.03]
2 s. 2.1
3 s. hierzu ebenda.
4 vgl. hierzu auch [Depe02] pp.19ff.