Wiki mit Baum-Struktur

Sebastian J

Ich fände es super, wenn es statt 2 Schichten (Kategorie und Seiten) beliebig viele (oder zumindest ein paar mehr) Schichten geben könnte.

Also zB in meiner Wiki-Kategorie K gibt es dann:

Seite 1 Schicht A
- Seite 1 Schicht B
- Seite 2 Schicht B
  - Seite 1 Schicht C
    - ...
- Seite 3 Schicht B
Seite 2 Schicht A

Ich verstehe ehrlich gesagt nicht, warum es diese Möglichkeit nicht gibt. (Oder übersehe ich etwas?)
Bei Ordnern auf dem PC oder bei Seiten in Confluence ist das doch schon seit Jahrzehnten etabliert. So könnte die Navigation und Struktur in den jeweiligen Wiki-Kategorien doch viel besser werden.

phelfer

Ja das fände ich auch gut.
Dann würden wir das sogar nutzen.

Gunnar

@sebastian-j Wo willst du das haben?

Ich habe Unterseiten von Unterseiten von Unterseiten angelegt, "no problem".
Da aber jede Seite von jeder Seite referenziert werden kann, ist eine Hierarchie der Unterseiten graphisch nicht darstellbar.

Ein Wiki ist kein Folder-Tree! sondern Web Content Management System. Obstsalat und kein Apfelbaum!
Beispiele: lies "==>" als "... hat Verlinkung zu ..."

Start-Seite 1 ==> Seite 2 ==> Seite 3 ==> Seite 2
Start-Seite 4 ==> Seite 3 ==> Seite 2
Start-Seite 5 ==> Seite 6 ==> Seite 7 ==> Seite 2 ...
Auf welcher Ebene soll Seite 2 angezeigt werden? Wie oft?

Und ganz eigentlich gilt in (meinen) Wikis: "Each page is page 1" = jede Seite kann vom Nutzer als erste Seite = Homepage genutzt werden = no hierarchy. Normalerweise werden Kategorien in Wikis einer Seite zugeordnet, so dass eine Seite auch zu 2 Kategorien gehören kann, ChurchTools ist hier ??? schlauer ??? anders ??? komisch !!!

Solange kein Standard "du darfst nicht wild verknüpfen" als Beschränkung zur Erreichnung einer Baumstruktur eingeführt wird, ist mir egal, ob bei anderen Wiki Seiten old-school hierarchisch angeordnet werden.

PS: Microsoft wollte vor 15 oder so Jahren die Folderstruktur abschaffen und durch kluge Metadaten ersetzen, die Testnutzer haben es aber nicht kapiert und gerufen "wir wollen unseren hierarchischen Folder Tree zurück".

bwl21

@gunnar sagte in Wiki mit Baum-Struktur:

Da aber jede Seite von jeder Seite referenziert werden kann, ist eine Hierarchie der Unterseiten graphisch nicht darstellbar.

Ist schon grafisch darstellbar, nur nicht mehr als Baum

Ansonsten volle Zustimmung!

Und wenn jemand einen Baum will kann man den als eine eigene Seite prolbemlos aufbauen.

Wenn man den Wunsch aber verallgemeinert, dann würde man

Breadcrumbs anzeigen, auf welcham Weg man zu der Seite gekommen ist.
auf den Seite eine liste der "referenzierenden Seiten" angeben. Die kann man ggf. sogar manuell erstellen.

Sebastian J

@gunnar Ich verstehe ehrlich gesagt die Vehemenz nicht so.

Niemand verbietet ja Verlinkung von Seiten. Die Baum-Struktur soll einfach nur den Obstsalat strukturieren. Wenn du weiterhin den Obstsalat haben willst - dann nutzt du eben den Baum nicht. Aber ich finde eine Struktur, wo ich logisch zu meiner Zielseite komme (über den Baum) hilfreich.

Wenn ich in deinem Beispiel Seite 2 finden will und ich kenne den Weg zu ihr nicht genau - dann muss ich ewig durch die Gegend klickern, bis ich endlich bei ihr angekommen bin. Ich finds einfach unordentlich so.

Und: Eine Suchfunktion wird dann erst sinnvoll, wenn das Wiki sehr umfangreich ist, ich dort also erfolgreich nach fast allem suchen kann. Wenn ich also keine Ahnung habe, was das Wiki überhaupt alles so beinhaltet, dann hilft mir der Baum viel mehr als nach allem möglichen zu suchen.

Gunnar

@sebastian-j Kann man so machen, in meiner Welt dann ein Baum und kein Wiki.

Solange du wenige Seiten hast und nicht suchen willst, ist die Erstellung und Aktualisierung einer manuellen "Baumseite" überschaubar und möglich.

Bei Interesse an einer automatischen Baumseite bitte ganz oben voten.
Dass ich "aus Prinzip" dagegen bin ist wohl ersichtlich, es gibt aber keine negativen Votes ...

MichaelG

@sebastian-j mal unabhängig von dagegen und dafür: @Gunnar hat einen validen Punkt.

Wenn sie A Seite B verlinkt und umgekehrt, führt der Baum doch ins unendliche. Ich bin kein großer Wiki Kenner und kenn mich mit den Möglichkeiten nicht aus, sehe aber nicht, wie das automatisiert sinnvoll durchgeführt werden kann.

Eine grundsätzlich, z.B. alphabetisch sortierte, Seite mit allen vorhandenen Seiten finde ich aber auch sinnvoll

bwl21

@michaelg es im menü der Kategorie den Punkt 'Alle Seiten'

Simon2

@michaelg sagte in Wiki mit Baum-Struktur:

…sehe aber nicht, wie das automatisiert sinnvoll durchgeführt werden kann. …

Indem man nicht „verlinkt“ mit „Unterseite“ gleichsetzt.

Macht man bei Büchern auch schon immer so: Einiges sind Verweise („Wenn du zu diesem Begriff Näheres wissen willst, dann im Kapitel xyz..“) und anderes Unterkapitel („Ein Aspekt des Themas wird im Folgenden näher erläutert.“).

Ich bin jetzt kein harter Verfechter einer Baumstruktur, sehe aber Konstellationen, bei denen sie helfen kann.
(Da finde ich bisweilen auch wikipedia unnötig umständlich - es gibt einfach Unterthemen, die nur in einem bestimmten Kontext (Oberkapitel/-seite) Sinn ergeben)

Das Darstellungsproblem sehe ich als lösbar an - auch bei zirkulären Strukturen. Z.B. über eine begrenzte Verschachtelungstiefe und/oder eine „dynamische Übersicht“, die stets nur 1-2 obere und 2-3 untere Ebenen (bezogen auf einen aktuellen „Beobachtungspunkt“) anzeigt.
…übrigens ganz unabhängig von der Struktur.

P.S. Einen „Zwang“ zu einer Baumstruktur würde ich aber auch ablehnen. Dann wird man zu Unsinn gezwungen.

Sebastian J

@michaelg Wie Simon schon sagt: Das verlinken und die Baum-Struktur müssen doch gar nichts miteinander zu tun haben.

Ich kann Seiten wie wild verlinken, aber könnte sie gleichzeitig auch in einem (nicht automatisch generierten) Baum strukturieren. Das wäre also ein Feature on top, niemand würde zu irgendeinem Baum gezwungen. Wer ihn nicht haben will, der lässt alle Seiten eben auf Level 0.

MichaelG

@sebastian-j verstehe ich dadurch besser, ja! Aber ist dann nicht wirklich eine selbst erstellte Indexseite die Lösung?

Ralf Werner

Ich schließe mich der Meinung von @gunnar an , da in Wiki auch links wie [Home](<>/#HomeView/) oder [Ich]<>/?q=churchdb#/PersonView/searchEntry:%231977) und auch rekursive links die wieder auf die Ursprungs-Seite des ersten links weisen enthalten sein können (<>=https://anskar.church.tools bei mir).
Die links können auch auf andere Wiki-Tools verweisen, die erheblich besser und stabiler als CT-Wiki sind - so oder so - wer darf.
Die Spur der Links sollte aber mit der back-Taste vollständig zurück kommen - ist bei manchen Browsern nicht immer so (Feature/Bug).

r.palmer

@ralf-werner Hallo Ralf,
du scheinst dich sehr gut im Wiki und mit Links aus zu kennen und bevor ich einen neuen Artikel aufmache wollte ich folgende Frage an dich richten:

Wie erstellt man im Wiki einen Link, welcher auf eine Überschrift auf einer anderen Wikiseite verweist, also mich direkt dorthin bringt?
Ist das möglich und wenn ja, kannst du mir ein konkretes Beispiel geben?

Seite 1
Überschrift 1
Text + Link (Zu Seite 2, Überschrift 40)

Seite 2
Überschrift 1
Text
Überschrift 2
Text
…
Überschrift 40
Text

Mein Ziel ist es direkt den passenden Artikel zu sehen.

Vielen Dank im Voraus
Ruben

Ralf Werner

@r-palmer sagte in Wiki mit Baum-Struktur:

Wie erstellt man im Wiki einen Link, welcher auf eine Überschrift auf einer anderen Wikiseite verweist, also mich direkt dorthin bringt?

Hier ist ein Beispiel aus meinem Umfeld. Ich habe MD/Wiki zunächst in anderen Tools als CT=ChurchTools kennengelernt und war/bin von den Einschränkungen und Fehlern sehr überrascht. Dennoch halte ich das Wiki-Konzept über links im Netz und mit Fließtext eine Beschreibung zu erstellen, überlegen gegenüber anderen Konzepten (pdf,doc ...).

Ein Versuch die gravierendsten Einschränkungen über CT-Support zu bereinigen ist leider gescheitert (keine Prio). Also bin ich dazu übergegangen sie zu beschreiben. Was an CT-Wiki gut ist, ist die Verarbeitung von Header-Ids in Inhaltsverzeichnissen und links. Nicht gut ist, dass der Algorithmus sich zuletzt 4 mal (ohne changelog) geändert hat.
Es werden nur #,##,### Header in links verarbeitet und bei längeren Seiten oft ungenau positioniert. Die Bearbeitung der Seiten ist ebenfalls sehr "gewöhnungsbedürftig".

Die Domain braucht nicht in den links angegeben zu werden ([](/...)), solange man sich innerhalb von CT bewegt. Wenn du mein Beispiel oben (... oder so nicht CT) checkst, mußt du auf Preview umschalten und die Details öffnen. Dann findest du dort auch ein integriertes Video

jziegeler

@r-palmer was du suchst sind Anker-Links. Diese setzen sich aus der URL und der ID der Überschrift zusammen und lassen sich am einfachsten aus dem Inhaltsverzeichnis rechts mit "Link-Adresse kopieren" ziehen. Sollte dan etwa so aussehen: https://churchtools.test/wiki/0#fragen.

Wie Ralf schon geschrieben hat, brauchst du die Domain nicht und kannst den Link so [Link](/wiki/0#fragen) angeben

r.palmer

@jziegeler Danke für die Antwort, es klappt bestens:)

Gruß
Ruben

Andi 1

@jziegeler sagte in Wiki mit Baum-Struktur:

@r-palmer was du suchst sind Anker-Links. Diese setzen sich aus der URL und der ID der Überschrift zusammen und lassen sich am einfachsten aus dem Inhaltsverzeichnis rechts mit "Link-Adresse kopieren" ziehen. Sollte dan etwa so aussehen: https://churchtools.test/wiki/0#fragen.

Wie Ralf schon geschrieben hat, brauchst du die Domain nicht und kannst den Link so [Link](/wiki/0#fragen) angeben

Das funktioniert bei mir aber nur im Web, nicht in der App. Ich erhalte dort die Fehlermeldung "Non-existent! The page was not found or does not exist yet." Im Web klappt es bei mir einwandfrei.