Mini-Prototyp

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.

Das habe ich erledigt. Solltest jemand irgendwo noch auf eine Verwechslung von Bedürfnis und Bedarf stoßen, sagt mit bitte Bescheid.

Hier habe ich mal ein Bedürfnis eingestellt, für welches es ein passendes Muster gibt. Die Konfigurationen werden dann automatisch berechnet:

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

Ihr könnt natürlich auch selbst Bedürfnisse, Mittel und Muster ergänzen und sehen, wie sich die Dinge verändern. Ich freue mich über eine Diskussion.

Eine wichtige Frage von mir: Was fehlt noch, damit wir eine Konfiguration finden können, die freigeschaltet werden könnte? Brauchen wir dazu schon die Fähigkeiten? Auf jeden Fall einige Zahlen, richtig? Was wäre ein Minimum für den Anfang?

Ach, schön erstmal! Sehr simpler, aber cleverer Umgang mit etwas, das ich mir bisher nur grafisch vorstellen konnte. Aber echt gut!

Ich habs allerdings noch nicht selbst ausprobiert, aber das kommt noch!

Na, jetzt fehlt uns auf jeden Fall eine Datenbank über verfügbare Mittel. Was die Software ja ganz grundsätzlich auswertet ist, welche Konfigurationen im lokalen Umfeld sinnvoll sind, anhand der dort zur Bedürfnisbefriedigung verwendbaren Mittel. Der Konfigurationsprozess geht so lange, bis eine Konfiguration gefunden wurde, deren Tätigkeiten die verfügbaren Mittel zu den Mitteln umwandeln kann, die zur Bedürfnisbefriedigung notwendig sind.

Wenn wir den lokalen Aspekt und Zustand und Nutzungsbedingungen etc. erst einmal weglassen, dann brauchen wir nur eine Datenbank mit Mitteln und deren Menge.

Fähigkeiten vereinfachen Konfigurationen lediglich, indem einzelne Tätigkeitsmuster zu komplexen Tätigkeitsmustern zusammengefasst werden können. Das brauchen wir auf jeden Fall noch nicht. Eher dann irgendwann Qualifikationen, damit nur diejenigen sich den Tätigkeiten zuordnen können, die sich ihnen auch annehmen dürfen. Aber da gehts dann ja wieder um den Prozess der Selbstzuordnung.

Wenn du Bock hast, könntest du dann auch schon einen Aufwandswert zu den Tätigkeitsmustern hinzufügen - so liese sich die Prozessqualität / spekulativer Gesamtaufwand der einzelnen Konfigurationen herausstellen. Aber wirklich notwendig ist gerade nur die Mitteldatenbank.

Nachtrag: Cool, dass du auch die Musternamen angepasst hast! Das macht es meiner Meinung nach schon viel übersichtlicher.

„Fehlen“ ist vielleicht das falsche Wort. :slight_smile: Es gibt ja die Mitteldatenbank:

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

Sie ist eben nur unglaublich stark vereinfacht, aber sie ist da. Es sind noch nicht viele Mittel drin, aber ihr könnt ihr beliebig welche hinzufügen. Bliebe also die Frage, um was die Mittel mindestens ergänzt werden müssen, damit wir sinnvoll mit den Konfigurationen rumspielen können (die Betonung liegt auf „Spielen“).

Ist es also die Menge, die wir hinzufügen müssen? Dann müssten auch die Bedarfe von Mustern Mengen angeben, richtig?

Das Hinzufügen des Aufwandswerts ist einfach. Wo steht noch mal, wie sich dann die Prozessqualität/ der spekulative Gesamtaufwand für eine Konfiguration berechnet?

Du hast ja recht, sorry :slight_smile:

Genau. Und wenn die Konfiguration aktiviert wird, müssen die entsprechenden Mittel dafür reserviert werden.

Ähm… im nicht erschienen und noch nicht angefangenen fünften Teil der Textreihe :wink:

Grob soweit aber auch in Alexander 101 bei der Einführung der Qualität des Resultates und der Prozessqualität.

Prozessqualität/spekulativer Gesamtaufwand bezeichnen beide dasselbe auf verschiedenen Abstraktionsebenen („Prozessqualität“ ist tatsächlich wichtig als Begriff im Kontext des Timeless Ways). Aber im Grunde heißt es erstmal nur:

Gesamtaufwand einer Tätigkeit = Aufwand der Tätigkeit + Aufwand aller festgelegten Tätigkeiten, die für die Deckung ihres Bedarfes notwendig sind.

spekulativer Gesamtaufwand einer Tätigkeit = Aufwand der Tätigkeit + Aufwand aller Tätigkeiten, mit denen im lokalen Umfeld die verfügbaren Mittel am effizientes zur Deckung des Bedarfes der Tätigkeit verfügbar gemacht werden könnten.

Der spekulative Gesamtaufwand ist im Konfigurationsprozess wichtig, da über ihn bestimmt wird, welche Tätigkeiten freigeschalten werden ( wobei auch die Qualität der Resultate hier reinspielen könnte - das muss noch diskutiert werden ). Er ist so lange spekulativ und verändert sich, bis es die letzte notwendige Selbstzuordnung zu einer für die Bedarfsdeckung notwendigen Tätigkeit gegeben hat.

Ich kriegs grad nicht so richtig gebacken, was warmes zu Abend zu essen.

Bedürfnis: „Etwas warmes zu Abend essen“

Tätigkeitsmuster zur Bedürfnisbefriedigung: „Zu einer Küche für alle (Küfa) gehen“

Bedarfe: … Eine Küche für alle?

Tätigkeitsmuster: Aufbau einer Küfa

Bedarfe: (a) Ein großer Raum mit angehängter Küche. (b) Küchenutensilien. ( c ) …


Aber ist das Essen, das in der Küche für alle hergestellt wird jetzt ein Bedarf des Tätigkeitsmusters „Zu einer Küche für alle (Küfa) gehen“? Oder ein Bedarf der Küfa selbst? In letzterem Fall würde es aber parallel zur Küfa hergestellt werden, - was natürlich Quatsch ist.

Das Problem ist natürlich: Da kommt plötzlich eine Institution drin vor - und das darf es natürlich (?) nicht.

Also:

Bedürfnis: Ich möchte etwas warmes zu Abend essen

Tätigkeitsmuster zur Bedürfnisbefriedigung: Etwas warmes zu Abend essen.

Bedarf: Warmes Essen. (Zeitraum: Abend)

Möglichkeiten:

Tätigkeitsmuster für Curry.

Tätigkeitsmuster für Lasange.

Tätigkeitsmuster für Rosenkohleintopf.


Die Institution der Küfa ergibt sich, wenn sich Leute zusammenschließen, um sozusagen „alle“ zu bekochen, die Lust auf ein warmes Abendessen im lokalen Umfeld haben.

Wie lernen sie sich kennen und wie kommen sie an einen Raum?

Tätigkeitsmuster für Curry (hohes Gewicht, da viele Lust darauf haben)

Bedarf: (a) Eine Küche mit Küchenutensilien. (b) Reis. ( c ) …

Selbstzuordnung von mehreren Personen: „Alleine mache ich das nicht, aber wenn sich x Personen anschließen, können wir Menge y bewerkstelligen“ - dafür muss sich dann ein Kommunikationsraum um das Tätigkeitsmuster eröffnen.

Dass sie dann eine Küche mit Gemeinschaftsraum heraussuchen, können sie ja selbst entscheiden.


Zum Thema Entwicklung: Ich fände es wirklich geil, wenn wir mit so einer Küfa-App anfangen. Der riesen Vorteil ist, dass es 1. schon solche Institutionen gibt, mit Menschen die sich jetzt schon Freiwillig beteiligen, 2. keine großen Maschinen etc. notwendig sind und 3. wir tausende Tätigkeitsmuster in Form von Rezepten haben, die wir importieren können. Außerdem sind „etwas warmes zu Abend essen“ und „in Gemeinschaft sein“ sehr verbreitete Bedürfnisse und der Aufwand für sich selbst zu kochen relativ hoch.

Diese Stelle finde ich besonders interessant:

Wie passiert diese Auswahl? Wann und wo kann ich als Bedürfnissteller bei deinem Beispiel angeben, dass ich am meisten Lust auf Curry habe?

Ansonsten finde ich die Dinge aus deinem Beitrag gut nachvollziehbar und halte die Küfa-App ebenfalls für ein gutes Beispiel. Bei der „Institution“ musste ich kurz an den Kindergarten denken, der in einem anderen Thread vorkam.

Das erinnert mich an eine frühere Diskussion, die wir zum Prototyp hatten. Da wurden Vorschläge gemacht, wie ein Bedürfnis befriedigt werden kann und die entsprechende Person hat gesagt: „So schon, so nicht, so schon“ usw. Das heißt, ich möchte warm zu Abend essen; dann gibt es unterschiedliche Möglichkeiten, welche darauf deuten und ich mache schon einmal eine Vorauswahl, was mir taugt und was nicht.

Die Tätigkeitsmuster, welche also im Konfigurationsprozess schließlich freigegeben werden, werden von Anfang an eingeschränkt. Reicht das?

Den Kindergarten sehe ich auch als guten Einstieg, um „in der Gesellschaft Fuß zu fassen“, allerdings wesentlich problematischer als die Küfa. Angenommen, unsere App wird wirklich dafür benutzt und plötzlich kommt es zu einem Vorfall irgendeiner Art - dann müssen wir dafür gerade stehen auf eine Weise. Und das kann echt schwierig werden. Bevor wir uns so einem heiklen Thema annähern sollten wir schon Erfahrung haben, meiner Meinung nach. Besonders auch, wie wir mit Verantwortlichkeiten und Vertrauensnetzwerken (o.ä.) umgehen.

Ich denke, das passt alles grob. Wahrscheinlich ergeben sich die Details erst während der Entwicklung und dann in der ersten Experimentierphase.

Bei der Küfa ist noch das Problem, dass natürlich viele Menschen essen wollen, aber nur wenige (wahrscheinlich) die Arbeit machen. Die haben dann vielleicht eine hohe Reputation, aber außer dass sie Essen bekommen, hilft ihnen das nicht viel. Und irgendwer muss wahrscheinlich auch noch die Möhren bezahlen oder die Küche mieten.

Will sagen: Aller Anfang dürfte schwer sein, es dauert, bis erste Kreisläufe entstehen und die entstehen nicht in einer Küfa-App. Was nicht heißt, dass es nicht ein guter Anfang ist.