Mini-Prototyp

In der Hoffnung, dass es uns in der Diskussion voranbringt, hier ein Mini-Beispiel: https://dry-fortress-03113.herokuapp.com/needs/

Bei der ersten Benutzung müsst ihr die Seite möglicherweise mehrmals neu laden. Bitte hinterlasst dort keine sensiblen Daten, es ist ein Wegwerf-Prototyp, der keinerlei Sicherheitsanforderungen erfüllt. Ihr dürft aber gute ausgedachte Dinge eintragen (möglichst nicht „sdfsdf“), damit wir ein halbwegs realistisches Gefühl für das System bekommen.

Der Quelltext ist hier zu finden:

2 Like

Cool! Finde ich wirklich sehr praktisch als Diskussionsgrundlage! Da stellt sich mir etwa direkt die Frage nach dem Zusammenhang zwischen bestehenden Tätigkeitsmustern und der freien Vermittlung von Bedürfnissen - echt schön.

Vielen Dank dafür!

Fügt gerne noch ein paar Dinge hinzu. Einige Funktionen offenbaren sich erst, wenn man versucht, etwas zu tun. Beispielsweise sind die Muster so gar nicht sichtbar. Sie sind aber da.

Dann würde mich sehr interessieren, was ihr als erstes und vielleicht auch zweites verbessern würdet, um die Benutzbarkeit dieser Mini-Demo zu verbessern.

@LaMarta, erkennst du dein Konzept zumindest teilweise wieder? Bekommst du ein Gefühl dafür, ob es irgendwo falsch modelliert sein könnte?

Die Frage verstehe ich leider noch nicht, kannst du sie erläutern?

Mir sind bei der Entwicklung eine Menge Dinge bewusst geworden: Es gibt nun ein Kern-Datenmodell, welches die wesentlichen Dinge miteinander in Beziehung setzt. Es lassen sich Module identifizieren und damit auch Schnittstellen definieren.

Und aus Sicht der Benutzerschnittstelle: Ich kann genau drei Dinge in zwei Gruppen sehen, die ein Mensch auf so einer Plattform machen möchte:

  • Bedürfnisse äußern
  • Beitragen:
    • Tätigkeiten zur Durchführung/ Mitwirkung auswählen
    • Mittel zur Bedürfnisbefriedigung bereitstellen

Das sollte das UX-Design berücksichtigen, diese drei Dinge sollten sehr gut und auf mehreren klaren Wegen zugänglich und hürdenarm benutzbar sein.

Alles andere sind aus meiner Sicht eher administrative Aufgaben, die entweder dem Aufbau der Plattform dienen oder sowieso halb- oder vollautomatisch ablaufen könnten. Sie werden wohl eher von den versierteren Nutzer_innen ausgeführt werden.

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 Like

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 Like

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 Like

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.