Gesamtkunstwerke - ein moderater Vorschlag

[Tim Tepaße]

Hallo,

weiter unten im Forum ([pref:t=73703&m=424510]) tobt gerade eine erbitterte
Diskussion um das Thema Deep Linking. So erbittert, daß ich dort mit meinen
abstrakten Gedanken nicht teilnehmen möchte, da die Wahrscheinlichkeit
groß ist, von den üblichen »Praktikern« im Kreuzfeuer einen auf den Deckel
zu kriegen.

Es stehen hier zwei Modelle gegeneinander. Zum einen das, was ich mal
als das Web-Modell bezeichnen möchte. Dies deswegen, weil dieses Modell
das ist, was wir mit dem WWW haben und anscheinend auch das ist, das
TBL damals im Sinn gehabt zu haben scheint.

In Kürze: Es gibt Resourcen (Webseiten, Telefonnummern, Toaster), die durch
URLs (Oder URIs. Oder IRIs) adressierbar sind, damit man etwas damit tun
kann. Es gibt keine Restriktionen, irgendeine URI zu benutzen, es sei
denn, die URI und ihr Protokoll geben so etwas vor (HTTP Authentifikation).

Und dank HTML können bequem Verweise auf jede beliebige URI gesetzt werden,
mit denen man diese Resource aufrufen kann. So weit, so abstrakt, so gut.
Das sorgt dann natürlich für eine chaotische Struktur. Hypertext. Oder
Hyperinhalte, wenn man so will.
   ___                  ___
  |   | -------------> |   |
  | A |                | B |
  |___| <------------- |___|        (Jepp. ASCII-Art ist
                                     einfach nur häßlich)
    |  \                /\     |   \_________      /
    |             \    /
    V             /  /              Ach ja, die Legende:
   ___             ___               Ein Pfeil ist ein Link,
  |   |           |   |              ein Kästchen eine Ressource
  | C |           | D |              mit Adresse(!)
  |___|           |___|

Dann gibt es das andere Konzept, ich nenne es mal naheliegenderweise das
Chräcker-Modell. Hier zählt das Gesamtkunstwerk einer linearen Struktur.
Jedes Informationsabschnitt hat einen bestimmten Platz in der Reihenfolge
und diese soll eingehalten werden, um ein bestimmtes Ergebnis zu erreichen.
   ___            ___           ___
  |   |          |   |         |   |
  | 1 | -------> | 2 | ------> | 3 |
  |___|          |___|         |___|

Wobei man diesen Konzept auch auf einen hierarchischen Baum übertragen
kann:
   ___            ___           _____
  |   |          |   |         |     |
  | 1 | -------> | 2 | ------> | 3.1 |        (Habe ich schon erwähnt,
  |___|          |___|         |_____|         wie sehr ich ASCII-Art
                   |            _____          verabscheue?)
                   |           |     |
                   o---------> | 3.2 |
                               |_____|

Es gibt einen Start- und einen oder mehrere Endpunkte. Eine Reihenfolge.
Die eingehalten werden soll. Wenn nun jedoch ein Link auf einen Knoten
mitten in dieser Reihenfolge gesetzt werden soll, dann ist die Reihenfolge
zerstört und damit nach gängiger Meinung anscheinend auch das Gesamtkunstwerk.
Also sei dieses zu vermeiden.
   ___            ___           ___
  |   |          |   |         |   |
  | 1 | ---/---> | 2 | ------> | 3 |
  |___|          |___|         |___|
                   /\                    /
                  /
              ___/
             |   |
             | X |
             |___|

Nach all den ausschweifenden Text und dem häßlichen ASCII-Zeugs nun mein
Vorschlag, der gar nicht so moderat ist. Sorry, ich habe gelogen. ;-)

Ich sehe keinen Widerspruch zwischen beiden Modellen. Nein wirklich nicht.
Es hapert meiner Ansicht nur daran, wie sich das Chräcker-Modell in das
meiner Meinung nach »größere« Web-Modell einfügt. Dies hat natürlich auch
technische Gründe, ich will aber dennoch erst sagen, wie meiner Meinung
nach dieses Einfügen aussehen sollte.

Das Gesamtkunstwerk soll nur als Ganzes genossen werden. Wieso wird es
dann nicht einfach als Ganzes realisiert? Genauer: Als eine Ressource,
die nur über eine Adresse bzw. URI abrufbar ist und auf die man dann
die Links setzen kann.
   _____           ______________________________________
  |     |         |                                      |
  | Tim | ------> | *glänz*   Stempelgeheimnis   *glänz* |
  |_____|         |______________________________________|

Ich finde das logisch - das Gesamtkunstwerk ist ein einziges Ding, eine
einzige Ressource. Wieso soll es dann aufgeteilt sein in Unterressourcen,
die der Natur des Webs nach auch automatisch Adressen haben?

Nun zur Technik. Das Problem ist natürlich, daß auch ein Gesamtkunstwerk
auch aus Happen oder Knoten besteht, zwischen denen man linear navigiert.
Da fallen mir verschiedene Möglichkeiten ein, dies zu beheben.

a) Weiter wie bisher. Nur: Die Einzeladressen dieser Happen vollkommen aus
dem Rest des Webs raushalten. Oder diese verbergen, z.B. mit Frames.
Schließlich will man ja nicht, daß diese von woanders her besucht werden
können. Das betrifft zu allererst Suchmaschinen. Wie sich im unteren Thread
rauskristallisiert hat, ärgern sich viele (ich auch), mitten in so einem
Zyklus anzukommen oder wieder von dort weggerissen zu werden. Die
Gesamtkunstwerker sind da nicht alleine. Hat aber immer noch den Nachteil,
daß die Ressourcen trotz allem adressierbar sind.

b) Die Logik hinter der Adresse verbergen. Das läuft dann auf etwas
dynamischen auf der Serverseite hinaus. Es wird Buch über den Besucher
geführt (Sessions, Cookies, POST oder auch GET) und je nach Besucher und
dem Knoten, in dem sich der Besucher befindet, wird anderer Inhalt
gesendet und somit die Reihenfolge gewahrt. Vom Web-Standpunkt her finde
ich das halbwegs elegant. Hat natürlich den Nachteil, daß sich der Autor
des Gesamtkunstwerkes nun auch noch Gedanken um serverseitige Automaten
machen muß.

c) Alles auf einer Seite, aber dafür dynamisch. Zum Beispiel mit Javascript
und DHTML, die einzelnen Informationsknoten des Gesamtkunstwerkes werden
dann dynamisch eingeblendet. Zu den Nachteilen sage ich mal nichts.

d) Noch dynamischer! Und zwar Flash, eventuell mit dynamisch nachgeladenen
Inhalt. 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.

Ehe irgendjemand aufschreit: Nein andere Arten des Deep Linkings berücksichtige
ich nicht. Außer Gesamtkunstwerkseiten, Datenbankvorsätzen, geschütztem
Inhalt und dem Einbinden anderer Inhalte wüßte ich nichts, was gegen
Deep Linking sprechen würde. Für den zweiten und den dritten Punkt gibt
es technische Lösungen, für den vierten Punkt halbwegs funktionierende
technische Lösungen, wobei dies eher ein soziales Problem ist. Und
außerdem bin ich ein Fan von Deep Links.

So. Ich muß jetzt den Hausflur putzen.

Tim

[sschumann]

Ich finde das logisch - das Gesamtkunstwerk ist ein einziges Ding, eine
einzige Ressource. Wieso soll es dann aufgeteilt sein in Unterressourcen,
die der Natur des Webs nach auch automatisch Adressen haben?

Was sich mit einer MVC Model 2 Architektur auch ganz hervorragend realisieren läßt. Und dann kotzt wieder der halbe Nutzerkreis, weil man die Browsernavigation benutzt hat - was der Controller nicht gut fand, denn man hat sich ja nicht an den Faden des Gesamtkunstwerks gehalten :)))

[wahsaga]

hi,

a) Weiter wie bisher. Nur: Die Einzeladressen dieser Happen vollkommen aus
dem Rest des Webs raushalten.

ja, bei diesem punkt waren Thomas Luethi und ich doch schon längst angekommen in der von dir genannten diskussion!

es geht uns keineswegs darum, ob jetzt der "gesamtkunstwerk-gedanke" irgendwelche theoretischen hypertext-konzepte "verletzt" oder nicht.

es ist nur ärgerlich, wenn zur umsetzung des gesamtkunstwerk-gedankens umleitungen bei deep links (v.a. aus SuMas heraus) erfolgen.

wenn also der ersteller den gesamtkunstwerk-gedanken auch konsequent zu ende denkt (indizierung durch geeignete maßnahmen wie robots.txt, meta tags unterbinden), so dass wir gar nicht erst in diese "falle" laufen müssen, haben wir doch auch gar kein problem mehr :-)

gruss,
wahsaga

[Tim Tepaße]

Hallo wahsaga,

ja, bei diesem punkt waren Thomas Luethi und ich doch schon längst
angekommen in der von dir genannten diskussion!

Jepp. Ihr zwei.

also der ersteller den gesamtkunstwerk-gedanken auch konsequent zu ende
denkt

Darum ging es mir und das wollte ich in etwas freundlichere und etwas
mehr erklärende Worte fassen.

Tim

[Chräcker Heller]

Hallo,

ähem, genau das, was ich doch immer sage ;-)

Ich sehe einfach das Netz als eben eine Vernetzung (im nicht technischen Sinne) an. Eine Vernetzung zwischen allmöglichen "Dingen", und mit Dingen ist es mir auch erst mal wurscht ob es eine Dokumentation, eine Bildschirmseite voll Gedichte, ein Toaster oder ein Spielfilmtraieler ist. Das, was Du mit Resourcen meinst.

Wenn ich "Tunnel-Erlebnisseiten" bereitstelle, dann benutze ich dazu eine Technik, die dafür nicht ausgelegt wurde. Damit meine ich aber ausdrücklich nicht(!) das Netz, nicht das www etc sondern in der Tat das html-Modell. Ich schreibe ausdrücklich nicht: wofür es nicht *gedacht* war, denn das mag stimmen, intersiert mich aber nicht die Bohne. (Doch, natürlich schon, aber eher akademisch/historich)

Es gibt ein paar Alternativen inzwischen, wie zBsp. flash, das ist mir aber bisher schlicht zu teuer gewesen, auch präferiere ich hier eben das offene Format. Aber genau das ist es ja, was ich "irgendwem" gerne vorwerfen würde: das man hier bei der Enwticklung der offenen Techniken bei der Überlegung, was eben eine letztendlich verlinkte Resource sein könnte, etwas "phantasielos" war. (ich habe keine Ahnung von den Gremiumsmechanismen hinter den Kulissen, deswegen formuliere ich das betont vorsichtig)

Diese Phantasie klage ich eben hier ab und an mal ein. Ich gebe aber auch immer zu, das Dinge, wie ich es zum Bsp. mit html macht, keine reinrassigen html-Seiten sind. Nur: andere Techniken habe ich zur Zeit nicht. Natürlich kann ich tricksen, in dem ich zum Bsp. nun eine einframe-Konstruktion nehme oder beim Server rumspiele, aber auch das ist letztendlich nur eine Tesafilmlösung mangels anständiger Autorensysteme für "Typen wie mich".... und die sind gar nicht so selten, es geht ja nicht nur um Gefühl-Erlebns-Vermittlungsseiten wie meine. Das Bedürfnis in sich gekapselte "Bildschirmgeschehen" zu gestalten, ist ja relativ hoch im Web. Man, so scheint es mir, überläst dieses feld nur leider Firmen wie makromedia (womit ich ausdrücklich nichts gegen diese Firma sagen möchte)

Was ich will, ist das Verständnis dafür, das es noch mehr Resourcen gibt als reine html-gestützte Textvorherschende Informationsseiten und das Resourcen viel mehr bedeutet als eben das, was zwischen zwei body-Tags past und ich bin immer gerne bereit zu zu geben, das ich html eher misbrauche bzw aufbohre. Deswegen schreibe ich ja auch immer von "Tesafilmlösungen" bzw von "Seiten kleben".... und wer meine refernezseite kenn, weiß, das ich eben alles nur zusammenstoppel ;-)

Chräcker

PS. danke übrigens Tim für diesen guten neuen Diskussionsansatz!

[Tim Tepaße]

Hallo Chräcker,

Nur: andere Techniken habe ich zur Zeit nicht.

Ja, deswegen habe ich gebräuchliche Lösungen für HTML-Seiten skizziert
und bin nicht gleich auf irgendwelche SVG-Lösungen eingegangen. Schon
allein wegen mangelnden Detailwissens darum. ;-)

Was ich will, ist das Verständnis dafür, das es noch mehr Resourcen gibt als
reine html-gestützte Textvorherschende Informationsseiten und das Resourcen
viel mehr bedeutet als eben das, was zwischen zwei body-Tags past (..)

Ich glaube, das Verständnis dafür ist durchaus da. Ein Resource ist nur
ein über eine Adresse abrufbares Ding, das können sowohl
http://example.org/puristische-text-seite.html als auch
http://example.org/grafische-orgie.ppt sein. Und in der Theorie
können hinter einer Adresse auch verschiedene Dinge stecken; Browser
und Webserver handeln dann aus, was für Inhalt dann gesendet wird. Aber
leider ist die Praxis manchmal etwas ... naja. ;-)

Tim

[molily]

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

[Chräcker Heller]

Hallo,

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.

exakt meine Meinung. (wie auch Dein restlicher Beitrag, aber das hatte ich ja auch weiter unten schon so skiziert....) - Im moment nehme ich noch html für Dinge, für die es nicht ausgelegt ist, weil es eben das einzige weit verbreitete offene Format ist und klebe auf alle Bruchstellen Tesaflim drauf. Das mache ich aber eben sehr bewust, hoffe auf einen Nutzen für die Besucher (Denn die Alternative wäre für mich nur der Rückzug mit solchen Arbeiten aus dem Netz) und poche auf mein Recht, damit nicht als debiler Suchmaschinenspamer zu gelten. (Jaja, das debil galt nicht mir, ich weiß ,-))

Bis zur Durchsetzung eines alternativen offenen Formates (und das wirds erst geben, wenn die "nur html-Inhalte haben Gehalt"-Denker nicht mehr all zu laut vertreten sind) bleibt mir kaum etwas anderes übrig, möchte ich die Freiheit des Netzes auch mit einer Freiheit des Angebotes nutzen. Hier wäre mit manchmal eben nur etwas mehr Toleranz und Offenheit lieb. (nicht persönlich, die geniesse ich ja zum Glück, deswegen hebe ich ja auch immer in solch mir dogmatisch klingenden Fällen die Hand und werfe meine Seiten in den Raum....)

Chräcker

[Tim Tepaße]

Hallo Mathias,

Ich verstehe nicht ganz, wozu dieser Aufwand nötig ist.

Ich sehe das als Übergangslösungen auf dem Weg zu geeigneteren Formaten.
Eine Art des Anerkennens einer Realität, so daß verschiedene Blickwinkel
auf das Web nicht ausgegrenzt werden.

weil sich die Grundlagen des Datenformats HTML und das dahinterstehende
Web-Modell nicht abschütteln lassen.

Ich vermute, ich unterscheide stärker als andere zwischen dem Web (durch
Adressen aufrufbare Ressourcen) und dem Datenformat HTML. HTML ist durch
seine Zugänglichkeit als Textformat und durch die bis jetzt noch alleinige
Möglichkeit des Setzens von Hyperlinks natürlich dominant, ich glaube
jedoch nicht, daß dies auf längere Zeit so bleibt.

Ich kann mir nicht die Aspekte von HTML heraussuchen, die mir gefallen,
diese gebrauchen und gegebenenfalls kreativ zweckentfremden

Oh, ich bin gespannt, was sich da in Zukunft durch die Modularisierung
von XHTML und Techniken wie XLink ergibt. Zumindest hoffe ich, daß sich
da etwas ergibt.

(..) 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.

Etwas grob, aber es beschreibt die Realität zutreffend. Ja.

Tim

[at]

Hallo.
Nichts gegen deinen interessanten Beitrag -- aber deine ASCII-Grafiken gefallen mir.
MfG, at