Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Vorschlag zur Forumerweiterung
Als ich des öfteren Antworten zu SoS-(hauptsächlich MC)-Fragen im Forum nachgeschaut hab sind mir einige Sachen aufgefallen:
- es ist schwer herauszufinden ob eine Frage als “offiziell” gelöst gilt, weil die Diskussion meistens noch ewig weiterrennt und man den Überblick verliert
- es vermischen sich sehr viele Aspekte der Frage(n) die nicht unbedingt immer leicht auseinander zu halten sind
- es gibt meistens keine vollständige, strukturierte Lösung, man muss sich alles aus den verschiedenen Kontexten zusammenklauben
- häufiges “querlabern”/“philosophieren”/… (ist meistens nichtmal wirklich offtopic) bläht Threads enorm auf und erschwert die Suche
Deswegen dachte ich mir mal man könnte überlegen ne bessere Organisationsstruktur in Threads zu ermöglichen:
- ne Art Wikipage zu dem Problem das der Thread lösen soll die das Endresultat fasst
- Unterthreads in denen die einzelnen Aspekte der Frage gesondert behandelt werden können; hier ist auch ne Klassifizierung nach der Relevanz für die Klausur/whatever möglich (zB ein Unterthread für Philosophen/Kritiker/Neugierige, einer für die klausurbezogene Lösung, einer für Fragen zur Literatur unter diesen Gesichtspunkten usw)
- vllt auch die Zuordnung von Tags/Kategorien zu Threads ermöglichen um verwandte Threads/Fragestellungen einfacher zu finden und um sich vllt irgendwann durch Themengebiete klicken zu können (macht insbesondere mit den Wikipages Sinn)
Hmm glaube das wärs erstmal. :>
Ach vllt zu diesem Thread gleich mal ne beispielmässige Strukturierung in Sachen Unterthreads: Pro, Contra, Implementierung, allg Diskussion ^^
Klingt auf jeden Fall alles andere als verkehrt.
Ist alles in Planung mit dem neuen Forum, 
das hört sich doch mal gut an. In so nem wiki könnten dann auch schon unterm semester die Lösungen zu den Übungen eingestellt werden, das wäre unglaublich praktisch zum lernen…
das wuerde mich zu sehr verleiten einfach die loesung anzuschaun
naja, man kanns ja erst nach der übung veröffentlichen
Was auch toll waere sind offtopic-tags, wobei der Text dazwischen nicht schwarz, sondern grau ist und vielleicht sogar wahlweise in den Optionen deaktivierbar ist - dann weiss man, was zum Thread gehoert, und was man ueberlesen kann, wenn man nur am Thema interessiert ist.
Schonmal [ot]…[/ot] versucht?
Entscheidet dann der Poster ob sein Post offtopic ist? Weil dann könnte er ja eigentlich auch gleich in nen Unterthread oder so posten.
Aber es wäre sowieso ne gute Sache Tags sogar auf Postebene zu verteilen damit man nicht nur ne statische Threadstruktur hat (zB für Posts sinnvoll die mehrere Subthreads betreffen oder auch replies auf bestimmte Posts statt einfach allgemein replies zum Thread). Vielleicht würde das sogar “Unterthreads” ersetzen wenn man nicht nur linear-, sondern auch hierarchisch-aufgebaute Threads durch replies auf einzelne Posts machen kann. Ist ja im Usenet auch nicht anders.
Hmm das ist eigentlich die Idee: Usenetmässige Struktur mit Tags (auch auf Postebene) und integrierte Wikipages würde glaube alle meine Anwendungsfälle abdecken. :>
Im Grunde waer das Suchen nach MC aufgaben gar nich so schlimm gewesen, wenn man fuer jede der alten Klausuren eine Thread gemacht haette. Zudem haette man dann auch problemlos die Programmieraufgaben und die Theorieaufgaben darin besprechen koennen.
Ansonsten sind so Loesungs-wiki-pages gar nich verkehrt, auch wenn sie teilweise ziemlichen muell beinhalten.
Das mit den Verschiedenen Unterthreads halt ich aber nur dann fuer sinnvoll, wenn trotzdem weiterhin in zeitlich richtiger reihenfolge alle Posts zu einem Thema in dessen “Hauptthread” stehen, sonst darf man sich ja erst recht zusammenglauben wer wann was geschrieben hat, wenn man gern alles zu einem Thema lesen wuerde. (Teilweise sind z.b. ja auch offtopic sachen auf ontopic sachen bezogen, die machen dann halt wenig sinn wenn sie “allein” im offtopic bereich stehn…) Also praktisch ein Thread wird erstellt mit ner gewissen anzahl an Subthreads (sollte man eventuell auch die normalen benutzer erweitern lassen?!), die leute posten weiterhin in den Hauptthread, markieren aber per Tag in welchen Subthread der Post gehoeren wuerde und der wird dann automatisch auch in den richtigen Subthread gepostet. (Natuerlich sollte man diese Posts dann nur einfach zaehlen, sonst sind ja die Posting-Charts unrepraesentativ. 
)
Ich würde es ganz einfach so machen, dass man beim Erstellen einer Antwort aussuchen kann, ob man in den Thread des Beitrags, auf den sich das Ganze bezieht, oder in einen neuen Unter-Thread schreiben will.
Und dann könnte man es so machen, dass standardmäßig vielleicht alle Beiträge angezeigt werden, man aber einzelne Unter-Threads ausblenden kann.
Unter-Threads? Hört sich an wie Alternate Data Streams oder so. Sonst kann ich mir darunter grad nix konkretes vorstellen. Meinst du damit einfach nur eine hierarchische Beitragsstruktur (Baumstruktur)?
Ja, sowas in der Richtung → Newsgroup-artig?
Ein Tag-System finde ich jedenfalls ein bisschen zu kompliziert…
Ohne Tags kriegst du halt nur ne hierarchische Struktur. Wenn man wirklich noch ein Wiki integrieren würde wäre das als einzige Organisationsstruktur wahrscheinlich wieder zu statisch.
Okay, hierarchische Threads, wie in Newsgroups. Nur hab ich persönlich damit noch so meine Bedienungsprobleme, man bekommt einfach keinen anständigen Lesefluss hin, wenn man einen Zweig gelesen hat und zum nächsten ungelesenen wechselt, weiß man gar nicht mehr, worauf der sich grade bezieht, weil man zu einem unbekannten früheren Punkt in der Diskussion zurückspringt und viele Beiträge in einer völlig ungeordneten Reihenfolge liest. Das ist für mich nicht benutzbar. Dazu kommt noch erschwerend, dass die Frame-Technik der Newsreader nicht ohne weiteres auf Webseiten übertragbar ist. In den Heise-Foren muss man z.B. immer hoch und runterblättern, und in großen Threads wird’s schnell unübersichtlich. Dafür müssten erst Lösungen gefunden werden. Ein paar Ideen für netzwerk-artig organisierte Beiträge hab ich schon, aber richtig toll sind die noch nicht.
Die Wiki-Integration finde ich auch eine gute Idee, ich bin in der Tat schon mit Planungen beschäftigt, die ein solches Foren-Konzept beschreiben. (Such mal nach “UNB2”…)
Ich hätte gesagt man blendet für einen „Pfad“ in der Threadhierarchie einfach immer den passenden Kontext ein.
Beispiel:
[m]A
B
C
D
E
F
G
[/m]
Wenn man jetzt D liest ist nur A,B,C,D eingeblendet; wenn man dagegen G liest ist nur A,F,G eingeblendet usw. Kommt dann eigentlich auch wie ein linearer Thread mit Verzweigungen als Unterthreads. Kleine Unterthreads könnte man eigentlich auch direkt in den „Lesefluss“ integrieren, oder überhaupt wäre es sinnvoll bei Bedarf zwischen den Ansichten (am besten auch partiell in Bezug auf einzelne solcher Pfade im hierarchischen Thread) zu wechseln.
Könnte man in Bezug auf Tags noch verallgemeinern (s.u. ^^) aber dann landet man schnell bei ner Darstellung von allgemeinen Graphen. Heisst jetzt natürlich nicht das das unpraktikabel wäre, aber komplizierter schon. Vllt reicht für praktische Anwendungen auch tatsächlich ne Baumdarstellung (von verallgemeinerten Tags, Referenzfolgen usw.; s.u.) die die Identität von Knoten des eigentlichen Graphen erhält, aber Knoten entsprechend dupliziert darstellt (für Feinsinnige: man stellt für jeden Knoten die transitive Hülle der jeweiligen Kantenrelation als Baum dar; klingt fast so als wäre das ein Anwendungsfall für embedded Prolog in PHP oder nen Prolog->PHP-Compiler ;P)
Zur Lösung von
schlage ich mal „merges“ (sich auf mehrere Pfade gleichzeitig beziehen bzw zusammenfassen; könnte man in der Baumansicht einfach dupliziert, aber natürlich mit gleicher Identität darstellen, s.o.) als komplementäre Aktion zu „forks“ (neuen Pfad erstellen bzw Unterthread eröffnen) vor. Darstellung siehe oben.
Les hier grade mehr von deinen Diskussionseinstiegspunkten. Klingt für mich wie ein besonders getaggter „fork“. Und das ganze Forum als Graph mit Knoten als Beiträgen und Kanten als Referenzen aufzufassen klingt auch nach ner sehr genialen Idee.
Bin grade am überlegen ob ein Hypergraph nicht besser zum Tagging-Konzept passen würde. Hier wäre dann einfach alles mit einem Tag über eine Hyperkante verbunden, für Referenzen u.ä. wären eventuell noch gerichtete Tags(„mehrstellige“)/Kanten/Hyperkanten denkbar, womit dann auch gleich „merges“ abgedeckt wären.
Als allgemeinere Definition eines Tags wäre für mich übrigens Tag:=n-stellige Relation über (partielle/Teile von) Beiträgen. In bestimmten Kontexten wäre das sicher hilfreich (zB variablere Referenzvergabe aka „forks“/„merges“/…, Zitate, benutzerdefinierte Tags im Content einer Wikipage aka „Inhaltsverzeichnis“/„Zusammenfassung“/„Bildbeschreibungen“/… usw), prinzipiell könnte man dann auf „everthing is a tag“ gehen.
BTW: nein wer hätte gedacht das ich sogar in diesem Kontext auf beinahe kategorielle Abwege gerate. Jetzt besser nicht noch weiter verallgemeinern, sonst trauern wir gleich alle gemeinsam Prof. em. Dr. Hans Jürgen Schneider nach. ^^
Die Beschreibung zu UNB2 sagt mir übrigens in weiten Teilen schon sehr zu. :>
Wo ich grad dabei bin: ne Art Pluginkonzept für Markup-Sprachen (insbesondere in Bezug auf integriertes Wiki) und ähnliches wäre auch sehr hilfreich. Z.B. für Mathe könnte man Formelrenderer gebrauchen, für diverse Programmiersprachen Syntaxhighlighting …
Das scheint jetzt wieder einer dieser Posts geworden zu sein bei denen man sagt „hä, was will der?“ (geht mir morgen wahrscheinlich genauso ^^) darum hier mal die Zusammenfassung der Aspekte die mir momentan am wichtigsten erscheinen:
- Schlachtruf „everything is a tag“ realisiert über gerichtete (Hyper-)Kanten eines (Hyper-)Graphen auf „Beiträgen“ (das schliesst auch Teile von Beiträgen ein, zB bei Zitaten oder benutzerdefinierten Tags innerhalb von Content einer Wikipage). Lasst euch von dem „Hyper-…“ nicht abschrecken, das soll hier einfach nur andeuten das es auch mehrstellige Tags (zB merge(PostA,PostB,PostC) <=> C ist ein merge von A und B) gibt. Damit kann man wahrscheinlich extremste Flexibilität zocken, braucht eventuell halt ein paar Optimierungen (zB Caching von Tags die die zugrundeliegende Struktur des ganzen Forums bilden, halt ein bisschen von der „äusseren Hülle“ ^^).
- Dualität der „fork“/„merge“-Operationen auf Pfaden innerhalb einer Threadhierarchie
- Darstellungsweisen: Pfade als pseudolineare Threads feat. traditionelle Baumstruktur (siehe beispielsweise Usenet) mit identitätstreuer (kein „crossposting“!) Duplikation von Beiträgen um allgemeinere (also nicht nur Bäume!) Graphen darzustellen.
Nachtrag:
hab mal noch mit ein paar Anwendungsfällen experimentiert und bin zu weiteren Einsichten und Optimierungsmöglichkeiten gekommen:
- „everything is a tag“ ist meistens eine Indirektionsstufe von der „intuitiven“ Lösung entfernt, kann aber auch sehr praktisch sein wenn man sich zB direkt auf ein Zitat (oder besser eine „Zitierung“? ^^) beziehen will statt wiederum alles (auch bereits enthaltene Zitate usw) zitieren zu müssen. Feinsinnig ausgedrückt kann man alle Objekte jetzt auch intrinsisch (über Identität) statt sonst im Allgemeinen nur extrinsisch (über Inhalt) referenzieren.
- wenn man Content tagbasiert referenziert kann man eine maximal-sharing-Philosophie umsetzen die vllt die Verwaltungskosten für Tags wieder reinholt
- tagbasierte statt postbasierte Versionierung ist wesentlich flexibler, es können beispielsweise ganze Wikipagehierarchien mit nur sehr wenig Versionierungsinfos verwaltet werden wenn sich an an den meisten Pages wenig ändert
- Content der in Hypergraphform vorliegt, aber so häufig benötigt wird das der Renderingaufwand zum Problem wird kann zu „flachem“ Content kompiliert werden. Dazu wird die Graphstruktur (die natürlich im Backend weiterhin existiert) in eine lineare, atomare Struktur transformiert, die dann wie „traditioneller“ Content ohne viel Rechenleistung gerendert werden kann. Im Extremfall kann hier sogar auf reines HTML runtergebrochen werden, oder man geht einfach über Caching im Hauptspeicher. Solche Optimierungen könnten für Content mit sehr vielen Zugriffen (zB News, Übersichtsseite …) notwendig sein.
- Namespaces für Tags scheinen sinnvoll. Dann muss man in seinem Post nicht drauf achten die Namen von globalen Tags versehentlich zu benutzen und man könnte die Tags der Leute die vorher gepostet haben direkt mitbenutzen. Denke hier an ein einfaches Umgebungsmodell das Name->Identifikator-Bindings über die replyTo-Relation vererbt. Wenn man sich auf Tags ausserhalb der Hierarchie bezieht kann man eindeutige Namen durch PostId.Tagname oder ein ähnliches Schema erreichen. Wenn Versionierung auf Tags angewendet wird kann man zusätlich ein PostId.Tagname.Version Schema verwenden sonst geht man einfach auf die zu der Zeit aktuelle Version.
Also viel hab ich nicht grade verstanden, deshalb gehe ich nur auf diese Teile ein.
Willst du für jeden Beitrag alle vorherigen anzeigen? Also die konventionelle Baumansicht, nur dass alle vorherigen Beiträge ebenfalls ständig sichtbar sind? Bissl viel, hm?
Mehrstellige „Tag-Relationen“, was soll das bringen? Ich kann mit Tags („Schlagwort“ find ich ne gute Übersetzung) nur Beiträge kategorisieren, weiß nicht, was du damit vorhast. Referenzen durch Tags ersetzen, wie soll das gehen, und kann man das sinnvoll auf datenbankrelationale Ebene abbilden? Was sind überhaupt „forks“ und „merges“? Außerdem bin ich mir nicht sicher, wie sinnvoll es ist, die Referenzen und Adressierung von Inhalten von der Ebene der Beiträge auf deren Inhalt auszuweiten. Dann müsste man ja zusätzlich zu Post-IDs noch Absatz-IDs vergeben? In der Formatierungssprache wollte ich sowas jedenfalls nicht sehen.
Zur Darstellung für den Benutzer haben wir jetzt ja nicht viel gehört. 
Dass man Beiträge auch sehr kompliziert und dadurch vermutlich unnötig „flexibel“ verwalten kann, ist klar, aber es muss benutzbar bleiben, sonst hat es überhaupt keinen Sinn. Mir geht’s derzeit immer noch hauptsächlich darum, ob man Beiträge als Bäume oder gar Graphen überhaupt so darstellen kann, dass die Organisationsvorteile überwiegen. Unter aktuell verfügbaren Techniken bevorzuge ich noch klar die flache Ansicht einer linearen Liste von Beiträgen, Bäume sind bislang zu unübersichtlich und Graphen gibt’s noch keine.
Hallo,
im Prinzip wäre das vorgeschwebte wohl eine rekursive Threadimplementierung, also Threads, die innerhalb von jedem Thread entstehen können. Das Startposting eines Threads ist ein variables Posting aus einem anderen Thread und somit zu beiden assoziiert.
Solche Foren gibt es ja schon öfters zu sehen. Mir gefallen sie leider gar nicht. Es ist sehr mühselig, sich in einem Thread zurechtzufinden. Dieser wird auch unnötig fragmentiert, da Antworten auf Beiträge sinnigerweise grundsätzlich einen neuen Ast eröffnen müssen und man nun auch mehrere Beiträge braucht, um auf mehrere Beiträge zu antworten, bzw. eine allgemeine Diskussion ohne feine Aufsplittung ist eigentlich relativ unmöglich.
cu
Ford Prefect