Define and visualize the workflow for survey responses

[brandonrosage]

User story: I want to be able to define the workflow that my team and I will use to process incoming survey responses. I also want to see incoming survey responses within that workflow, so I can see what stage responses are in within my workflow.

[ClearLakeHABMap]

This is an interesting idea. Are you thinking graphically or more like drop carrots/dynamic tabs? Would this include the Tasks?

[brandonrosage]

For your review, @jshorland, @natmanning, @caharding, and @rjmackay

---

[NOTE: I'm going to refer to "posts" as "responses"]

I'd propose we leverage the existing "post status" mechanism to articulate (and configure) a response's "stage," since so much of the intent and meaning of those two terms is the same.

Stages, therefore, would be deployment-level entities. a deployment's default, out-of-the-box stages would be:

• Under review
• Published
• Archived

This, of course, honors the existing "post status" configuration, whose language and intent lends itself nicely to what stages are to become.

Each stage has three values:

1. Name
2. Order (it's position within the ordered list of stages)
3. Who can see responses in this stage (two options: "Everyone" or "Users with permission to edit responses")

"Who can see responses in this stage" gives stages the ability to explicitly hide or expose responses from the public. So their stage defines their visibility.

How this might affect existing patterns

Postcards' "status," for example, would now display their stage name with an icon indicating its inherited visibility.

A response who "stage" is "Published":

A response whose "stage" is "Under review":

By extension, this would also be echoed in "Tasks" mode, where postcards display a little metadata atop the task in question:

Toolboxes that offer a control to toggle "Stages" would also adapt to the deployers' configuration of stages. So if they expanded their use stages to include more internal processes, it might look like this:

Visualizing workflow using stages

All of a deployment's stages added together makes a workflow. Offering a distinct "workflow" mode fits nicely into Ushahidi's existing approach to modes, which is to display responses in way best conducive to a showcasing a specific part of their definition.

"Map" mode for responses' location data. "Timeline" for responses' submitted date. And, so, "Workflow" for responses' stage within the deployment's workflow.

I'd propose we do that with a Kanban board pattern, using "lanes" for each stage:

(Forgive that the content of the postcards in the following mockup don't necessarily match their stage)

In this mode, postcards can be dragged and dropped into different lanes to change their stage. Each lane can be scrolled vertically, and the overall board can be scrolled horizontally to reveal any obscured lanes.

In all cases, the last lane is an empty placeholder with a button to "Add stage":

Selecting the name of a single stage atop its lane collapses the other lanes:

Adding and editing stages

You can edit your deployment's stages either via the "Edit stages" button in the toolbar for "Workflow" mode or via Settings > Stages. Its view mimics the visual presentation of the Kanban board, but is editable:

You can add a stage via the "Add stage" button that's located in the placeholder lane for both "Workflow" mode and the "Edit stages" view. The view for adding a stage also mimics the Kanban board it'll appear in:

Configuring a survey to use stages

This approach to stages (replacing "post status) would demand that the current switch control within a survey's settings to "Require responses be reviewed before they're published" be adapted. With this new flexibility, I'd propose this control change to "Default stage for new responses":

This would naturally allow deployers to control which stage incoming responses were dumped into, thereby directing its default visibility, as well.

[rjmackay]

• Does 'who can see responses in this stage' effect who can edit them at all?
• Does this interact with existing tasks at all? (I'm assuming it will interact with some future tasks eventually)

[ClearLakeHABMap]

This is really cool @brandonrosage . I would actually implement this immediately in the ecosystem we are developing as it fits the hierarchical report verification system used in my two deployments.
Also, glad to see the use of this in Austin. The N. Lamar gave it away for me, but later images were confirmation. I left there in 2013 and come back often. I would love to chat more.

[rowasc]

I think we might want to close in favor of ushahidi/platform-pattern-library#205 but I"m not sure, tagging to have it as a reference there

[Erioldoesdesign]

@rowasc yikes. looking at the UI above that's a lot of information on the screen. I would like to be able to simplify this process and make it less UI heavy.

Let's close this and look at the problem statement again after UI refresh. I'll create a new Issue under the ushahidi/platform-pattern-library#205 epic.