the one task to rule them all: order!

[ahdinosaur]

had a nice chat with @iainkirkpatrick,

would be ideal if the entire app flow was a single task: "do an order" (or if your first order "do your first order").

we would need:

• sub-tasks can be ordered: can only move on when previous task is complete

[ahdinosaur]

dependent on #236

[michael-smith-nz]

Would like group all tasks by order? At the moment the 'dashboard' shows what look like identical tasks for different orders.

[ahdinosaur]

@NotThatSmith that's a good point. this proposal is an alternative approach, each order corresponds to a single task, which has the entire order flow as sub-tasks. this way, all the top-level tasks would be your orders, except for any isolated tasks like setting up your profile or such and such.

for the proposal, we'd probably also want the ability for sub-tasks to be conditional, as in be able to determine dynamically whether you are an admin or whether you've filled out the pre-requisites.

[ahdinosaur]

so, how would this look like in practice?

rough sketch in my mind:

- order
  1. if (!consumer || !supplier): setup
    - if (!consumer): setup consumer group
      - profile
      - members
    - if (!supplier): setup supplier group
      - profile
      - products
  2. intent casting
  3. if (admin): close intent phase
  4. if (admin): review order plan
  5. if (admin): send order to supplier
  6. if (admin): receive order from supplier
  7. receive order
  8. ...

and more complete draft of the order task recipe, including childs:

{
  id: 'order',
  hasOrderedChilds: true,
  childTaskRecipes: [
    {
      id: 'setupOrder',
      hasOrderedChilds: false,
      condition: ({ consumer, supplier }) => {
        return isNil(consumer) || isNil(supplier)
      },
      assigneeAgentId: ({ facilitor }) => {
        return facilitator.id
      },
      childTaskRecipes: [
        {
          is: 'setupConsumer',
          hasOrderedChilds: true,
          condition: ({ consumer }) => {
            return isNil(consumer)
          },
          childTaskRecipes: [
            {
              id: 'setupConsumerProfile',
              Component: SetupConsumerProfile
            },
            {
              id: 'setupConsumerMembers',
              Component: SetupConsumerMembers
            }
          ]
        },
        {
          is: 'setupSupplier',
          hasOrderedChilds: true,
          condition: ({ supplier }) => {
            return isNil(supplier)
          },
          childTaskRecipes: [
            {
              id: 'setupSupplierProfile',
              Component: SetupSupplierProfile
            },
            {
              id: 'setupSupplierProducts',
              Component: SetupSupplierProducts
            }
          ]
        }
      ]
    },
    {
      id: 'castOrderIntent',
      Component: CastIntent
    },
    {
      id: 'closeOrderIntentCasting',
      Component: CloseOrderIntentCasting,
      assigneeAgentId: ({ facilitor }) => {
        return facilitator.id
      }
    },
    {
      id: 'reviewOrderPlan',
      Component: ReviewOrderPlan,
      assigneeAgentId: ({ facilitor }) => {
        return facilitator.id
      }
    },
  ]
}

thoughts anyone? i'm pretty keen on this idea, but obviously need buy-in from the team.

[iainkirkpatrick]

just chatted with @ahdinosaur about this, took a few questions for me to see the idea clearly, but i'm pretty keen on this now :)

key things for me:

• IMO an order as the 'task to rule them all' gives us an opportunity to consider the paradigm that ONLY an order is a task in Cobuy (i.e. the only processes we model with tasks are an order and it's sub-tasks as @ahdinosaur listed above). This appeals to me in some ways - it probably simplifies the UI for one, as on the dashboard we can just have 'Orders' instead of 'Tasks'. It means that 'creating your profile' wouldn't be a Task, which is sort of annoying cause it kinda fits the idea of something that's nice to prompt the user to do. thoughts?
• @ahdinosaur re-raised his vision of an initial form on the dashboard for what i've been referring to as the 'order config' - i.e. which group, which supplier, which admin etc. The idea being that this is the first thing to do when wanting to start a new order, and completing this form creates the top-level order Task. My question was around what happens the first time, when there isn't a group, supplier? Mikey's answer - just remove the fields and leave the button to start the order - i vibe with this.

[iainkirkpatrick]

a thought... around non-order-admins looking at orders in their dashboard, what would they see if the order is at a stage where there is nothing for them to do? do they not see it (seems bad, they're part of an order but can't see the status), do they see it but can't interact with it (how do we show them which orders they can / need to interact with)?

wondering now if a good solution is still for an Order to be a 'top-level' Task, but maybe not the whole hog of ONLY orders being tasks. Then we could have an 'Orders' section on the dash which shows all current orders you are a part of, as well as 'Tasks' section which shows your active tasks (i.e. non-order Tasks like createProfile, along with tasks for orders where they're at the stage for you to do something).

thoughts?

[ahdinosaur]

we could have an 'Orders' section on the dash which shows all current orders you are a part of, as well as 'Tasks' section which shows your active tasks (i.e. non-order Tasks like createProfile, along with tasks for orders where they're at the stage for you to do something).

this matches my mental model for the dashboard.

around non-order-admins looking at orders in their dashboard, what would they see if the order is at a stage where there is nothing for them to do? do they not see it (seems bad, they're part of an order but can't see the status), do they see it but can't interact with it (how do we show them which orders they can / need to interact with)?

as with the order progress, we could have a symbol for "action required". like if we visualize an order as a series of steps connected in a chain, each step with a symbolic icon, we could update the background or fill in the icon when it is completed, and connect the next steps when active with lines.

roughly:

[x] -> [x] -> [x] -> [x] -> [ ] -- [ ] -- [ ] -- [ ]

or something

[danalexilewis]

I like the idea of some sort of progress indicator / status on orders peeps are participating in.

For mvp let’s keep it simple: perhaps a text field showing the stage name. That way it creates the requirement that we need to name the stages without us worrying about building to much ui.

[danalexilewis]

Regarding the idea that only orders are tasks. I think that makes sense for the current scope for beta 1.

Beyond this I think we will have other task types. Eg packing. There are potentially other tasks related to responding to suppliers, status updates, accounting (checking transaction references) etc.

So i am not sure what implications this has - more pointing out I think there are other task types on the horizon and leaving the implications for you all to workout :)

[michael-smith-nz]

Love the thinking here. I agree most with @iainkirkpatrick's statement:

we could have an 'Orders' section on the dash which shows all current orders you are a part of, as well as 'Tasks' section which shows your active tasks (i.e. non-order Tasks like createProfile, along with tasks for orders where they're at the stage for you to do something).

I like our thinking of moving away from a task-based system, to an order based system with tasks. My main concern with a task-based system is the assumption that everything the user does can be "completed" or that they can be completed in a linear fashion.

E.g. Casting intents; As the order progresses, users may be casting intents multiple times until the order is closed. We wouldn't want to remove that ability until the order has closed, so would a Cast Intent task stay as uncompleted until the order has finished?

I think a possible next step is defining the steps of an order "cast intent phase", "packing phase". Defining what needs to be done at each phase, what are the tasks that are on-going at each phase and what is a task.

[michael-smith-nz]

And yes @ahdinosaur your rough sketch looks ideal. I agree with everything aside from the 'cast intent' being a task(reason above). But also happy to leave that as a task for MVP and come back to that once we receive user feedback

[ahdinosaur]

I think a possible next step is defining the steps of an order "cast intent phase", "packing phase". Defining what needs to be done at each phase, what are the tasks that are on-going at each phase and what is a task.

i started this in #21, so far have 12 stages (!)

[ahdinosaur]

I like our thinking of moving away from a task-based system, to an order based system with tasks. My main concern with a task-based system is the assumption that everything the user does can be "completed" or that they can be completed in a linear fashion.

i'm aiming for a task-based system where the primary top-level tasks are orders. i see the non-linear completion of tasks as a challenge for any real-world-useful task system, not a barrier that we can't overcome. 😸

E.g. Casting intents; As the order progresses, users may be casting intents multiple times until the order is closed. We wouldn't want to remove that ability until the order has closed, so would a Cast Intent task stay as uncompleted until the order has finished?

alternatively, the cast intent task is completed when the user feels they are done, they are still able to check their intent casted anytime later, they may even be assigned a new task which is like "hey check your intent again before the order closes", as say Loomio would push as a notification.

and a silly idea: the group is assigned a cast intent task, which is not completed until the cast intent phase is complete. sound cool but complicated. 😅

[michael-smith-nz]

Hmmmm, maybe I'm confusing tasks with a to-do item.

Can a task be completed but still open? I see the update profile, cast intent tasks falling into that category.

I agree from a programming point of view, everything is a task. But I am concerned that we're also wanting the user to think that way when it doesn't feel natural to them. I'd love for some user testing 😀

I think what is confusing me moment is that we're using the task system as a todo list, wanting users to complete everything on the list, rather than giving them tasks that may, or may not be completed.

[ahdinosaur]

I think what is confusing me moment is that we're using the task system as a todo list, wanting users to complete everything on the list, rather than giving them tasks that may, or may not be completed.

i think my idea is that if the primary tasks are orders, we can get the order tasks and search down the task tree to see the task pipeline. by seeing the whole pipeline, we can see tasks that may, or may not be completed.

then non-primary tasks can be fired as notifications as they are relevant. 🔔

[ahdinosaur]

we could have an 'Orders' section on the dash which shows all current orders you are a part of, as well as 'Tasks' section which shows your active tasks (i.e. non-order Tasks like createProfile, along with tasks for orders where they're at the stage for you to do something).

random idea: with last comment, if non-primary tasks are notifications, then the dashboard could contain only orders.

and in the app bar, we have:

• register / sign in / log out
• orders
• notifications
• directory

?

[danalexilewis]

I remember talking about workflows and I think a workflow in my head is the same as a primary task or pipeline.

I also think I am hearing that we need to distinguish better between the language of our app and the language of our code and that ideally they should overlap as much as possible. User testing the app language would be something we should plan to do as soon as we can run a user through the primary journey.

@ahdinosaur Regarding notifications - for me notifications are not tasks - notifications are where people look to see activity in the app that is relevant to them. Eg you have been assigned a packing task. So we can use them to point to tasks but will also want to be able to send out “news notifications” etc...

[danalexilewis]

Last thought on tasks:

I was thinking about how I explain the way we are building this and was remembering the cyclejs request response drawing (which I love for its clarity)

And was wondering if tasks are essentially the handover to humans from an event driven architecture on the app side. In this sense a task is a “todo” that has come out of an event and that can trigger more events.

What do peeps think?

[ahdinosaur]

diving into implementation details:

• somehow each recipe step needs to embed the information on whether this step should happen or be skipped. maybe we do this with a function that receives the task params and returns true or false. in the above example this is called condition.
• at the beginning, create the task plan for the overall order
  • we also need to create the task plans along a tree walk to the first leaf task plan
  • using a getter, we can start from this task plan and walk the recipe tree to fill in all the missing task plans, to display future plans
• using a before hook on task works create, we create task plans for the "next" steps when the previous step is complete
  • we'll need to check the step that has been completed and walk the task recipe tree to the next task, creating task plans along the way
  • somehow each recipe step needs to embed the information on who the assignee should be. maybe we do this with a function that receives the task params, and returns either a person or a group (which then signals the task is assigned to everyone in the group). most commonly this is for tasks that are assigned to either only the order admin or the entire group.

I remember talking about workflows and I think a workflow in my head is the same as a primary task or pipeline.

agree, this is my motivation for this issue. 👍

Regarding notifications - for me notifications are not tasks - notifications are where people look to see activity in the app that is relevant to them. Eg you have been assigned a packing task. So we can use them to point to tasks but will also want to be able to send out “news notifications” etc...

yeah sorry, i meant when you get assigned a task, we also create a corresponding notification that points to this new task assignment.

And was wondering if tasks are essentially the handover to humans from an event driven architecture on the app side. In this sense a task is a “todo” that has come out of an event and that can trigger more events.

yeah sweet, this makes sense. are there further implications of this?

[danalexilewis]

Hmm the only other thing I can stretch to think of would be task pools and the ability to put a task back into a pool and take one out.

This is mainly a thing we will need for packing when there are a lot of tasks and potentially moving them around fast.

However it does enable more then one person to share tasks. Eg 2 admins - one has some order admin task and decides they can’t do it - they can push it back into the pool or even reassign it to another admin.

As always lov your fractal thinking ;)

[ahdinosaur]

Hmm the only other thing I can stretch to think of would be task pools and the ability to put a task back into a pool and take one out.

yeah, this could be handled by assigning a task to a role (all agents with a specific relationship type with a specific agent): assigning to all admins. or by assigning to a temporary group: the packers of october 2017.

[michael-smith-nz]

From slack discussion:

Dan:

I gave Iain my take on this. It seems the biggest point of tension was when a task should close. Ie is a participate a task or is an action that produces an event in the app a task. For me it is the former.

Though I thought about it some more - we also want to track the number of times people change an intent. So I was wandering what happens when a user changes their intent several days after the first. So my guess is that this is about allowing a user to have multiple order intents at a given price spec and then we select the last as the one to use.

In my brain a task is something the computer has given a human to do and once it’s “complete/done” then it produces an event.

The key question here is can a task involve more then one action (that produces an event in the app) and I think yes. In other words participate in order is a task that allows you to do activity in the app for a certain period of time.

I think there is something in here about us not knowing when someone is “done”. Completing a task is quite a subjective thing. I think that’s why task managers make tasks basically a string plus bool. That way they get the flexibility of the string and specificity of the bool. We don’t want to have checkboxes/ui bool inputs (swipe to tick) for every task so we close or complete a users task after a given period of time - it actually doesn’t matter if they participated or not: we are trying to automate things to present opportunities to the user so that they can participate in an efficient way.

[ahdinosaur]

some silly drawings from a month ago, now scanned:

---

dashboard:

---

tasks page:

[ahdinosaur]

paper prototype draft 1!

home page!

side navigation when not signed in:

side navigation when signed in:

initial dashboard, after signing in:

after you click (+)

now we have an order! it's at the first stage

click into the order and...

intend to buy all the things!

[michael-smith-nz]

Nice @ahdinosaur! Loving the use of icons instead of words/names and also love the onboarding of users to the language you're wanting to use through terms they already may be familiar with.

This is pretty close to what we're already creating which is great to see.

What do you think the next steps are? Should we test it on 3-4 people in the office and get some feedback that way? It's not our "end users" but would still be hugely valuable.