Hallo Tim,
a) Die Einzeladressen dieser Happen vollkommen aus dem Rest des Webs raushalten. Oder diese verbergen, z.B. mit Frames. (...) Hat aber immer noch den Nachteil, daß die Ressourcen trotz allem adressierbar sind.
b) Die Logik hinter der Adresse verbergen.
c) Alles auf einer Seite, aber dafür dynamisch.
Ich verstehe nicht ganz, wozu dieser Aufwand nötig ist. Im Grunde genommen wird eine Technik eines Medium verwendet, die für solche Anwendungen zwar geeignet scheint, aber zahlreiche Probleme auftreten, weil sich die Grundlagen des Datenformats HTML und das dahinterstehende Web-Modell nicht abschütteln lassen. Ich kann mir nicht die Aspekte von HTML heraussuchen, die mir gefallen, diese gebrauchen und gegebenenfalls kreativ zweckentfremden, auf diesen aufbauen und die restlichen vergessen, wenn es gerade diejenigen sind, die gesamte Medium WWW prägen bzw. in seinen Grundkonzepten ausmachen. Das bedeutet, HTML zu benutzen, wenn gar nicht HTML als HTML gewünscht ist, verhindert nicht, dass es als HTML im Kontext des Web-Modells auftaucht (Adressierbarkeit als Einzelknoten, Verarbeitung als »Markup« bzw. ausgezeichneter Text durch Suchmaschinen/Nur-HTML-Browsern usw.). Es muss damit gerechnet werden, dass an das Dokument die Ansprüche gestellt werden, die an »klassische« HTML-Dokumente gestellt werden. Dagegen kann der Autor nichts Grundlegendes machen, insofern sind Konflikte vorprogrammiert. Noch mehr Technik zur Verschleierung und konsequenten Verfremdung (Frames, Cookies, Sessions, Direktverlinkungs-Sperren, ein Dokument als Container für wechselnde DHTML-Inhalte) einzusetzen, täuscht letztlich nur darüber hinweg, dass die beiden Dokument-, Site- bzw. Netzmodelle grundlegend inkompatibel sind. Letztlich dienen diese Methoden dazu, die Modelle voneinander zu trennen, anstatt sie ineinander zu überführen.
In </archiv/2003/10/60063/#m337845> sprach ich von zweischneidigen Kausalzusammenhänge, die man sich zu Nutze machen kann. Zum Beispiel: Die Orientierung am klassischen, letztlich auf Markup und Text reduzierbaren Dokumentmodell garantiert Funktionalität in vielen Zugangskontexten, bedeutet aber auch gleichzeitig eine oft unpassende Beschränkung und Reduzierung. Die entgegengesetzte Beziehung verspricht entsprechende Freiheit und mehr Möglichkeiten, dann muss ich aber auf die Vorteile verzichten, die das klassische Modell bzw. Konzept hat. Damit will ich sagen, dass es zwangsläufig kompliziert und letztlich aussichtslos wird, wenn ich mir *beide* in vielen Punkten unvereinbaren Zusammenhänge zu Nutze machen will.
d) Noch dynamischer! Und zwar Flash, eventuell mit dynamisch nachgeladenen Inhalt.
Das ist meiner Meinung nach die sinnvollste Methode, weil das Format Flash für solche Anwendungen prädestiniert ist. Wenn eine zwingende Sequenz vorliegt, von der die einzelnen Stati nicht adressierbar sein sollen, dann kann ich sie nicht als mehr oder weniger autonome Ressourcen ins Netz stellen und mich dann wundern, dass sie adressierbar sind, dass Menschen deeplinken und Suchmaschinen die Menschen mittendrin in der Sequenz absetzen.
Hätte den Vorteil, daß der Autor des Gesamtkunstwerkes sich noch mehr gestalterisch ausleben bzw. betätigen kann. Hätte eventuell den Nachteil, daß sich die Zielgruppe verringert. Wobei ich das bezweifele, ob die Gruppe derjenigen ohne Flash wirklich zur Zielgruppe des Gesamtkunstwerkes gehört.
Denke ich ebenso, vor allem wären ja auch Probleme wie mangelnde DHTML-Fähigkeiten der Browser gegessen. Schade nur, dass es keine praktisch ebenbürtigen offenen Formate und entsprechende kostenlose Autorenprogramme gibt.
In [pref:t=73703&m=425206] hatte ich bereits schon einiges gesagt.
Mathias