Mini-Prototyp

Diese Stelle ist übrigens interessant:

https://dry-fortress-03113.herokuapp.com/needs/3/

Ein Bedürfnis oder Bedarf wird entweder von einem Mittel oder von einer Tätigkeit, die ein passendes Mittel erzeugt, befriedigt/ gedeckt. Insofern sind die Vorschläge auf der Seite oben als entweder-oder-Liste zu verstehen. Und keiner der Vorschläge würde das Bedürfnis nach dem Holzhaus befriedigen: Der Hammer nicht und die vernagelten Bretter vermutlich auch nicht.

Ich kann ja mal einen weiteren Vorschlag probieren.

1 „Gefällt mir“

Danke. Ich habe jetzt noch Bretter den Mitteln hinzugefügt. Lässt sich das Holzhaus nun bauen?

Wir hatten vor einer halben Dekade auch einmal versucht ein Vokabularium von möglichen Bedürfnissen zu erstellen. https://wiki.openstreetmap.org/wiki/Proposed_features/TransforMap#Needs_fulfilled_by_a_community. Solch eine Datensammlung ließe sich aber sicherlich besser in etwas wie Wikidata oder einer separaten Wikibaseinstanz abbilden.

Danke, dass du das ausprobierst und wir solche Stellen finden.

Das ist wirklich interessant. Es ist ein Verständnisproblem. Dass meine schäbige Oberfläche das Problem nicht lösen kann, ist mir sofort klar. Und zukünftig soll das ja eher zumindest teilweise automatisch passieren.

Also: Bretter sind kein Holzhaus. Daher werden sie auch das Bedürfnis nach einem Holzhaus nicht decken können. Dass sie dafür möglicherweise gebraucht werden, steht auf einem anderen Blatt. Bzw: Ich habe ein einfaches Muster erzeugt, welches tatsächlich so etwas wie ein Holzhaus hervorbringt und dafür Bretter braucht:

https://dry-fortress-03113.herokuapp.com/activities/5/

Ha, sehr interessant und aufschlussreich, dein Prototyp @balkansalat! Aber gar nicht so einfach, wenn man etwas neues erfassen will, beispielsweise ein Muster, wirklich das Muster zu beschreiben und nicht die dafür nötigen Mittel…

Hat leider etwas gedauert, bis ich den Kopf dafür frei hatte - Verzeihung!

Ich glaube aber, das Programm hängt. Ich habe jetzt ein Bedürfnis eingespeist und ich finde es erstmal sehr cool, dass sich sowohl Tätigkeiten als auch Mittel vorschlagen lassen, die das Bedürfnis befriedigen. Das ist cool! Jetzt würde ich aber gerne eine Tätigkeit definieren, die aus bestimmten Mitteln ein bestimmtes Mittel hervorbringt - und das geht nicht. Also ich schaffe es nicht zu den Tätigkeitsmustern zu kommen. Intuitiv würde ich jetzt auf den „Mehr“-Button gehen und dann auf „Mittel“ und dann hoffen, dass da ein „Tätigkeiten, die das Mittel hervorbringen“-Schaltfeld ist. Aber die Software reagiert weder auf die „Mittel“ noch auf die „Muster“ Schaltfläche. … das sollte sie aber, oder?

Ich erkenne das Konzept wieder und mag den Ansatz. Jetzt bin ich aber erstmal auf die Muster gespannt :slight_smile:

Und was natürlich ein wenig struggelt: Es gibt jetzt zum Beispiel das Bedürfnis „Brottaig“ - was spannend ist, da es natürlich als Bedürfnis „falsch“ erscheint. Taig ist kein Bedürfnis, sondern ein Mittel zur Befriedigung eines Bedürfnisses. Genauso wie das Holzhaus etc. Aber anderseits würde ja die Vermittlung von „ich würde gerne in einem Holzhaus leben“ auch schlicht auf das Mittel „Holzhaus“ verweisen und dann gibt es verschiedene Möglichkeiten, dieses Bedürfnis zu befriedigen indem genau dieses Mittel für diese Person verfügbar gemacht wird (was natürlich nicht nur die Produktion ist - vielleicht steht ja irgendwo eines). Ist das jetzt problematisch, konkrete Mittel wie Bedürfnisse zu vermitteln? Ich würde sagen, dass es zumindest die Möglichkeiten der Befriedigung des Bedürfnisses einschränkt. Vielleicht gibt es „hinter“ der Vorstellung, in einem Holzhaus zu leben, das Bedürfnis nach einem Rückzugsort und das lässt sich auf sehr viel mehr verschiedene Arten befriedigen.

Jetzt wird es ein wenig wild, aber ich folgt dem mal: Die Software ist ja kein Psychotherapeut, der helfen kann, sich seinen wirklichen Bedürfnissen bewusst zu werden. Aber vielleicht lassen sich (irgendwann) an bestimmte Mittel Vorschläge hängen, die an ein möglicherweise dahinterstehendes Bedürfnis verweisen. Wenn zum Beispiel das Mittel „Holzhaus“ vermittelt wird, könnte die Software vorschlagen: „Meinen Sie vielleicht einen Ort der Ruhe?“ oder „Meinen Sie einen Ausflugsort?“. Oder auch einfach: „Meinen Sie das als dauerhaften Wohnsitz?“. Das Holzhaus wäre ja nach dem Commoning-Prozess kein privates Eigentum der Person, welche das Bedürfnis danach vermittelt hat. Es muss auf jeden Fall noch irgendwie klarifiziert werden, was die Person überhaupt möchte.

Ich hoffe, die Person, welche das Holzhaus angegeben hat, fühlt sich gerade nicht angegriffen :wink: . Aber grundlegend geht es darum, dass ein Bedürfnis mit einem Mittel befriedigt werden kann, aber kein Mittel ist. Die Frage ist, ob wir die Möglichkeiten der Vermittlung einschränken müssen - aber ich glaube fast, das dem nicht so ist. Das könnte sich vielleicht auch dadurch ergeben, dass je offener ein Bedürfnis vermittelt wird, es immer mehr Möglichkeiten der Befriedigung gibt und diese Befriedigung damit wahrscheinlicher wird. Die Person also lernt, wie sie Bedürfnisse zu vermitteln hat, damit diese tendenziell auch befriedigt werden. - Würde ich jetzt aber noch keine Hand dafür ins Feuer legen.

Das ist ja genau, was du durch Zuordnung gelöst hast. Jemand vermittelt ein Bedürfnis, jemand anderes liest das aus und sagt: so und so lässt sich das befriedigen. Also zum Beispiel durch eine Tätigkeit, zum Beispiel durch ein Mittel. Und durch die freie Zuordnung wird das Bedürfnis mit den Tätigkeitsmustern zusammengebracht.

Vielleicht braucht es ja eine Funktion, um das abzustimmen:

  • Person A: „Ich habe dieses Bedürfnis“
  • Person B: „Das lässt sich mit xyz befriedigen“
  • Person C: „Das lässt sich durch abc befriedigen“
  • Person D: „Das lässt sich mit kjl befriedigen“
  • Wieder Person A: „Das Bedürfnis lässt sich mit xyz und mit kjl befriedigen, aber nicht durch abc

Damit hätten wir am Ende ein besonderes Bedürfnis und definierte Mittel und Tätigkeiten, welche das Bedürfnis befriedigen. Vielleicht haben wir damit ein … Bedürfnis-Muster? Eine wiederkehrende Art von Bedürfnis, das sich über verschiedene Möglichkeiten befriedigen lässt?

PS: Achja, fand ich übrigens sehr nett, dass du das „horicon“ genannt hast. Ich musste schmunzeln!

Aus euren Antworten kann ich schön ablesen, an welchen Stellen die Mini-Demo als nächstes erweitert werden sollte. Wenn ihr nichts dagegen habt, würde ich demnächst versuchen, da noch ein paar Schritte zu gehen und anschließend die Diskussion weiterführen.

Es kann dabei passieren, dass über die Wochen und Monate aus dem Wegwerf-Prototyp etwas wird, was wir nicht mehr vollständig wegwerfen wollen. Die Benutzeroberfläche vermutlich schon, aber andere Teile könnten möglicherweise länger bestehen. Haben andere von euch Ambitionen, etwas einzubringen? Sollten wir jetzt schon versuchen, einige der Module mit anderer Software zu verknüpfen? Ich denke da an Web of Needs (@fkleedorfer) oder Schnittstellen wir die Commons API, Wikidata oder externe Musterspeicher.

Habt ihr Vorstellungen, was Sprachen und Technologien angeht? Bisher ist es sehr schlicht Python und Django ohne weitere Abhängigkeiten, weil ich da augenblicklich am flüssigsten bin. Ich könnte das auch leicht ändern, wenn es für jemand den Zugang erleichtert. @almereyda hat einen schönen Post geschrieben, den ich von Zeit zu Zeit zu Rate ziehen würde:

Einiges davon ist bereits erfüllt, mit anderen Dingen muss ich mich erst beschäftigen. Oder andere Menschen bringen etwas ein.

Um transparent zu machen, was ich gerade mache oder noch machen möchte, würde ich nun anfangen nach Tickets zu arbeiten:

Langfristig wünsche ich mir, dass die Tickets als (Meta-)Bedürfnisse/-Bedarfe in der Software selbst existieren, so dass Menschen, die die Software voranbringen, klarerweise zur Bedürfnisbefriedigung beitragen. Genau wie solche, die organisatorische Aufgaben übernehmen oder Texte schreiben. Das meine ich mit der Idee des „Bootstrapping“.

1 „Gefällt mir“

Du meinst wahrscheinlich zum einen, dass die Benutzeroberfläche nicht besonders angenehm zu bedienen ist. Das ist leider so. UI-Entwicklung ist sehr aufwändig und ich kann es nicht. Ich kann nur etwas sehr Einfaches bereitstellen. Sobald sich Menschen finden, die das machen möchten, kann ich zusätzlich beispielsweise eine sogenannte REST-API bereitstellen. Auf dieser Grundlage lässt sich dann eine komfortable Benutzerschnittstelle erzeugen.

Zum zweiten gibt es nur ein sehr einfaches Datenmodell. Ein Tätigkeitsmuster besteht ja grob aus drei Teilen (siehe auch Textreihe):

  • Der Art des Mittels (Konzept, siehe), welches dieses Muster erzeugt, also das Ergebnis (noch nicht implementiert, siehe #4).
  • Der Musterbeschreibung. Diese besteht augenblicklich aus einem simplen Titel und Text. Wenn ihr denkt, dass es jetzt schon sinnvoll ist, hier mehr Struktur reinzubringen, dann gebt mir gerne Vorschläge.
  • Die Liste der Arten von Mitteln (Konzepte), die gebraucht werden (Bedarfe), wenn die Tätigkeit nach diesem Muster ausgeführt wird.

Ich denke, wir merken an diesen Stellen sehr schön (wie auch oben), dass die Benutzeroberfläche sehr viel Erklärungsarbeit leisten muss. Am besten muss das alles so intuitiv sein, dass Menschen das Konzept (wie Muster, Mittel und all diese Dinge zusammenhängen) zunächst gar nicht verstehen müssen, sondern die einfachen Dinge erst mal benutzen können, ohne Fehler zu machen.

Hier gibt es nun seit eben die Liste aller Muster, sozusagen der simple Musterspeicher:

https://dry-fortress-03113.herokuapp.com/patterns/

Funktionen wie bearbeiten oder löschen oder auch die Sortierung von Listen habe ich bisher ausgespart. Einiges kann ich auf Wunsch auch von Hand löschen oder gebt mir Hinweise, wenn an manchen Stellen diese Funktionen dringend wünschenswert sind.

Nur der eine Einwurf gerade: Die Tätigkeiten in der Liste, sind keine Tätigkeitsmuster im Sinne des Softwarekonzepts. Für solche braucht es ein klar definiertes Resultat. Also „Die Außenwand einer Holzhütte bauen mit [a] Nägeln und [b] Holz“ statt „Holzbretter vernageln“

Zu dem fehlenden Resultat hatte ich oben geschrieben:

Falls es das ist, was du meinst, dann kommt das also demnächst.

Das ändert nichts daran, dass Menschen beliebige Dinge formulieren können. Über das Muster Holzbretter vernageln hatten wir oben auch bereits diskutiert.

Ich denke, dass sich die Qualität des Musterspeichers zukünftig aus mindestens zwei Dingen ergeben wird, die gerade noch nicht vorhanden sind:

  1. Es werden nur Muster angezeigt, die mindestens einmal in einem erfolgreichen Commoning-Prozess verwendet wurden. Bisher können CPs weder aktiviert noch abgeschlossen werden.
  2. Die Muster selbst werden ja mindestens ein Qualitätskriterium erhalten. Muster mit geringer Qualität tauchen in solchen Listen typischerweise so weit hinten auf, dass sie einfach nicht mehr auftauchen.

Nein, die beiden Seiten gibt es erst seit heute. :slight_smile:

Tätigkeiten kannst du auf der Seite eines Bedürfnisses vorschlagen.

Damit du explizit angeben kannst, welches Mittel ein Tätigkeitsmuster hervorbringt, muss ich erst #4 implementieren.

Das ist interessant. Ich kann mir vorstellen, dass das ein langwieriger Lernprozess sein könnte. Ich bin es gewohnt, das Produkt, welches ich im Supermarkt einkaufe, als „Bedürfnis“ wahrzunehmen. Wir hatten über dieses Thema auch schon mal im Gitlab diskutiert, glaube ich. Ich kann mir vorstellen, dass wir über eine Diskussionsfunktion (Kommentare oder so) unter einem Bedürfnis zunächst die Möglichkeit schaffen können, dass Menschen die Bedürfnisse hinter den Mitteln finden. Falls sie das wollen und sich das positiv auswirkt.

Es heißt auch, dass ein Bedürfnis nach „Ruhe“ auf verschiedene Arten befriedigt werden kann: Beispielsweise durch einen Raum mit Tür oder durch Kinderbetreuung. Ein Bedürfnis kann also nach mehreren Arten von Mitteln fragen. Auf den Gedanken bin ich bei der Modellierung bisher noch nicht gekommen.

Ja, das kann ich mir so vorstellen.

Also vielleicht: Ein konkretes Mittel deckt einen konkreten Bedarf einer Tätigkeit. Diese Tätigkeit bringt wiederum ein konkretes Mittel hervor. Dieses Mittel befriedigt ein konkretes Bedürfnis.

Und analog: Eine bestimmte Art von Mittel (Mittelmuster) wird einem Bedarfsmuster zugeordnet. Das Bedarfsmuster ist quasi ein Teil eines Tätigkeitsmusters. Ein Tätigkeitsmuster beschreibt eine Tätigkeit, welche eine bestimme Art von Mittel (Mittelmuster) hervorbringt. Und eine solche Art von Mittel wird wiederum einem Bedürfnismuster zugeordnet.

Das sind die gleichen Verbindungen, einmal auf der konkreten Ebene und einmal auf der abstrakten Klassen- oder Meta-Ebene.

  • Tätigkeit -> Mittel -> Bedürfnis*
  • (Tätigkeits-)Muster -> Art von Mittel (Mittelmuster, Klasse, Konzept) -> Bedürfnis*muster

Auf der abstrakten Ebene müssen wir uns noch auf Begriffe einigen.

Sorry :slight_smile:

Spannender Gedanke. Das könnte wirklich erst einmal funktionieren, aber auch etwas befremdlich, wenn meine angegebenen Bedürfnisse öffentlich diskutiert werden. Wahrscheinlich ist hier wirklich das „falls sie das wollen“ sehr relevant.

Schönes Beispiel. Besonders zeigt sich, dass hier ein „Bedürfnismuster“ Unsinn wäre, da sich das Bedürfnis nach Ruhe nicht immer gleich befriedigen lässt. Damit könnte das …mh… tiefe (?) Bedürfnis Ruhe eine Kategorie darstellen, die sich in immer konkretere Äste aufgabelt. Vielleicht kann ich als Anwenderin diesen Weg gehen so lange er mir sinnvoll scheint. Also entweder einfach sagen „Bedürfnis: Ruhe“ oder „Bedürfnis: Ruhe: Kinderbetreuung“ oder „Bedürfnis: Ruhe: Kinderbetreuung: integrativer Kinderhort mit ausgebildeten Erziehern“.

Falls wir das ausprobieren wollen, müssen wir bestenfalls einen Weg finden, wie sich die Grundbedürfnisse und die untergeordneten Kategorien dezentral und im Prozess herausstellen können. Und im Notfall vielleicht so lange vorgeben.

Gibt es einen Grund, warum du das Mittelmuster und Bedarfsmuster trennst? Das Prinzip ist ja, dass Resultat des einen Tätigkeitsmusters und Bedarf des darauf folgenden identisch sind. Ich kann mir allerdings vorstellen, dass die Definition der Mittelmuster das doch nochmal differenziert - was allerdings auf jeden Fall die Sache komplizierter macht.

Falls es bei den Begriffen „Klasse“ und „Konzept“ ebenfalls darum geht, die Nützlichkeit eines Dings virtuell verarbeiten und organisieren zu können (also die elektronische „Hülle“ eines häufiger vorhandenen materiellen Mittels), dann kommen wir meiner Meinung nach um den Begriff Muster von Mitteln nicht herum. Beziehungsweise diesem unsagbar furchtbaren Begriff „Mittelmuster“. Alles andere würde m.M.n. die Diskussion verkomplizieren, davon ablenken, worum es bei dem Begriff geht, und womöglich an der ein oder anderen Stelle die Diskussion in eine viel abstraktere Richtung laufen lassen, als es notwendig ist.

Wir können das natürlich an entsprechender Stelle neu diskutieren.

Auch wenn wir nicht gleich zu Anfang Bedürfnismuster einführen, werden wir auf die Notwendigkeit solcher Verbindungen zwischen Kategorien stoßen. @fkleedorfer und @almereyda kennen sich da -glaube ich- gut aus. Das sind Dinge aus dem Semantic Web, ich glaube der passende Begriff ist Taxonomie. Am Beispiel des Kinds lässt sich sehen, dass es vielfältige Beziehungen zwischen Klassen geben kann.

Auch für Mittelmuster und Fähigkeiten (Tätigkeitsmuster) werden wir (oder entsprechende andere Software, die diese Aufgabe übernimmt) solche Taxonomien verwenden wollen, wenn wir eine automatische Zuordnung ermöglichen wollen.

1 „Gefällt mir“

Ich schlage vor, wir trennen sie erst mal nicht und wir schauen, ob sich irgendwann die Notwendigkeit für eine Trennung ergibt.

Wie gehts dir eigentlich hierbei, @balkansalat? Ich habe das in letzter Zeit aus den Augen verloren.

Ich arbeite kontinuierlich ein wenig daran. Leider habe ich wegen Lohnarbeit, bei der ich ebenfalls stundenlang am Schreibtisch am Rechner sitze, nur wenig zusätzliche Energie dafür.

Gerade eben habe ich etwas fertiggestellt, was mir sehr wichtig ist: Besser sichtbar zu machen, was ein einfacher Nutzer am Anfang tun kann (und sollte). Dafür gibt es zwei neue Seiten:

Übersichtsseite „Beitragen“ (Startseite): https://dry-fortress-03113.herokuapp.com/

„Deine Bedürfnisse“: https://dry-fortress-03113.herokuapp.com/needs/user/

Ich habe schon mal danach gefragt, aber im Prinzip keine Antworten bekommen: Das Aussehen ist nicht unglaublich hübsch und die Bedienung grottig, klar. Aber was wären die wichtigsten Verbesserungen, die ihr am liebsten gleich als nächstes hättet, damit wir besser daran Dinge demonstrieren können?

Deswegen hatte ich nachgefragt - ich habe das Gefühl, dass ich in vielleicht mehr als den Thread abgelenkt war und Fragen vielleicht offen stehen. Erinnere gern bei sowas einfach nochmal daran - fände ich mehr hilfreich als aufdringlich.

Die Sache ist, dass ich immer super schnell die Übersicht verliere, wenn ich den Prototyp ausprobiere und versuche mich hineinzudenken. Ich habe auch wirklich lange jetzt wieder gebraucht, um zu verstehen, dass das was im Muster als „Bedürfnis“ angegeben ist, eigentlich der Bedarf ist (oder?).

Ich würde mir wünschen, dass die Muster klarer sind und wir vielleicht auch einfach mal definieren, wie so ein Muster aussehen muss.

An der Stelle: Es gibt ja eigentlich schon eine Seite, die ich selbst immer wieder vergesse, aber die ja tatsächlich Tätigkeitsmuster anbietet und an der wir uns orientieren können, wenn nicht sogar auf Dauer eine Kooperation möglich ist. Ich bin über Zufall wieder darauf gekommen, nachdem ich auch ein wenig hamstern wollte und mich mit Wein eingedeckt habe… :slight_smile:

So wie ich das dort überblicke: Mustername, dann die verschiedenen Möglichkeiten mit eindeutiger Tätigkeitsbeschreibung, Tipps zum Vorgehen (Was ich auf Dauer auch gut finde - aber natürlich nicht wesentlich für die Struktur) und zuletzt ist der Bedarf angegeben („Was brauchst du dafür?“). Achja: Und Referenzen. Klar, ist jetzt viel das Design, was das ausmacht, aber für die Orientierung ist das gut. Die Frage ist, was wir jetzt mit dem Prototyp machen, um Übersicht zu gewinnen.

Was ich als Ziel sehe wäre eine Ansicht für die Konfiguration. Also mehrere miteinander verbundene Tätigkeitsmuster und das möglichst übersichtlich. Wie kriegen wir das hin? Was brauchen wir dafür?

Ich habe so ein wages Gefühl, dass wir im gitlab schon einmal über Muster-Design gesprochen haben, aber finde das gerade nicht mehr -… vielleicht auch gar nicht so wichtig und wir können das schnell und besonders auf den Prototyp zugeschnitten neu erschließen.

Was braucht ein Tätigkeitsmuster grundlegen?

Mustername: Der Mustername ist in der Softwarekonzept-Textreihe eindeutig definiert, z.B. „Herstellung einer Leinwand mit einem Handtacker, Leinengewebe, Keilrahmen und Tackerklammern“. Also erst die Tätigkeit (Produktion/Transport/Erziehung/etc.), dann das Resultat und dann der aufgelistete Bedarf. Vielleicht sollten wir das im Prototyp auch übernehmen.

Tätigkeitsbeschreibung: Welche Schritte sind notwendig? (passt ja gerade im Prototyp)

Resultat: Das resultierende Mittel bzw. die dadurch entstehende Bedürfnisbefriedigung eindeutig definieren (das fehlt noch, oder?)

Bedarf: Die notwendigen Mittel eindeutig definieren.

… das wars vermutlich schon. Und die Muster von Mitteln brauchen ja meiner Meinung nach gerade nur den Musternamen und die Mittelbeschreibung, wie sie ja bereits bei dir angelegt ist.

Um ehrlich zu sein, würde ich gerade richtig gerne konstruktiv daran weiterarbeiten, aber ich kann mich super schwer gerade hineindenken. Ich frage mich nur, woran das liegt; die Funktionen sind ja eigentlich da. Teilweise denke ich liegt das wirklich daran, dass die Muster nicht eindeutig beschriftet sind - vielleicht würde ein wenig „saubermachen“ gerade helfen. Im Idealfall dann ein „Musternamengenerator“, der den Namen eben aus Art der Tätigkeit, Resultat und Bedarf zusammenbaut.

Doch, das ist wirklich mein Wunsch. Also nicht unbedingt der Generator, aber erst einmal die eindeutige Definition der Namen von Tätigkeitsmustern. Und die Übersicht von Resultat/Bedarf in den Tätigkeitsmustern. Und auf Dauer eine Ansicht von Konfigurationen. Letzteres ist wahrscheinlich aber gar nicht so einfach, oder?

Danke für deine Antwort, die gibt mir den gewünschten Input. Ich möchte auch alle anderen ermuntern, Antworten zu schreiben. Wenn ihr bei der Benutzung des Mini-Prototypen entnervt aufgebt, dann ist das genau die Stelle, an der ihr hier ablegen könnt, was die größten Hürden waren. :slight_smile:

Ich habe mich schon gewundert, dass du nicht früher darüber gestolpert bist. Da das technisch nah beieinander ist, habe ich das bisher (fast) nicht getrennt. Ich nehme an, dass die wenigsten Menschen den Unterschied verstehen werden, weil wir das ja im allgemeinen Sprachgebrauch nicht so wie im Konzept verwenden. Mit #11 werde ich versuchen, die beiden Worte so gut wie möglich zu trennen.

Interessant, das ist nicht so super kompliziert ich würde es bei Gelegenheit mit #12 mal ausprobieren. Ich bin mir nicht sicher, ob dieses strenge Namensschema etwas verbessert. Aber lass es uns gerne ausprobieren. Grammatik wird die Software aber nicht können, die Titel werden also etwas holprig klingen. Und in einigen Fällen sehr lang werden, besonders wenn es viele Bedarfe mit langen Namen gibt.

So? https://dry-fortress-03113.herokuapp.com/patterns/

Ist das nicht schon umgesetzt? Wenn dir etwas fehlt, poste doch mal den Link, damit wir über die gleiche Stelle sprechen. Ich sehe das beispielsweise hier:

https://dry-fortress-03113.herokuapp.com/patterns/1/

Interessant ist das. :slight_smile: Ich mache mir in #13 darüber Gedanken und probiere mal was, das können wir dann diskutieren.