Wireframes, App Design

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.