XML » SVG Presenter - Carto:net

XML » SVG PRESENTER | STRUKTURIERTE MULTIMEDIA-PRÄSENTATION IM WEB 188
Abb. 6.6.3.1.2: Modifiziertes, Viewer-natives
Konextmenü
Eine weitere Option könnte hierbei ü-
berdies die Änderung des Icons über ein
zusätzliches GUI-Element darstellen – die
meiner Einschätzung nach sinnvollste
Variante ließe sich etwa in Form eines Selektions-Menüs realisieren, das dem Benutzer wiederum eine Palette
zur Verfügung stehender Bildelemente zur Auswahl
stellt: 1
Abb. 6.6.3.2: Icon-Auswahlmenü (rechts)
ndigsten zu realisierende Komponente
einer derartigen Bearbeitungs-Schnittstelle stellt
n
it noch fehlende Schnittstelle zum Abspeichern dieser Daten als
roblematisch. Zwar bietet die aktuelle Adobe-Implementierung provisorische Linderung durch die (nichtstandardisierte)
postURL-Funktion – wie bereits beim „Overloading“ 2 Die wohl am aufwe
jedoch zweifellos die „Speicherung“ der veränderte
Baumstruktur dar: Obgleich sämtliche Daten durch die
Echtzeit-gesteuerte Manipulation der Präsentationsdaten
in Form einer verschachtelten Objektstruktur bereits
im Arbeitsspeicher als lokale ECMAScript-
Variablen vorliegen, erweist sich eine derze
p
des Viewer-Eigenen Kontextmenüs
[s.Abb.6.6.3.2] besteht hier jedoch ein Konflikt hinsichtlich
allgemeiner Kompatibilität, da auch diese
Funktion
lediglich auf Versionen des Adobe SVG Viewers anwendbar ist. Eine aus längerfristiger Perspektive
interessante Alternative stellt hier die Load-and-Save-Spezifikation der DOM-Arbeitsgruppe dar [vgl.
DOM02], die eine strukturell „Saubere“ Implementierung erlaubt. Da diese Funktionalität jedoch erst Working-Draft-Status
besitzt, wird offensichtlich noch einige Zeit verstreichen müssen, bis diese Schnittstelle
standardisiert und auch in gängigen SVG-Viewern vollständig nutzbar sein wird [s. hierzu auch
Watt02:1042].
Bis dahin ist die Realisierung einer derartigen Speicher-Funktion zwar durchaus technisch
möglich, gestaltet sich jedoch aufgrund
der soeben angesprochenen Problematik derzeit noch recht aufwendig.
Aus diesem Grunde wurde bislang von einer Implementierung
dieser Funktion (und damit auch der
zuvor erläuterten, hen, da entsprechende, „saubere“ Lösungswege erst
liches, arbeitsaufwendiges „Work-Around“ bis zu
3 „trivialen“ GUI-Schnittstellen) abgese
in einiger Zeit verfügbar sein werden und ein umständ
diesem Zeitpunkt nur wenig sinnvoll erscheint.
6.6.1 GUI-Komponente und Bearbeitungs-Komfort
Langfristig jedoch wird an der Realisierung einer Bearbeitungs-Schnittstelle
freilich kein Weg vorbeiführen:
4
Da sich der Presenter ja vorwiegend als Alternative zum augenscheinlich mangelhaften PowerPoint positioniert,
reicht der Bedienkomfort etwa mittels konventioneller XML-Editoren [ShSi99, s.Abb.6.6.1] im Hinblick
auf die technisch und gestalterisch vorwiegend als „unbedarfte“ einzustufende, potentielle Anwenderschaft
[vgl. Scha90, Park01, Pirn01] natürlich bei Weitem nicht aus: Die im Rahmen der Konzeptstudie
1
Die Auswahl externer oder lokaler Bilddateien wäre zwar technisch durchaus möglich, aber sowohl aus ästhetischer Perspektive (der
Nutzer könnte hierbei wiederum unansehnliches Bildmaterial „hochladen“) als auch Umsetzungstechnisch problematisch und zudem
weitaus umständlicher zu realisieren.
2
Mit dem „Überladen“ ist die Modifikation bzw. Ersetzung der ursprünglichen Kontextmenü-Elemente durch Bearbeitungsspezifische
Kommandos des XML » SVG Presenters gemeint.
3
s. Abb. 6.6.2, 6.6.3.1.1, 6.6.3.1.2, 6.6.3.2
4 s. hierzu Kap. 2.3