Das neue Wiki ist da - Livestream heute um 20 Uhr

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

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.