Das neue Wiki ist da - Livestream heute um 20 Uhr

rheimlich

Vielen Dank für das neue Wiki und den gerade durchgeführten Livestream. Das Wiki sieht jetzt deutlich ansprechender aus. Etliche Dinge sind einfacher geworden.
Anscheinend besteht Bedarf für einen Wiki-Editor mit rudimentären Funktionen (Markdown). Wenn dem so ist, ist das als zusätzliches Angebot ok.
Wir nutzen das Wiki schon einige Zeit, um Informationen zentral bereit zu stellen. Ich habe versucht, bestehende übersichtliche Seite zu Markdown zu konvertieren. Das Ergebnis war - vorsichtig formuliert - nicht schön.
Das geht mit dem HTML-Editor besser.
Dass die Strategie dahin geht, irgendwann mal nur noch auf Markdown zu setzen, "ängstigt" mich. Ich möchte gerne einfach mein Wissen in einer für den Leser ansprechenden Weise teilen. Dafür möchte ich nicht unnötig viel Zeit mit dem Editieren verbringen müssen.
Das Vergrößern des Editorfensters hat dafür dankenswerterweise den Editierkomfort wieder verbessert.
Vielen Dank.

davidschilling

@rheimlich bisher gibt es keinen konkreten Plan HTML abzuschaulten.

Ich möchte gerne einfach mein Wissen in einer für den Leser ansprechenden Weise teilen. Dafür möchte ich nicht unnötig viel Zeit mit dem Editieren verbringen müssen.

Ich würde sagen genau dafür ist der Markdown Editor da. Es geht nicht darum wie genau etwas aussieht, sondern, dass man strukturiert Text ablegt der von anderen gelesen werden kann. Wie groß der Text genau ist und wie er hervorgehoben ist spielt da eigentlich keine Rolle. Darum sollte ich mich als Editor gar nicht kümmern müssen. Ich sage dem System nur, dass es hervorgehoben werden soll und dass etwas eine Überschrift ist und wie genau es dargestellt wird, darum kümmern wir uns.

Hast du ein paar Beispiele warum du so im Detail formatieren möchtest?

rheimlich

@davidschilling
Ein typisches Beispiel ist das Arbeiten mit Tabellen. Wir nutzen Tabellen zur strukturierten Abbildung von Protokollen, ToDo-Listen etc.. Diese enthalten z.B. Spalten für Themengebiet, konkreter Punkt, Zuständigem, Status.
Oder für Listen verschiedener Art, z.B. die Liste von Gastpredigern mit Name, Adresse, Telefon, Zusatzinfos...
Farbe nutzen wir für das Hervorheben von Inhalten.
Protokolle schreiben wir gerne live in der Sitzung. In Schwarz ist der Text der vorher erstellten Tagesordnung. In Farbe werden in der Sitzung als Protokoll Einträge hinzugefügt.

davidschilling

@rheimlich Tabellen sind ja auch in Markdown möglich. Der neue Editor ist da sicher noch nicht perfekt in der Benutzbarkeit aber Möglich ist das. Ein großer Nachteil von Tabellen ist die mobile Darstellung, das ist generell sehr schwer und mit anderen Formen von Text viel einfacher machbar.

Ich sehe jetzt aus meiner Sicht keine Punkte von dir bei denen Markdown nicht funktionieren würde. Für die Protokolle wollt ihr eine unterscheidung zwischen der Tagesordnung und dem Livetext, da könnt ihr fett oder kursiv nutzen.

davidschilling

@davidschilling Hier gibt es noch einen Blog-Post der die Features des Wiki nochmal zusammenfasst: https://blog.church.tools/blog/das-neue-wiki-ist-da/

hbuerger

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

Oder für Listen verschiedener Art, z.B. die Liste von Gastpredigern mit Name, Adresse, Telefon, Zusatzinfos...

Nur als kleiner Einschub: Ich hab das auch bei anderen schon gesehen, dass sie im Wiki Personendatensätze ablegen. Allerdings haben wir dafür ja das Modul Personen & Gruppen.

Wir (in meiner Gemeinde) legen Gastprediger auch als Personen an und haben eine Gastprediger-Gruppe. So können wir die Personen bequem in der Dienstplanung berücksichtigen. Manche Gastprediger sind sogar sooft da, dass sie einen eigenen Zugang haben und wir können so bequem die Adressdaten, Telefonnummer, etc. dort pflegen, wo es Sinn macht.

rheimlich

@davidschilling
Der Grundgedanke eines Wikis und gerade eines Wissensmanagements in einem Wiki ist, dass viele Anwender einfach über Berechtigungen gesteuert auf zentral abgelegte Informationen zugreifen (lesen und ggf. pflegen) können, die bisher vielfach in Office-Dokumenten abgelegt waren oder verschickt wurden.
Viele Lösungen, so auch hier der HTML-Editor, zeigen, dass dies ohne große Verluste in der Darstellung oder erhöhtem Pflegeaufwand möglich ist. Mir erschließt sich nicht, warum hier ein technisches Werkzeug mit spezifischem Funktionsumfang (Markdown-Seiten / -Editor) „mit Gewalt“ als geeignete Lösung für alle in diesem Kontext auftretenden Anwendungsfälle gesehen wird.
Es gibt Fälle, da ist es sinnvoll, bei optischen Hervorhebungen mehr Möglichkeiten zu haben, als fett und kursiv.
In den Infos zu Markdown wird explizit auf die eingeschränkte Tabellenfunktionalität hingewiesen. Hier ist es wohl möglich, dasselbe Ergebnis auf Ausgabeseite zu erzielen, allerdings zum Preis eines massiv erhöhten Editieraufwandes.
Software wird für Anwender gemacht, hier Editoren und Leser. Wenn für etliche Anwendungsfälle die Markdown-Technik eine gute Lösung darstellt: prima. Aber bitte erklärt darüber hinausgehende Anwenderbedarfe nicht einfach als überflüssig. Ich denke, jeder kennt Analogien aus dem sonstigen Leben, in dem er das auch nicht akzeptieren würde.

@hbueger: Der Hinweis auf die Liste der Gästeprediger ist gut. Ich denke, es ist klar, dass das Beispiel für Listen sich beliebig austauschen lässt.

MichaelG

@gmaess

Vielen Dank für das neue Wiki!!!

Ein Hinweis:

In der mobilen Ansicht ist das Scrollen noch recht fragil. Man kann nach rechts gehen, wobei man dadurch die Spalte verlässt. Ganz rechts taucht dann irgendwann das Menü auf.

URLs scheinen nicht umgebrochen zu werden (was möglicherweise mit dem oberen zusammenhängt)

(Ich kann hier leider kein gif hochladen. Deswegen als Link:
https://share.icloud.com/photos/0C9KxbiJiXve9z4USqHzAYgjw

Lässt sich aber auch gut selbst ausprobieren unter intern.church.tools)

Safari auf neuestem iOS mit Pro Plus Display Größe.

MichaelG

@gmaess außerdem hat sich die Schriftgrösse vergrößert. Ich bekomme jetzt also weniger Inhalt zu sehen und muss mehr scrollen.

Eine Möglichkeit dies per Nutzer oder per Installation einzustellen, fände ich sinnvoll

David.R

Hallo,

ich habe hier schon mal eine paar Anmerkungen und Fragen gestellt:
https://forum.church.tools/topic/7694/neues-wiki-unterkategorie/8?_=1628612823642

Ich habe noch ein paar Anmerkungen hier in der größeren Runde:
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.

Wie in dem Link oben möchte ich hier mal direkt fragen, warum man nicht bei jeder Seite ermöglicht einzelne Rechte zu vergeben.:
"Ich habe Anleitungen - Hätte Sie auch gern unter der Kategorie Anleitung, weil es eben da logisch ist. Jetzt muss ich unterscheiden, ob die Anleitung sich an einen neue Interessent oder Freund oder die GL richtet.
Ich müsste jetzt also eine Kategorie Anleitung GL,
Eine Kategorie Anleitung Freunde,
Eine Kategorie Anleitung Mitglieder ... erstellen.
Weil: ein Teil der Anleitungen sind eben nur für die GL bestimmt, eine Teil ist eher auch für Neue bestimmt. OK da macht es nichts, wenn es auch die GL ließt, aber es macht es eben total unübersichtlich. Wie soll wer wissen wissen, wo er jetzt Anleitungen findet.
Oder muss ich der GL zumuten alle Kategorien durchzublicken um dann irgendwo die Anleitung zu finden? Ja es gibt die Suche, aber die Grundstruktur ist doch so schon völlig daneben.
Oder muss ich alle Anleitungen jeweils in jede für sie notwendige Kategorie einstellen?

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?

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