While working on the project.-page, I felt the need to bring the graphic to a new state. It was especially important to me to break down the engine a bit and especially to show its result isolated (proposed activities), because it refers again to other data. And of course the introduction of the reputation extractor/adapter as a single module.
Brief introduction as I think of it:
Distributed means and reputation databases that are read via extractors/adapters and made equally processable. The “means e/a” thereby sends information back to the “means-databank” for use/agreement on the means. The “activity-pattern-database” is referred to in the proposed activities. The “reputations a/e” ties various reputation systems to user profiles.
needs / demands / problematic state of means
These are three forms of problems, which can trigger activities to solve them. What is exciting is that they come from three different sources. “Needs” are fed in directly by users. “Demands” are created by self-assignment to “proposed activities” and are then part of “configurations”. “Problematic states of means” are mediated by the “means extractor/adapter” if a “conservation state” (bad translation) has been defined before. The three forms of problems are passed to the engine.
The engine is the algorithm of the configuration process. At the end of the day, it does nothing more than propose activities (“proposed activities”) based on the locally available resources and the three problem cases that stakeholders can take on.
The static set of all proposed activities. Activities are proposed to users according to their availability of resources, according to their skills/interests, and according to their specified consideration (“Berücksichtigung”). Each activity refers to a pattern of the “activity-pattern-database”. If activities are assigned, they become part of the “configurations”.
The context of activity patterns that have been assigned to ultimately satisfy mediated needs. It is a transparent arrangement of patterns from the activity pattern database.
Present twice in the image, for clarity. It’s about unique user profiles - The top means: users mediate needs and communicate to agree on configurations or make agreements on the use of resources or the definition of conservation states. The “User-ID” below means: In the profiles one’s own circumstances, social relations, reputations are recorded. Depending on this, one’s needs are displayed to other users according to their preferences, or activities are highlighted according to one’s considerations. Users can assign themselves to the “proposed activities”.
In user interfaces, various information that arises in the process can be made available. For example, suggested activities. Or transparency of configurations. Or communication. Or anything. In different forms, as smartphones or web apps, etc. pp. The main thing is to display information and, in the best case, enable interaction with it.
Software mediation can’t be decided solely on the use of resources. It needs interfaces to non-software users. At least the information about their planned use and possibilities of contacting etc., if there is a conflict about the use or someone wants to use the means who is not a user.
Did I miss something relevant? Do you disagree with something? Especially, but not exclusiv, @balkansalat and @qsmd .
I also hope it helps us structure our " environment analysis"/Umfeldanalyse.