Stabilität von Extensions und deren Updatefähigkeit

[Hendriks]

Möchte noch einmal für WorkFlowy (nein, ich bin nicht von denen zur Akquise beauftragt worden..) als einfache, und genau deswegen gute Lösung zur Visualisierung von Struktur-Daten appellieren.

Sehe gerade, dass sich die Listen auch mobil auf kleinen Screens ziemlich cool bedienen lassen.. Klar, das ist kein zentrales, aber heute mehr denn je ja schon auch ein Argument.

Bin halt irgendwie gerade generell davon begeistert - von der radikalen Einfachheit und Zweckmäßigkeit. Man hat eigentlich alles, was man braucht: einen Breadcrumb (Wo bin ich), darin enthalten Back-Links (wie komme ich zu höheren, logischen Ebenen zurück), frei wählbarer Fokus auf den Bereich des Interesses,... Inhalt, Struktur und "Menüführung" in einem. ..und.. weitgehend auto-didaktisch! ; o )

Gut, für eine richtige Wiki-Doku oder eben das Feature-Log ist es vielleicht eher nix, aber für diese Art von Setup-Referenz, wie ich sie (auch) vorschlage, why not?

Siehe: https://workflowy.com/shared/a09a2a1...5-8ecabf3b8c05

Unabhängig davon, so ist es einfach ein super Tool um auch sehr tiefe Gedanken-/ Projektstrukturen zu erfassen, zu verwalten und (auch) teilen.. In der Art und so konsequent und benutzerfreundlich kannte ich so ein Tool zumindest (bis vor kurzem) noch nicht.. Und neben Tabellen regieren ja nun mal Listen die Welt.. ; o )

[folkfreund]

... wie man eine gescheite Navi-Übersicht (oder Sitemaps nach Kategorien) generiert.

Hallo Luis,
automatisch generierte Navis werden wohl nie die optimale Struktur für alle Fälle darstellen.

Aber im Wiki lassen sich ja beliebige (Navigations-)Seiten erzeugen, deren Inhalt einfach die jeweils gewünschten Links enthält. Die Wiki-Navi am linken Rand ist auch nur eine Wiki-Seite, die mit "irgentwelchen Tricks" immer dort zu sehen ist.

Also müsste es auch möglich sein, so einen Baustein für die MM-Doku zu erstellen und irgendwie auf allen/bestimmten Seiten einzublenden.
jQuery müsste auch gehen - aber solche Erweiterungen kann bestimmt nur der Wiki-Admin machen.
Wer ist das eigentlich?

Gruß, folkfreund

[andreasisaak]

Wie der Zufall es will - xtra
Ich werde mir im Laufe der nächsten Tage auch mal nen Admin Zugang besorgen und dann schauen was sich machen lässt.

[luis]

Aber im Wiki lassen sich ja beliebige (Navigations-)Seiten erzeugen, deren Inhalt einfach die jeweils gewünschten Links enthält.

Du meinst solche Naviseiten wie bei Avisota,... mit Kategorien, Unterkategorien, Unter-Unterkategorien, Unter-Quer-Rüberkategorien? Mit Verlaub, das ist doch Pipifax. ;-)
Bevor ich hier so ne Klickerei verquante, knie ich mich lieber nochmals ins Wiki für Wiki und find heraus, was sich navi-mässig aus diesem System rausquetschen lässt. Ausser Grandmaster xtra zaubert hier ex-und-hopp ne hübsche Lösung aus dem Hut.

[folkfreund]

Du meinst solche Naviseiten wie bei Avisota,... mit Kategorien, Unterkategorien, Unter-Unterkategorien, Unter-Quer-Rüberkategorien? Mit Verlaub, das ist doch Pipifax. ;-)

So ist das natürlich nicht schön!
Wollte nur sagen, dass eine 'generische' Lösung, egal nach welchen Kriterien, für die Dokumentation eines so komplexen Projektes wie MM auch nicht zum Ziel führt.

Unabhängig davon wäre es für das Wiki allgemein sicher eine Bereicherung, wenn lange Beschreibungen so gegliedert werden könnten, dass Details zunächst ausgeblendet wären. Das ist vermutlich auch die Idee von Luis: Detailbeschreibung in zugeklapptes Akkordeon oder in eigene Seite auslagern, die dann in einer Lightbox angezeigt wird.

Zunächst möchte ich mich aber timbec anschließen:

Wichtiger ist es, das wir uns auf einheitliche Strukturen einigen und überlegen, was wirklich Sinn macht dokumentiert und beschrieben zu werden.

Ich hab da so eine Lose Liste im Kopf:

• Dokumentierte-Demo Installationen (im Wiki haben wir ja schon eine, die offizielle Demo könnte man dann auch mal angehen)
• "Baustein-Doku" (abgekoppelt von der Doku: Was ist ein Attribut? Welche gibt es? Was kann welches? Was machen Rendersettings...)
• Individuelle Templates (Beispiel-Templates die einen speziellen Use-Case abhandeln aber nicht in einem geschlossenen Kontext wie die Demo hängen)
• Codeschnippsel (Die kleinen Helfer, die man immer wieder braucht)
• Screencasts (Da bin ich grad an den ersten dran)

Die beiden ersten Punkte gibt es bereits, müssten ggf. auf den aktuellen Stand gebracht / ausgefüllt werden.
Querverweise zwischen den verschiedenen Bereichen sind jederzeit möglich (und werden bei den Beispielen ja auch bereits genutzt).
Fehlt noch was in der Liste?

folkfreund

[luis]

..., dass eine 'generische' Lösung, egal nach welchen Kriterien, für die Dokumentation eines so komplexen Projektes wie MM auch nicht zum Ziel führt.

Ich suche nicht nach einer Lösung für die gesamte Wiki-Doku, sondern nach einer besseren Darstellung einer Gesamtübersicht, die letztlich die Komplexität von MM einfach und übersichtlich darstellt. Es sollte möglich sein, einzelne Beiträge (Templatebeispiele oder CodeSchnipsel) unkompliziert an eine bestehende Ordnungsstruktur andocken zu können, ohne sich unsinnig lange Titel ausdenken zu müssen, damit gemäss Wiki-Ordnungs-Automatismus thematisch ähnliche Artikel wie in der aktuellen Kategorie-Übersicht nebeneinander zu liegen kommen. Sowas ist selbstredend Blödsinn.
Mir schwebt so was vor: mm-sitemap-idee.png
Wenn sich so was mit Wiki umsetzen liesse (ohne händische Mehrarbeit) wär das natürlich genial. Das würde auch viel mehr dazu einladen, die Lösungsansätze, Code Schnipsel, etc. hier zu dokumentieren... statt im MM Forum. Dort gehen die guten Ideen in einem Meer von Posts unter.

wenn lange Beschreibungen so gegliedert werden könnten, dass Details zunächst ausgeblendet wären. Das ist vermutlich auch die Idee von Luis...

Genau... schaumermal was Andreas oder xtra bezüglich Machbarkeit hier herausfindet.

[xtra]

Das was du mit deiner Struktur meinst, geht doch im Wiki yber Kategorien, welche frei schachtelbar sind.

Dann musst du bei einem Artikel nur sagen, dass er in die Kategorie "MetaModels" soll und z.B. auch noch in die Kategorie "MetaModels Attribute".
Dann bearbeitet man die Kategorie "MetaModels Attribute" und sagt der, sie selbst soll unter "MetaModels" drin sein, und schwupps hast du es alles...?

[luis]

Dass man nebst Artikeln auch Kategorien in Kategorien packen kann, wusste ich. Hab mal testhalber die Unterkategorie "Metamodels Basics" erstellt. Aber da wären wir dann bei der Organisationsstruktur wie bei 'Avisota'. Und das hilft nicht Übersichten zu generien. Was man bräuchte wäre so was wie nested lists... nur eine Seite zeigen, die Kategorien, Unterkategorien und zugeordnete Artikel all-in-one zeigt. Und die alphabetisch geordneten Listen helfen dann auch nicht wirklich weiter. Dann wären wir wieder dort, wo man die Kategorien im Titel mitlaufen lassen müssen, damit die Liste ne Pseudo-Struktur kriegt. Die Frage ist nun: Muss man solche Sitemaps wirklich von Hand erzeugen?

[Hendriks]

Wir koennen euch eine Featureliste nur bieten, wenn Ihr uns sagt wie die aussehen soll, am Besten ist es wenn ihr uns sagt, wie diese aussehen soll oder diese im Optimum selbst pflegt.
Am Beispiel Wiki haben wir gesehen, dass dies funktionieren kann, wenn sich einfach nur einige einbringen.
Genauso kann es auch bei einer Feature Matrix sein. Wenn jemand etwa auffaellt, dass etwas neues dazu gekommen ist, schreibt er es rein, ist etwas aktuell broken, schreibt er ein Ticket und verlinkt das dort.
So hat dann jeder direkt Yberblick was funktionieren sollte und was noch nicht da ist, aber es einen feature request gibt usw.

Tut mir leid dass ich den Ball nun an euch zuryckspiele, aber wer kann das besser beurteilen als ihr Anwender, was euch interessiert und in welcher Aufmachung das daher kommen soll.

Gruss
Chris

Ok, von mir aus... Da bin ich dabei, das ist prima – die Docs-Tabelle, die Andreas vorschlug...

Aber ist es nicht so, dass der Entwickler einer Software die Features –sowohl die anvisierten, als auch die bereits funktionierenden– selbst am besten kennt!?

Gut, bei so einer Meta-Ebenen-mäßigen Extension ist das vielleicht tatsächlich nicht so genau zu überschauen - selbst vom Entwickler selbst nicht...

Aber, dass ihr selbst den Grundstock zu dieser Feature-List legt, macht bestimmt Sinn... und dann stellt der ein oder andere Tester vielleicht noch fest: "Hey, dieses oder jenes Setting bringt übrigens noch folgendes abgefahrene Feature hervor!"

Grüße, Hendrik

PS: Und wie geht das eigentlich vonstatten, wenn man sich mal im Wiki mit einbringen würde wollen...?

[lucina]

Aber ist es nicht so, dass der Entwickler einer Software die Features –sowohl die anvisierten, als auch die bereits funktionierenden– selbst am besten kennt!?
Gut, bei so einer Meta-Ebenen-mäßigen Extension ist das vielleicht tatsächlich nicht so genau zu überschauen - selbst vom Entwickler selbst nicht...

Die Features sind doch relativ genau bekannt ... ;-) Allerdings muss man die Zeit haben um sie aufzuschreiben.

PS: Und wie geht das eigentlich vonstatten, wenn man sich mal im Wiki mit einbringen würde wollen...?

Was Du dazu tun musst, das steht auf der Startseite des Wikis (http://de.contaowiki.org/Hauptseite).

[Hendriks]

Die Features sind doch relativ genau bekannt ... ;-) Allerdings muss man die Zeit haben um sie aufzuschreiben.

Ja, da hast Du wohl recht. Wenn ich es mir jetzt gearde noch einmal genauer überlege...

Allein die genaue Benennung / Kurzbeschreibung der vielen Features... Da brüchte man ja schon fast einen professionellen (Werbe)-Texter an der Hand... Ganz zu schweigen von den detaillierten Erläuterungen und der technischen Dokumentation... Ok, ok, ich merke schon: Willkommen im Wiki!

Was Du dazu tun musst, das steht auf der Startseite des Wikis (http://de.contaowiki.org/Hauptseite).

Ah, ok... Bin selten auf der Startseite vorbeigekommen... und dann steht das ja auch noch below the fold... ; o )