Our whole paradigm for the UI is wrong, should not center on ResourceSpecifications

[adaburrows]

As I was working on the accounting and event input code, a lot of what Leanne said about the interface in chat (RE #156) clicked in my head. If what we have on the label should be on the block (graph node) itself, then that feels a lot like the UX I first had a year ago when we started thinking about a similar project: Valueflows UX Test 1.pdf (though that UX will be refined based on revisions we've already made and feedback we already have about the forms).

Basically, we should switch the ResourceSpecifications pallet out with one that has

• Intent
• Commitment
• Event

and we can move the ResourceSpecifications into another place, like perhaps a treeview under the pallet that could have the Agents and other objects that need configuration in the Playspace. We could also draw users to the option to create a new Agent or two when they first visit the play and there's no data. Then we could highlight the ResourceSpecifications next.

In the course of filling out the form for the specific type of {Intent,Commitment,Event}, the resource will have to be referenced, so it would only be natural for that to show up on the block along with the agent assigned. The line connecting the {Intent,Commitment,Event}s would have the placeholder role that ResourceSpecification has and could indicate the flow of that ResourceSpecification or specific EconomicResource.

To represent a transfer, we would just drag an Event onto the screen and fill it out. This would be much more straightforward, instead of dragging the resource placeholders onto the screen and then connecting the lines and finally inputting the Event.

When a Commitment is created alongside and Intent, we could create the Satisfaction.
When an event is created alongside a Commitment, we could create the Satisfactions and Fulfillments

Also, it means that plans could naturally be transformed into string diagrams and could keep track of their inputs and outputs automatically based on the {Commitment,Event}s which are part of the open graph.

There's still some aspects that need to be thought through, but I think this would be a drastic improvement and would lead to an intuitive way of composing plans at a higher level.

We could also add

• Proposal
• ProposedIntent
• Agreement

to that same pallet which we could drag and drop and create relationships with the other objects on the screen (perhaps it would be a dashed line in those cases). Although we could always group related Commitments into an Agreement bounding box, but I think the lines might be easier and clearer for small datasets.

Later when people want to explore it, we could add Claim into the Pallet.

[fosterlynn]

Will respond in a few days... I have some thoughts, but need a little focus time to study more.

[adaburrows]

For instance, here's a few Valueflows statements which are perfectly valid in the playspace:

In this case the resource specification placeholders are the least important aspect of the data. What is most meaningful is what is on the lines. We already have a ticket to make better custom edges that look more like the nodes that have formatted information, but this would formalize it much better and we wouldn't have to put in as much work to get it done.

Also, Zippy is on board with this idea. Perhaps we should make a few mockups of how it would look.

We could also simplify the "Flow Modal" and make a convincing UX that can move things from Intents and Proposals through to Commitments and Agreements, and then to Events more easily. Additionally Shane and I thought through the idea of having Proposals and Agreements be those group boxes ReactFlow provides. Since the edges in our current model become the nodes and processes stay processes, we have an easier would of accomplishing the grouping into proposals and agreements. There are several varieties of the UX we could experiment with to figure out the best option. Oh, additionally, we could more easily create a version of the canvas that shows things much more like how the NY Textile Lab envisioned their flows from the PDF they sent us in August last year.

[bhaugen]

I don't care whether resources have boxes or not but would hate to lose the arrows. It needs to be directed graph. But it looks like your proposals still have arrows, right?

[adaburrows]

I don't care whether resources have boxes or not but would hate to lose the arrows. It needs to be directed graph. But it looks like your proposals still have arrows, right?

@bhaugen oh definitely, the arrows still visualize the flow of the resources. They become much more like the lines of the string diagram the category theory community likes to throw around:

The primary difference is that the Intent, Commitment, or Event become a box on the line — mostly for clarity of the information contained inside of it, since it has way more information than the lines in the diagram above. Also, it fits within the model I had about Processes being maps between Intents, Commitments, and Events, while each of those are directed maps to and from Agents, ResourceSpecifications, EconomicResources, Quantities, Actions, etc.

Note, there's a mistake in the diagram below, I wrote EconomicResource after the process when I meant EconomicEvent:

[fosterlynn]

Still studying, and will have more time starting tomorrow. But, I think I read it enough to understand where you're going. If not, please correct me and ignore some of the following.

I'm concerned that the directed graph won't work without the resources (little-r) there to resolve the many-to-many between processes, just like processes resolve the many-to-many between resources.

I do think we may have an issue with ResourceSpecifications vs EconomicResources in trying to represent either or both on the same diagram, because it is possibly more difficult to think of ResourceSpecifications as placeholders for users, but I'm not sure, this may be just fine.

And the way transfers work might not be optimal from a UX perspective, as discussed, they are the same but also different from production. Clearly we need to have some validations in place to guide the constructs. Your pictures that are intended to show the problem lose the placeholder piece, I think that when planning visually like we are, the ResourceSpecification probably needs to anticipate a future resource, i.e. transfers have 2 places for resources (and if they were 2 events, they would still have 2 places for resources, just be split out). But think about at the end of a production/creation set of processes, there is some final output that shows on the graph. So it can easily be transferred to one or multiple agents. You start drawing a flow from an existing little-r resource, create a transfer event, and at the end is a different resource because a different agent has responsibility.

Here's one scenario (we should come up with several scenarios to run through this proposal). But let's say that in the string diagram above, instead of it being a simple flow that happens to make a pie today, when they make the lemon filling, they make enough for 50 pies, and freeze most of it for later. If you don't show the little-r resource, you will have 50 lines coming out of that process eventually. And the lines can't be right because the output flow is one produce event, and you will have 50 consume events. The consume events don't come out of that process, they need the mediating resource.

In terms of the NYTL diagrams that they did, they called them recipes, and in fact they really are more recipes than plans from the perspective you are looking at. When I translated them to playspace plans for dweb, I made it so the farmer perspective was the farmer's, not the designer's. What NYTL did was explicitly the designers' perspective, here is exactly what I need to make my batch of socks. The farmer is tending a herd of sheep, a lot of which are the same animals season to season, and shearing them once a year to get a bunch of wool, way more than goes into one designer's batch of socks. They mostly don't want to see all the individual designer detail, better to see the combined demand from sets of plans that have then been combined so that the network can actually order the total of what they need of dirty white wool from maybe a few farmers that all the designers think they need for the season. And last year Laura bought extra because it was available, and it is in inventory (the "in my garage" kind).

Bob brought up the concept of push and pull with NYTL in early discussions, and it is useful to think about. Their network is mostly pull, from the designers' individual plans. But the farmers are in push mode (with some understanding of what is wanted, but they can't turn on a dime when raising a flock of sheep for a season, and they have physical constraints too). And some farmers might grow extra for "stock", thinking they can probably sell that on individual pull demand through the season outside the NYTL network. Our veggie CSA is mostly in push mode, after an initial pull from eaters' orders for the season. Then they plant enough quantity of different things to fill that many boxes for the season, and after that it is all push from the farm. Each week it is what grew well, ripened in time, etc. We get what we get. Usually push meets pull somewhere in the middle of resource flows.

I'm not sure what will be the best UX where the pull and push meet in the NYTL use case. There is thought that the farmers will post offers for the season (the map with offers that was started), but as the network develops, there may be more planning farther back in the chain. And this doesn't include the designers to wearers part of the flow, where the wearers are probably just buying stuff that is already made.

I'll give more thought to what are the different UXs and underlying assumptions/models behind the different layers.

My other comment for group discussion is that I think we've been working on this a long time with only minimal user-group feedback, and that we need a good cycle of that before making drastic changes to the UX. Or at least use cases derived from actual requirements and mockups for where they diverge, working directly with the groups on the ground on the upcoming projects.

[adaburrows]

@fosterlynn, I'm very confused by what you're saying. It seems there's a lot of assumptions going on here when no real design decisions have been made or even fully clarified or presented. I will need to draw out what I'm thinking because what I'm writing is both verbose and abstract and the images I'm presenting do not match up with the design ideas (a plurality of them) in my head. Even though I didn't mention it, there will still be placeholders for what is output or input into a plan at the resource level.

The main difference is that we should style the nodes to indicate that they are resource placeholders for storing stock. The idea around the resource placeholders as capacitors or reservoirs/stockpiles still stands.

The main difference is that it would no longer be necessary to place resource placeholders between every Intent, Commitment, Event, or Claim. Though we could still indicate it on the lines connecting those things. We would have the placeholders as inputs and outputs to/from the plan/scenario, but they would be there purely out of visual convenience, since they are always implied.

It might just be that it's part of the node (and I want you to remove the idea of the node as a solid block, It can be made transparent and have images and what not inside it and still have dots as ways of connecting the flows), or maybe we add input and output placeholders that are styled according to the kind of thing it is. Some of this will be easier once we have the full graph as a data object we can traverse.

For instance, there could be a ResourceSpecification node that magically appears connected to the new Intent the user created. It can be styled to indicate that it's an input or output. It could also be explained that it's both a source and a sink. It's still just as true that a ResourceSpecification going into a process and the same ResourceSpecification coming out of a process or transfer are theoretically the same source or sink, but we can also compute what the estimated EconomicResource would be without further user intervention.

We could also use the actual EconomicResources at the event level and those could be styled differently to indicate that it has a different level of specificity.

There is also a misunderstanding about the number of lines corresponding to the number of items produced, that need not be the case and I never had that as an idea. It would still be the same kind of data we have now, "50 lemon pies" and it would just go to the placeholder at the edge of the plan representing the inventory or potential inventory (i.e., it's just planned around ResourceSpecifications, not actual EconomicResources).

The only thing that I wanted to show was that the Intent, Commitment, and Event, can be connected directly to the Process, while the Intent, Commitment, Event serve as mediators between the ResourceSpecifications and EconomicResources.

Then using the placeholders from the edges of the plans, a larger scale network view of plans could be made, or even aggregate views of multiple plans laid on top of each other could be constructed.

[fosterlynn]

Sorry if I added to the confusion, I may have responded more to "our whole paradigm for the UI is wrong" and the visuals than you intended. I'll wait until you have mocked something up, or whatever the best step is to bring the discussion closer together. No hurry on my end.

[pospi]

and we can move the ResourceSpecifications into another place, like perhaps a treeview under the pallet that could have the Agents and other objects that need configuration in the Playspace. We could also draw users to the option to create a new Agent or two when they first visit the play and there's no data. Then we could highlight the ResourceSpecifications next.

This does seem ideal to me- putting ResourceSpecifications (and other specifications) into a separate configuration section so that they don't take up screen real estate during the main event of authoring a flow. Most networks do this infrequently, ideally once at setup time.

I also think there might be a pattern here that's applicable to building We-compatible UI components:

• There's a "controller" UI component that services the main functionality of the hREA module (in this case, Specification). This would be the larger config screen for setting up the ResourceSpecifications.
• There's a "consumer" component that gets embedded into the visual editor component tree. This one feeds data out of the hREA module into a controller to be used as part of some other UI. In this case, selectors for choosing the event / resource type when logging EconomicEvents, Commitments and Intents.

Terrible names I know, I'm just trying to reference existing terminology in other common software patterns so that hopefully you know what I mean by them.

[adaburrows]

Copied from https://lab.allmende.io/valueflows/forum-valueflo-ws/-/issues/141#note_39999

---

What I'm thinking about now is separate UIs for different aspects:

• Process editor
  • Allows constructing Processes (in the planning stage with Intents, since that's roughly where everything starts) along with their Intents that connect them to the ResourceSpecifications/EconomicResources. That way we can think of a Process as something that already has connections to the resources it will require. These units of planning can then be pulled into a Plan.
  • Another possibility is to construct RecipeProcesses, RecipeFlows, and RecipeResources. These templates would actually form the basis of everything that gets pulled into a Plan. Need to pull a Process into a Plan with Intents, Commitments, or finished Events? We could easily do all of that from a menu in the Plan editor.
  • This also allows for making a Recipe object that would fulfill the previously discussed need for being able to have multiple recipes for the same ResourceSpecification, however, that would be a special function of the Plan editor.
• Plan editor
  • Allows pulling these processes into a plan along with the Intent/Commitment/Event connections to the ResourceSpecifications/EconomicSpecifications it needs. This means the majority of the work on creating the connections between Processes and ResourceSpecifications or EconomicResources can be left to the Process editor.
  • Since we have the data about which Processes use which resources (ResourceSpecifications/EconomicResources), we can constrain which Processes can be chained as inputs or outputs of other Processes.
  • Could also function as a Recipe editor.
• Proposal and Agreement editors
  • These would specifically look at the independent view of what happens between Agents since either of these objects may be multilateral.
  • This would specifically avoid looking at the Processes and other Proposals and Agreements used to create a specific EconomicResource (the overwhelming entirety of the full network view) and focus on trade/exchange/barter Proposals and Agreements between Agents.
  • It would become possible to surface all the possible Proposals that would satisfy each other agreed on.
  • This would form the basis of a POS (point of sale) system that allowed barter/exchange/mutual credit/complementary currencies/etc.
• Plan Based Network View
  • This can be used to show how Plans connect to each other and gain insight into how circular/local the economy is.
  • Also useful for management/governance to see how things need to be sequenced and managed.

[adaburrows]

Oh, I also think there's an aspect of the ResourceSpecification/EconomicResource duality that needs to be made more clear in the UI. We need to show that the ResourceSpecification is a category of resource and that it's possible that, in certain circumstances, any of the EconomicResources which conform to it might be substituted for another. There are obviously certain cases like if a ResourceSpecification is 'Alcohol Infusion' and the EconomicResources are 'Tepezcohuite' and 'Mallow' or if a ResourceSpecification is 'Git Repo' and the EconomicResources are 'REA Plaspace' and 'We'. This plays into #37.