Das neue Wiki ist da - Livestream heute um 20 Uhr

Simon2

@david-r: Ich kann deine generellen Fragen nicht beantworten, aber zu deinem konkreten Beispiel habe ich eine Meinung:
@david-r sagte in Das neue Wiki ist da - Livestream heute um 20 Uhr:

..."Ich habe Anleitungen - Hätte Sie auch gern unter der Kategorie Anleitung, weil es eben da logisch ist....

Finde ich nicht.
Anleitungen sind mMn nur in Bezug auf die jeweilige Zielgruppe sinnvoll und passen deshalb hervorragend in gruppenspezifische Wikis.
"Anleitung" ist eine ebenso globalgalaktische (und damit wenig hilfreiche) Kategorie wie "Übersicht".... ich sehe keine Vorteile davon, alle Anleitungen in eine Schublade zu packen.

Das schließt nicht aus, dass es (auch für mich) nachvollziehbare Konstellationen gibt, in denen die derzeitige Rechteverwaltung zu Problemen führt - nur hier sehe ich es gerade nicht.

Gruß

Simon

bwl21

@david-r sagte in Das neue Wiki ist da - Livestream heute um 20 Uhr:

Ich halte es leider für sehr wenig durchdacht. Wo liegt das Problem, wenn von den Benutzern gewünscht (gab ja gestern schon zur Präsentation anfragen dazu) jeder Seite einzelne Rechte zu vergeben?

ketzerische Anmerkung: Benutzer (auch ich tendieren dazu Partikularanforderungen zu stellen. Wenn man die einfach nur umsetzt, dann kommt ein chaotisches System zustande. Man muss die alle Zusammenhang bringen um ein langfristig stabiles System zu haben. Daher würde ich das "nicht durchdacht" so nicht ganz unterschreiben.

Eine Berechtigung auf Einzelseiten halte ich für technisch schwierig und für die Benutzer / Admins kaum beherrschbar.

Lösungsvorschlag

Ich mach dir hier also einen Lösungsvorschlag, wie du mit vorhandenen Mitteln vorgehen kannst:

Du legt so viele Kategorien an wie du unterschiedliche Berechtgungen brauchst
Du gibst den Anleitungen Nummern (so wie das in Betriebshandbüchern üblich ist)
Auf der Hauptseite jeder Kategorie verlinkst du auf die relevanten Anleitungen
Du verlinkst nicht mit der Kategorieinternen Syntax [[Anleitung Jedermann]]sondern mit einer normalen Markdown-url [Anleitung jedermann](wiki/1/test1)

Das Ergebnis sieht dann so aus:

Hier die Ansicht für jedemann

im Bearbeitungsmodus

Hier die Ansicht für die Gemeindeleitung

im Bearbeitungsmodus

Dieser Ansatz bietet dir viel Flexibilität und Möglichkeiten, die Anleitungen für jeweilige Zielgruppen zusammenzustellen bzw. Anwenderspezifische Navigationssseiten zu machen.

Da kannst du sogar Zwischenüberschriften usw. einfügen und was immer dir noch einfällt.

davidschilling

@david-r sagte in Das neue Wiki ist da - Livestream heute um 20 Uhr:

Warum funktioniert bei mir als Admin die (Schnell) Suche nicht? Im Video bei 52:30 kann Gerrit "Wiki" suchen und es wird ihm alles aus der Rechteverwaltung angezeigt. Bei mir hat er nicht einen einzigen Treffer.

Die Schnellsuche sucht im Titel der Wiki-Seiten, die Suche im Wiki durchsucht auch die Inhalte. Wenn du ein Beispiel bei dir hast bei dem das nicht funktioniert kannst du dich beim Support melden dann schauen wir uns das an.

jziegeler

@david-r Gerrit hat nicht die ChurchTools suche verwendet. Er war bereits auf der Seite der Rechte und hat dort einfach nur mit Strg + F die ganz normal die Browsersuche verwendet.

David.R

@jziegeler ah ok, das erklärt es. Da lag der Fehler also darin, dass ich sozusagen das falsche Feld benutzt habe. Danke

David.R

@bwl21
Danke das mit den Markdown URL hilft natürlich schon weiter.

Ich habe jetzt folgenden Ansatz versucht um eine -für mich/uns- praktikabel Lösung zu finden:

Ich habe je nach Berechtigung Kategorien angelegt und denen eben die entsprechenden Rechte gegeben.
Da drunter eine Seite Anleitung. Da die Anleitung, welche schon vorhanden sind (also von uns schon erstellt) jeweils an die richtige Stelle. diese Seite dann ausgeblendet.
Auf der Seite Anleitung jeweils das Thema geschrieben z.B. Checkin und dann einfach eben verlinkt auf die jeweilige Seite.
Sollte jetzt jemand versuchen die Anleitung aufzurufen, für die er/sie keine Berechtigung hat wird das so auch angezeigt.
So ungefähr stellte ich es mir vor.
Bin halt jetzt den Zwischenschritt mit den einzelnen Kategorien gegangen.
Aber damit denke ich durchaus machbar. Habe ich sozusagen meine Berechtigung wie gewollt.

bwl21

@david-r Damit folgst du im Wesentlichen meinem Vorschlag. Ich wollte halt keine Links anzeigen, für die dann keine Berechtigung vorliegt, um die Leser nicht zu verwirren. Wenn das aber nichts ausmacht ist es auch ok.

David.R

@bwl21
Sei mir nicht böse ich folge dem klugen Vorschlag meiner Frau, die dieses. Forum gar nicht mitbekommen hat.
Aber ja es geht natürlich auch in die Richtung.

dominikschreiber

Hi!

Ich hab mich gefreut wie ein kleines Kind als ich in den Release Notes von v3.76 "Wiki im neuen Glanz" gelesen habe und dann realisiert, dass das neue Wiki Markdown versteht. Das war einer meiner größten Wünsche seit wir das ChurchTools-Wiki verwenden (erst recht wo in ChurchTools nach und nach immer mehr neue Markdown-Editoren aufgepoppt sind, z.B. bei Gruppenbeschreibungen). Eins bereitet uns jedoch Kopfzerbrechen:

Wir verwenden ziemlich intensiv Tabellen, mit vielen Spalten, sicher nicht gedacht für Mobilgeräte. Im neuen Wiki wird der komplette Wiki-Inhalt auf 940px Breite beschränkt und die Tabellenzellen brechen teilweise mitten im Wort um. Das macht unsere bisher gut lesbaren Tabellen fies unübersichtlich. Bei zu Markdown konvertierten bzw neu angelegten Wiki-Seiten kann ich damit leben, da habe ich ja aktiv Hand angelegt und könnte alles ändern. Leider betrifft die Änderung aber auch nicht nach Markdown konvertierte Wiki-Seiten und ist damit eine ärgerliche Regression, die ohne unser Zutun die Benutzung verschlechtert.

Ich weiß dass Tabellen gerade mobile first extrem schwierig umzusetzen sind, weil der use case nie ganz klar ist. In der UX-Szene zerbricht man sich dazu regelmäßig die Köpfe und kommt dann auf Dinge wie

und das betrachtet nur den Fall von "Data Tables". Insofern habe ich gar nicht den Anspruch, erst recht nicht an ein Markdown-Wiki, das Problem allumfassend zu lösen.

Wir wollen aber darum bitten, wenigstens für nicht nach Markdown konvertierte Wiki-Seiten schon bestehende (und zumindest in unserem Fall) fies breite Tabellen weniger kaputt zu machen als das gerade der Fall ist. Dazu fallen mir drei recht einfache Fixes ein (für die man kein neues UX-Konzept für Tabellen braucht):

kein .cts .markdown th,.cts .markdown td{word-break:break-word} mehr für Tabellenzellen in nicht nach Markdown konvertierten Wiki-Seiten => dadurch brechen die Tabellenzellen nicht mehr mitten im Wort um, schon das erhöht die Lesbarkeit deutlich; oder
kein .cts .markdown table{max-width:940px} und stattdessen :root{--max-width:100%} für nicht nach Markdown konvertierte Wiki-Seiten => dadurch nimmt die ganze Wiki-Seite wieder die volle Breite ein und man hat was von seinem 27"-Bildschirm für den man die Tabelle damals geschrieben hat; oder
(das ist aufwändiger) eine "Metrische Entkopplung" des <tbody> der Tabelle: position:relative;overflow:auto an die <table> und position:absolute;width:max-content an den <tbody>, dann im JavaScript die scrollHeight des <tbody> ausrechnen und als height an der <table> anbringen => dadurch wäre die ganze Seite weiter 940px breit aber die Tabelle hätte eine Scrollbar und wäre so breit wie ursprünglich gedacht.

Wäre sehr sehr fein wenn ihr da noch mal an den Tabellen basteln würdet. Markdown im Wiki ist nämlich hammer hammer gut!

Danke für eure Überlegungen, gerade über das letzte Jahr hat man gemerkt wie viel ihr doch in ChurchTools investiert. Weiter so!

Viele Grüße
Dominik

jziegeler

@dominikschreiber danke für dein Feedback. Das ist mir wirklich beim Entwickeln durchgerutscht für die Version 3.77 habe ich das schon mit deinem Punkt 1. korrigiert. Könntest du mir aber vielleicht trotzdem noch mal eine eurer "extremen" Seiten als HTML an jziegeler@churchtools.de schicken? Dann kann ich damit noch mal explizit testen, bevor die Version dann am Montag 6.9. live geht

dominikschreiber

Hey @jziegeler, vielen Dank! Das ging ja flott, mega gut. Ich habe dir drei Beispiele gemailt. Bin sehr zuversichtlich dass schon das fehlende word-break:break-word uns gut weiter helfen wird. Danke für den schnellen Support. Klasse!

bwl21

@dominikschreiber mal ne blöde Frage: warum möchstest du {word-break:break-word} nicht. Es gefällt mir persönlich eigentlich besser, weil dann im pathologischen Fall die Tabelle nicht unendlich groß wird. Wenn ein Wort nicht in die Zelle passt ist es doch eh zu lang und es ist egal ob man es umbricht oder nicht, man muss sich eh was anderes ausdenken.

p.s. diese Diskussion sollte eigentlich nicht imm Ankündigungsforum laufen, drum hab ich lange gezögeert, überhaupt zu schreiben. Vielleicht kann man das korriegieren.

MichaelG

@jziegeler ich kenne mich mit den Codes dafür nicht wirklich aus, sehe aber immer noch, dass URLs auch nicht umgebrochen werden. Das dann so unschöne Effekte hat, dass sich das komplette Wiki verschieben lässt, nur weil irgendwo auf der Seite eine längere url steht.

Vielleicht lässt sich das auch beheben. Bei URLs finde ich es zb nicht schlimm, wenn sie umbrechen

Philippus

Hallo zusammen, erstmal danke für das Markdown. Ich finde das klasse. Es ist einfacher als HTML und macht es unseren Mitarbeitern leichter im Wiki Seiten zu erstellen und zu bearbeiten.

Wir haben allerdings 2 Probleme mit den Dateianhängen festgestellt (manche Formulardateien hängen wir im Wiki an, damit die Nutzer sie direkt runterladen können).

wenn eine Datei freigegeben ist, kann ein User, der keine Schreibrechte hat, dennoch alle Optionen im Menü sehen, auch wenn ein klick darauf einfach keine Response erzeugt. Klickt er allerdings "umbenennen", öffnet sich ein Pop-up, bei dem er den Namen ändern kann, beim Speichern aber einen Fehler erhält (Anmerkung: das "umbenennen" in dem Pop-up vermisst ein "e")
Bei einigen unserer Seiten, die wir zu Markdown konvertiert haben, sind Dateianhänge nicht mehr downloadbar, obwohl sie von der Rechteverwaltung freigegeben sind. Auch ein erneutes hochladen der Datei hilft nicht. Die Anhänge tauchen nicht auf. Wir erkennen darin auch kein Muster, außer eventuell, dass die Menge des Textes dafür verantwortlich sein könnte. Bei viel Text tauchen Anhänge nicht mehr auf, bei wenig Text schon.
Unser Workaround sieht jetzt so aus, dass wir die Dateien als Link in die Wiki-Seiten einbinden, aber schöner wäre es, wenn die Anhänge unten wieder normal funktionierten.
Hier die Ansicht beim Admin

Beim User wird nicht mal mehr der Bereich "Dateien & Links" angezeigt

Ich hoffe dafür kann schnell eine Lösung gefunden werden. Viele Grüße und vielen Dank
Philippus

jziegeler

@philippus das sind beides bugs die bereits in der Version für Montag behoben sind. Bugs bitte generell an support@churchtools.de melden.

Philippus

@jziegeler Ah, klasse, vielen Dank!

sp0ken

Hallo,

Ich finde die Struktur ungünstig. Wenn ich mehrere Seiten unter einer Kategorie anlege, erscheint immer die erste Seite und nicht eine Übersicht aller Seiten. Man muss erst auf "alle Seiten" gehen, dann bekommt man die Übersicht. Ist irgendwie umständlich.
Kann man da was machen?

VG,
Timo

bwl21

@sp0ken ich mach das so, dass ich auf der Startseite der Kategorie manuell ein Inhaltsverzeichnis erstelle. Auf diesem Weg mach ich auch die neuen Seiten.

Damit komme ich einigermassen durch.

Du kannst auf der Startseite einer Kategorie (14) auch einfügen

[Alle Seiten]/wiki/14/Sitemap

Ansonsten sammle ich Wiki-Wünsche auf https://forum.church.tools/topic/7724/wiki-2-0-wünsche?_=1637932168099 und bin für Votes dankbar

sp0ken

@bwl21 wie bzw wo genau machst du das? Wir hosten CT nicht selber, nur so als Info. Bin noch ein Leihe was CT angeht. Und wir nutzen kein Markdown bisher.

Bringen die Votes überhaupt was? Sorry für die kritische Frage, hab das Forum nur mal bisschen durchstöbert und da ist bei mir so der Eindruck entstanden.

VG

Andy

@sp0ken sagte in Das neue Wiki ist da - Livestream heute um 20 Uhr:

Bringen die Votes überhaupt was?

Ja, doch. Aber der Prozess ist manchmal lang. Dennoch ist jede Anregung hier wichtig und sinnvoll.