Discussion: Process composition and nesting UX

[fosterlynn]

This is an issue meant to house some UX ideas centered on processes and process flows, specifically the "nesting" of processes. This has taken two forms, "up" (less detailed) and "down" (more detailed). It is some thoughts that have arisen in recent days, from several discussions, including this, and our earlier experience.

It is NOT meant in any way to imply something we should be coding without actual user input on something we are actively working on!!

Valueflows does not support "down", it supports one level of actually operational processes, i.e. we will do / are doing this. If an operational process is defined such that people feel they need to have events pointing at some internal part of it, then it is probably not defined low enough. Operational processes need to be the lowest level, or there will be duplication of data and confusion on what needs to be done, tracking/tracing, etc.

For "up", VF currently supports Plans, which nest Processes, and Scenarios, which can nest Plans (and other things, but that is other use cases). I think this is worth doing as the need arises, and I think it will arise. For example, when I was putting the data collected in the Simon's Rock garden project (using Leanne's temporary app) into the Playspace, it became apparent that the canvas was going to get very large and very difficult to follow, as it is. Supporting Plans will help a lot (one Plan on the canvas at a time), but by itself, it won't solve a need to get a simpler overview of what is happening and how it all connects.

So I think one thing we will want to consider in the future is to derive at least one level "up" by showing plans and the connecting flows, derived from the processes, and excluding anything that happens just inside the plan. So just show inputs that come from outside the plan, and outputs that go to outside the plan. There will need to be something about finished vs unfinished plans (based on process.finished).

If we find that a user group needs further levels "up", we could experiment with offering Scenario as a way to define that for them.

On the "down" side, while not really "nesting", it will at some point be good to have a Process page, which is more than the current CRUD modal, and would include all related flows. This would be a focused place for coordination among the agents working on one process, perhaps even including chat/discussion (a requirement brought from projects that are adding VF on top of social networking). This isn't nesting, but I think it fits here, and is the way to think about "down". I think all of us are coming to something like this, @adaburrows has sketched a Process level page, and @shanedeeodonnell has also, as part of a thought process of building up from lower pieces of information. We have had a Process page in all of our previous software - and I suspect that even though we didn't have the visualization CRUD building UX, this still is probably a valid unit for a page. We'll hopefully find out with more user group feedback.

[fosterlynn]

Suggested examples to run ideas through, choosing for variety of visual needs:

1. Garden class of Code A. Features a quantity of flows, quite a few processes. Some of their processes could be handled as one process that is fairly long running, or several processes of the same type over time. Like "haul food scraps from dining hall". That could happen several days per week over the summer, say. In general, creating a diagram without plans is making a pretty big diagram that will be hard to use to conceptualize the whole picture. But if they were to use Plans (when we have them), they will also be pretty connected to each other, and not good to have separated completely. Like the dining hall scraps feed the composting process, which is used to build the garden beds, and later to re-fertilize them.

2. Guerrilla Translators!. For this example, let's say that they do translations of documents. The steps are pretty much the same, something like: do the initial translation, edit it, proofread it, add images, format it for publication. The steps are processes, connected with accept-modify, with work also logged. Each translation is a plan. The translations rarely connect with one another.

3. NY Textile Lab. Supply chain network. Each plan is for one run of one end "product" for one designer, going back to the types of fiber needed from the farm, or at least after scouring. So starting up, let's say they would have 10-15 plans/season. The designers then would coordinate with each other (with the help of the software) to see where their plans intersect and where they can combine orders, especially from farms. So it will be useful to see individual plans, and also all of them together in some way.

4. Koalas in Australia. Analytical flow diagram, not used for operations - rather for documenting and persuading. This kind of thing will pretty much be independent diagrams, although for the Koalas, there is a "as-is" and a "to-be" diagram. Those would each be a Scenario Perhaps out of scope for this discussion, not sure?

[adaburrows]

Please see the discussion here: #164 (comment)

[adaburrows]

Copied from #164 (comment)

---

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.

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.

[adaburrows]

@fosterlynn RE: Garden class of Code A, that's a good use case for thought. We currently don't seem to have a mechanism for specifying recurring plans. I've just heard the thought around keeping a long running process around. There's just the issue of coordinating work on that. To me it seems cleaner to have logic that creates new plans that allow repeating a process on a regular interval. I'm also wondering if maybe there shouldn't be a option for making a template plan (the original plan?) that has a repeating boolean field and an interval field for defining how often it should be done.

[fosterlynn]

We currently don't seem to have a mechanism for specifying recurring plans.

What VF has is recipes, which are not (yet?) in Playspace. They are exactly for creating plans that are the same or similar, where the series of processes will be done frequently enough to make it worth having a recipe. In NRP, we had a way to choose a recipe, an end or start date, the end quantity in case the recipe should be multiplied out, and it generated the plan. (From memory, approximately like that.) Seems like to create recurring plans, we could use recipes, and also have an option to create more than one plan from the recipe if it is recurring on an interval. Maybe sort of like in a calendar, creating recurring events.

[edit: Or your idea of a template with a repeating boolean and interval, something like that could work too.]

Side note. We also had a request for being able to copy a plan to create a new plan. And a request to create a recipe from a plan.

I've just heard the thought around keeping a long running process around. There's just the issue of coordinating work on that.

Agree, that is not the best way to handle a lot of use cases.

[adaburrows]

What VF has is recipes, which are not (yet?) in Playspace...

I mean specifically a mechanism for fully specifying the logic of how often and when an event recurs. Using a recipe still pushes that logic off to something outside of the core data model. this is why I mentioned adding:

a repeating boolean field and an interval field for defining how often it should be done.

I would actually suggest having a Recurrence object with a schedule data structure. That object can point to a template plan (for plans more complicated than a recipe, since in the current data model the Recipe is only for creating a specific EconomicResource), proposal (maybe agreement?), or a recipe.

[fosterlynn]

I mean specifically a mechanism for fully specifying the logic of how often and when an event recurs. Using a recipe still pushes that logic off to something outside of the core data model.

Yes, true. I hope we could do it as logic, not any new data structure, at least on the plan level.... how would you put events against commitments for example?... but see also below...

I would actually suggest having a Recurrence object with a schedule data structure. That object can point to a template plan (for plans more complicated than a recipe, since in the current data model the Recipe is only for creating a specific EconomicResource), proposal (maybe agreement?), or a recipe.

Your template idea might fit in the knowledge layer, something to consider when we add a Recipe class. Maybe that is what you meant? That would also support more easily creating plans that contains more than one deliverable, which we will need. (For example, a past requirement was to plan a "campaign" with events, brochures, etc).

But I'd suggest we hash the detail out when the need arises and we can work on it with real requirements.

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

Going back a step, I like a lot of these ideas. Now that we have a runnable Playspace, let's figure out how to leverage that to work with our various user groups and potential user groups to understand a possible roadmap. Maybe we can do it with some kind of simpler prototyping on top of the Playspace too?

[adaburrows]

Yes, true. I hope we could do it as logic, not any new data structure, at least on the plan level.... how would you put events against commitments for example?... but see also below...

I was thinking that we could at least have a schedule object that could be part of Valueflows since a recurring schedule would seem just as valid as part of the model data as any other date object referenced by hasBeginning, hasEnd, hasPointInTime.

The Recurrence object would just we a way of putting that outside of the original object that would recur, but I can see it as completely valid as part of a few other object. Perhaps it could be a hasRecurringSchedule relation that points to a schedule.

The schedule object would be something like:

{
  everyPeriod: 'day' | 'week' | 'month' | 'year' | duration in ms,
  atTime: time,
  onDays: [1..7] | [1..31],
  onDate: date
}

The field everyPeriod can specify a predetermined period, or it can have a duration in milliseconds. The field atTime specifies the time on which it occurs. The fields onDays and onDate are mutually exclusive. The field onDate is only useful for something that recurs yearly. The field onDays can specify multiple days in a week or multiple days in a month.

Your template idea might fit in the knowledge layer, something to consider when we add a Recipe class. Maybe that is what you meant? That would also support more easily creating plans that contains more than one deliverable, which we will need. (For example, a past requirement was to plan a "campaign" with events, brochures, etc).

Yes, putting that in a Recipe or something else (perhaps a PlanTemplate or a Plan with an added isTemplate boolean) in the Knowledge layer would be good.

What I see happening is that some people will want to have new Plans created with either Intents or Commitments at the intervals created by the schedule. People will then manually transition from Intents to Commitments that satisfy those intents. People will also manually enter the Events that fulfill those Commitments. That way, if the Plans are not done, they will build up and can be a clue of where things are failing.

Going back a step, I like a lot of these ideas. Now that we have a runnable Playspace, let's figure out how to leverage that to work with our various user groups and potential user groups to understand a possible roadmap. Maybe we can do it with some kind of simpler prototyping on top of the Playspace too?

Cool. I was pretty happy with these breakthroughs. I could see where people were struggling. And this seemed to be the best segmentation of the ideas.

I need to work through the tech debt in #168, but after that we can definitely start to prototype things more quickly, since we have most of the data structures.