Wireframes, App Design

Sehr spannend, liebe Leute. @katharina: Was sind für dich die nächsten Schritte? Ich fänds spannend, wenn wir diese Wireframes-Abläufe im Design sehen könnten. Das brauchen wir fürs Kürzestvideo sowieso, richtig?

Ja genau. Ich versuche möglichst bald in jeder Design Richtung die Webseite, die App und das Video durch zu gestalten (zumindest als erste umsetzungsidee), damit sich jeder was darunter vorstellen kann und wir uns hoffentlich bald auf eine Richtung einigen können.

Toll, ich freue mich mega! :slight_smile:

Kleines Update hierzu: Ich habe versucht die Wireframes schonmal ins Design zu übersetzen, habe aber festgestellt, dass ich gerne davor noch mehr Zeit ins Konzept stecken würde. Hier würde ich gerne noch weiter an der Sturktur arbeiten, z.B. überlegen, wie ein Menü aussieht, welche grobe Struktur die App überhaupt hat, welche Listen darstellung es gibt (hatten wir schonmal kurz angesprochen, die Diskussion ob es z.B. ein tinder-swipen oder ein instagram-scrollen ist).

Hier sind die Screenshots der Wireframes, wie ich sie heute gezeigt habe:

in diesem sieht man die Verlinkungen, also wohin man kommt, wenn man wo drauf klickt:

Danke, @katharina. Der Ablauf in der oberen Zeile ist richtig gut!

Mir fallen zwei Dinge auf, die ich unpassend finde:

  1. Das „+“ oben neben „Bedarfe“. Ich hatte das ursprünglich selbst dort eingefügt, mit einem anderen Gedanken. Gerade dass du es anders interpretiert hast, zeigt für mich, dass es verwirrend an der Stelle ist. Aus meiner Sicht sollten wir es weglassen.
  2. Beim „zur Verfügung stellen“ unten rechts: Ich stelle mir vor, dass man dort das Mittel, welches man zur Verfügung stellen möchte, beschreibt: Vielleicht ein Foto machen, Beschreibung und Ort eingeben, ab wann verfügbar, unter welchen Bedingungen etc.

Alles andere scheint mir genau so passend. An den Texten können wir noch feilen, aber das dürfte jetzt nicht wichtig sein, oder?

Ob das jetzt bei den ersten Entwürfen notwendig ist, weiß ich nicht, aber auf Dauer müssen die Tätigkeitsmuster meiner Meinung nach von der Bedarfsanfrage (… der Commonifizierung? Des zu-Commons-machens des eigenen Eigentums?) getrennt werden. Das ergibt sich schlicht aus dem Konfigurationsprozess: Die Tätigkeitsmuster werden ja freigeschalten, wenn sie nach den Informationen, welche über die Software ausgelesen werden können, im jeweiligen Umfeld sinnvoll sind und das ist in erster Linie abhängig, welche Dinge dort verfügbar sind. Zu sagen: „ich stelle einen Bedarf zur Verfügung“ heißt ja auch: Der Software war zuvor nicht bekannt, dass ich dieses Mittel habe und prinzipiell zur Verfügung stellen würde. Und wenn ich z.B. einen sehr großen und speziellen Ofen habe, der für Brotbacken geeignet ist, diesen aber noch nicht als verfügbares Mittel markiert/eingespeist habe, dann werden sehr sehr lange keine Tätigkeitsmuster freigeschalten, welche sich auf die Verwendung eines solchen Ofens beziehen, da seine Herstellung/Verfügbarmachung an sich sehr aufwendig ist.

Es gibt also die Situation, in der die Software sagen kann: „Dieses Tätigkeitsmuster ergibt hier Sinn, da alle Bedarfe relativ leicht verfügbar gemacht werden können“. Und gleichzeitig sagt sie: „Wenn dieses Mittel verfügbar wäre, dann gäbe es noch ein viel sinnvolleres Tätigkeitsmuster - aber da dieses Mittel scheinbar nicht verfügbar ist, ergibt auch das Tätigkeitsmuster keinen Sinn“. Es muss also einen extra Auswahlprozess geben, in welchem seperat abgefragt wird, ob dieses Mittel vielleicht doch wer zuhause herumstehen hat. Was aber nicht heißt, dass es keine direkte Verlinkung geben darf, wie sie in den bisherigen Wireframes angedacht ist.

Das nur. Und: Ich würde mich noch über ein Wireframe freuen, in dem das Tätigkeitsmuster selbst (siehe wikihow.com) sichtbar ist - also die Beschreibung, wie eine bestimmte Tätigkeit ausgeführt wird. Das ist noch super wichtig.

Ja, das stimmt. Nachdem man eine Tätigkeit konfiguriert hat, kommt man wahrscheinlich nicht zurück zur Bedarfsliste. Sondern zu einem Bildschirm, wo man Details über die Tätigkeit sieht. Und dort dann auch die Details des Tätigkeitsmusters. Also

  • Einordnung der Tätigkeit in die Produktionskette (benötigt XYZ und stellt ABC her), evtl. als Bild
  • Hat sich schon wer zugeordnet?
  • Was genau muss ich tun, um die Tätigkeit durchzuführen (Beschreibungsteil des Tätigkeitsmusters)
  • Angabe der „Wichtigkeit“?
  • Zeitlicher Rahmen? Bspw. von wann ist das älteste Bedürfnis, zu dessen Befriedigung ich mit dieser Tätigkeit beitragen würde.
  • Vollständigkeit: Kann die Produktion starten, wenn ich mich dieser Tätigkeit zuordne? Was fehlt noch alles?
  • Liste der Bedarfe laut Muster, Liste der tatsächlichen Bedarfe, falls sich schon jemand zugeordnet hat
  • Verweise auf Kommunikationsräume (ein interner, jeweils einer pro Bedarf, jeweils einer pro Ergebnis)

Sorry, das war jetzt nur schnell ein Brainstorming mit mir selbst. Ist viel, vermutlich noch nicht alles und recht ungeordnet. Ich denke, wir müssen da System reinbringen und die Herausforderung ist, das gut darzustellen. :slight_smile:

Ich habe eben die Kommunikationsräume in der Detailansicht der Tätigkeit ergänzt. Damit kann ich mir jetzt auch besser vorstellen, wie die aussehen könnten. @katharina, vielleicht möchtest du auch dafür einen Entwurf machen.

Ich stelle mir einen Kommunikationsraum wie einen Matrix-Chatraum vor. Alle, die es betrifft, sind automatisch Mitglied. Also bei einem Bedarf beispielsweise die Produzierenden und die Weiterverarbeitenden. Neben der Möglichkeit zu chatten, werden alle relevanten Ereignisse angezeigt, ähnlich wie im Chat: „ABC ist passiert, XYZ hat dies und jenes getan“. Ich glaube, man nennt das Activity Stream. Ein Beispiel aus einem anderen Zusammenhang: https://git.hack-hro.de/stadtgestalten/stadtgestalten/-/issues/673. Wenn ihr runterscrollt, seht ihr unten verschiedene Nachrichten und andere Aktivitäten.

Wenn man dann den Kommunikationsknopf unten im Menü unserer App wählt, erhält man quasi einen zusammengefassten Activity Stream aller Räume, in denen man Mitglied ist. Und ein Symbol, welches anzeigt, ob etwas Neues passiert ist. Bei dem Beispiel oben sieht die Zusammenfassung dann beispielsweise so aus: https://git.hack-hro.de/stadtgestalten/stadtgestalten/activity.

Zu diesem Thema siehe auch die Diskussion in Textreihe Teil 3: Konfigurationsprozess (Kapitel 3)

lezten Mittwoch hatten wir ja darüber gesprochen, dass man seine Bedarfe genauer beschreiben können sollte, bzw. eine genauere Auswahl treffen sollte. Das habe ich auf Screen 2 - 4 mal versucht umzusetzen. Im Screen 5 - 8 ordnet man sich einer Tätigkeit zu, entweder dass man sie als Mittel zur verfügung stellt (neu hier: die genauere beschreibung) oder etwas herstellt und einen neuen Bedarf vermittelt. Auf Screen 8 würde man dann wahrscheinlich anstatt der Liste an Bedarfen das Tätigkeitsmuster sehen. Das wird nochmal echt tricky das cool darzustellen glaube ich! Hier eine erste Annäherung:

Vielleicht könnt ihr mir helfen und wir überlegen uns gemeinsam ein Musterszenario und definieren einmal was in dem Beispielfall genau ein Tätigkeitsmuster wäre, also wie das ablaufen würde. Die Software wählt dann für mich das beste Muster aus, oder muss hier noch eine Auswahl dazwischen, auf welche Art das Brot hergestellt werden soll? Screen 11 stelle ich mir als große Fläche vor, in der man frei navigieren kann, also scrollen und zoomen, ähnlich wie bei Karten, deswegen hier das breitere Format. Die Screens 12 - 14 zeigen Fenster, die sich dann über dam Screen 11 öffnen würden, wenn man auf die entsprechenden Buttons klickt.

Und dann gibt es noch den Profilbereich und die frage was darin alles verpackt wird:

Auch nach unserer aktuellen Diskussion halte ich es noch für passend, die Anzeige wie bisher beizubehalten. Es sind dann eben nicht alles Bedarfe, die abgefragt werden, sondern teilweise einfach Mittel, die möglicherweise benötigt werden könnten. Und für letztere gibt es den Link „XYZ herstellen“ dann nicht, weil keine Tätigkeit freigeschaltet ist.

Ich bin ehrlich gesagt gerade nicht ganz in den Wireframes drin (kommt noch), aber so viel gerade: Ich denke, die Nutzer haben gerade drei Möglichkeiten sich aktiv zur Vervollständigung einer Konfiguration einzubringen: 1. durch die Selbstzuordnung zu Tätigkeitsmustern. 2. Durch das zur-Verfügung-stellen von Bedarfen und 3. Durch das zur-Verfügung-stellen von Wissen in Form von Tätigkeitsmustern. Und das zur-Verfügung-stellen von Bedarf kann einmal bei ‚möglichen Konfigurationen‘ der Fall und damit an Tätigkeitsmuster geknüpft sein. Also die Frage: „Willst du dich der Tätigkeit annehmen bzw. kannst du gleich das Resultat zur Verfügung stellen?“ - das ist ja, soweit ich das verstehe, das was bisher auch abgebildet ist (Wireframe 6).

Und dann gibt es noch die Abfrage nach Bedarfen von ‚nicht-möglichen Konfigurationen‘, also solchen, bei denen die dafür notwendigen Mittel nicht bzw. noch nicht zur Verfügung stehen und daher noch kein Konfigurationsprozess (also das zeitlich-getrennte Freischalten von Tätigkeitsmustern) angestoßen wird. Aber diese Bedarfe hängen ja selbst auch an Tätigkeitsmustern. Und die Frage wäre wieder: „Kanst du das zur Verfügung stellen bzw. kannst du dich einer Tätigkeit annehmen, die das verfügbar macht?“. Der einzige Unterschied ist also, das vom Bedarf, und nicht vom Tätigkeitsmuster aus gedacht wird. Und, dass die Wahrscheinlichkeit höher sein könnte, dass das Tätigkeitsmuster niemals aktiviert werden würde, da es noch Teil einer ‚nicht-möglichen Konfiguration‘ ist.

Ich will sagen: Am Ende hast du wahrscheinlich Recht und langsam kommen die Wireframes auch bei mir an und ich finde es sehr gut. Vielleicht würde ich immer noch zwei getrennte Prozesse machen, also die Tätigkeitsmuster von den Bedarfen trennen, so das mir entweder das Mittel ‚Brot‘ oder das Tätigkeitsmuster ‚Brot backen‘ jeweils zuerst angezeigt wird. Aber das könnte auch die Nutzerin vielleicht einfach umschalten, wie sie es sich gerne anzeigen lassen würde.

Lange Rede, kurzer Sinn: Soweit ich das jetzt sehe, passen die Wireframes.

Nachtrag: Was wir auf Dauer brauchen ist eben das „Wissen teilen“-Ding. „Brot herstellen“ (bzw. „verfügbar-machen“, da es ja auch auf ein Transport-Muster verweisen könnte) verweist ja auf ein oder mehrere konkrete Tätigkeitsmuster. Und vielleicht gefallen die mir alle nicht und ich habe ein anderes Rezept / eine andere Möglichkeit und hätte dafür auch die Zutaten zuhause. Zwischen den Wireframes 6 und 7 müsste jetzt eigentlich noch ein Wireframe sein, bei dem das konkrete Tätigkeitsmuster ausgewählt wird und zusätzlich ein Button Namens (z.B.) „Neue Möglichkeit hinzufügen“, über den sich leicht ein neues Muster einspeichern lässt.

Hallo Katharina

Hier noch meine (etwas allgemein gehaltene) Rückmeldung:

Mir gefallen die Wireframes ungemein. Und sie helfen mir sehr, mir die App vorstellen zu können. Für mich macht so weit alles Sinn und ich finde, du hast grossartige Arbeit geleistet. Einzig ein Punkt ist mir aufgefallen: Bis wie weit gehen wir ins Detail? Ist es wirklich relevant, dass ich ein Brotmesser als Mittel habe, damit ich ein Brot essen kann? Wo wird es lächerlich? Wie wir da eine allgemeine Regel finden, ist mir noch nicht klar. Vielleicht braucht es die aber auch gar nicht.

Wie dem auch sei: Wir haben heute morgen besprochen, dass es zur Zeit wohl keinen Sinn macht, noch tiefer in die Wireframes einzusteigen, sondern den aktuellen Stand einfach mal beibehalten möchten, damit wir dann mit den Softwarefirmen gemeinsam weiter gehen können. Teilst du @katharina diese Ansicht?

Wir fänden es aber wichtig, dass die Wireframes, die im Kürzestfilm und im Entwicklerfilm vorkommen sollen, ein schickes Design erhalten, damit sie für potenzielle Geldgeber*innen noch greifbarer rüber kommen. Wäre das möglich?

Ja, da würde ich auf jeden Fall zustimmen! Ich setze mich gerne ran an eine Gestaltung der Wireframes, wie sie bisher sind

Hier gibt es einen neuen Stand für die App:

Zunächst der Auswahl prozess:

Hier gäbe es dann sowohl Tätigkeiten (das dann auf Muster wie bei Wikihow verweist?), die ausgeführt werden müssen, als auch Bedarfe (ich stelle ein Mittel zur Verfügung?), die gedeckt werden können. Im Fall des Brotes würde hier dann auf das gleiche Resultat verwiesen werden. Soll das so? Ich bin mir immer noch nicht sicher. Außerdem sollte ja auch noch Wissen vermittelt werden können in der Liste, oder? Wobei man ja auch für etwas wie Marmelade kochen Wissen braucht… Oder soll auch noch abgefragt werden: Weißt du wie man Marmelade kocht?

(Sollte ich an einer Stelle die Begriffe nicht richtig verwenden bitte sehr gerne korrigieren!)

Dann wähle ich im nächsten Schritt etwas aus, habe also (mindestens) zwei mögliche Wege vor mir, je nachdem, ob ich eine Tätigkeit oder einen Bedarf ausgewählt habe. (Oder dann noch mit der Wissensvermittlung einen dritten?). Davor gab es bei mir ja, nachdem man z.B. ‚Brot‘ ausgewählt hatte die Frage, ob ich das herstellen oder zur Verfügung stellen möchte (hier auch noch Screen „Auswahl: Bedarf/Tätigkeit“. Aber wenn ich das zuvor schon entsprechend ausgewählt habe, muss das hier nicht mehr abgefragt werden, oder?

Und hier noch, recht ähnlich, der Strang zur Bedürfnisvermittlung:

Am Ende der Stränge würde man dann noch zu dieser magischen Übersicht kommen, auf der die Muster und Verbindungen dargestellt werden, die allerdings noch gestaltet werden muss.

Soweit… Drehen wir uns im Kreis? Oder machen wir zumindest Baby-Steps nach vorne?

Das ganze war jetzt leider immernoch ziemlcih wireframig, obwohl wir ja gesagt haben wir belassen es soweit dabie, aber es waren ja noch ein paar ungeklärte sachen dabei und sind das auch immernoch, da fällt es mir schwer das so stehen zu lassen.

aber jetzt weiter zur tätigkeitsmuster ansicht. ich hab überlegt wie man sich am besten annährt, ich denke es wäre sinnvoll wenn wir uns das, was robert hier schonmal gesammelt hat, klarer machen und vielleicht konkret am beispiel brotbacken aufschreiben. das würde mir zumindest helfen

ich hab mal zwei videos aus den klickdummies aufgenommen, die die abläufe in der app darstellen. im hinblick auf unseren workshop mit den softwarebuden haben wir (robert, florian und ich) überlegt wie wir das am besten präsentieren. ich denke tatsächlich die abläufe hier reichen aus, um die app zu grundlegend zu verstehen. weiter haben wir uns gefragt, ob das ganze dann nicht zu einfach erscheint, aber ich denke sobald man die gedanken zu den einzelnen auswahlfeldern weiterspinnt, wird klar wie komplex alles ist. deshalb würde ich es bei diesen zwei „handlungssträngen“ belassen, damit wir eine basis haben, auf der wir aufbauen können.

… die videos liegen erstmal hier unter dem wetransfer link, weil die dateien zu groß für hier sind… (wenn es coole alternativen dazu gibt, gerne bescheid sagen! oder hatten wir da schonmal was??)

2 „Gefällt mir“

Ich schreibe mal eine Nachricht, damit Katharina wieder schreiben darf (Discourse erlaubt anscheinend nur drei hintereinander).

Die Videos zu den zwei „Handlungssträngen“ gefallen mir gut. Ich würde dann anschließend noch kurz skizzieren, was im Backend grob passieren muss, damit diese Dinge funktionieren (inlusive Übersichtsgrafik).

Figma-Links zu Katharinas Wireframes: https://www.figma.com/file/Q3nOfOy3ErJwCOnpXUgCEs/Wireframes-GCS?node-id=0%3A1