Representing progress through a workflow that has parallel activities

Question

I'm trying to create a visual representation of the state of a workflow process that is linear but has parallel branches in it, for example:

A ----> B ----> C1 ----> D ----> E
          \---> C2 --------------^

The idea here would be that C2 would need to be complete before E could be completed, but after completing C1 you could go on to complete D.

I have toyed with the idea of representing this directly as I did above (using some sort of directed graph), but since the goal is for the user to get an idea of the "status" of the workflow quickly, the academic approach might be overwhelming. Is there a good way to condense this information into something more traditional, like a progress bar, or should I bite the bullet and draw the graph as above?

Answer 1

I think your idea of a progress bar is good, we just need to further define the different state of each task and its progress.

A task can have 3 states:

1. Open
2. In Progress
3. Completed

A task could further have sub-tasks (also having 3 states like above) that need to be completed before the parent task can be completed (your "C2" and "E")

For your visual presentation, you can do something like below where you indicate completed tasks (green), sub-tasks (rectangle and labeled "sub-task"), task in progress (red with % complete), and open task (white):

The issue with your proposed mockup is, visually, user don't understand "E" depends on completion of "C2" because "C2" is not near "E".

Hope this helps you out a little on deciding what to do.

...but how do I indicate that subtask C1 can be started after B but must be completed before starting task E? In the mockup above it looks like C1 is a prerequisite to D.

I think this has to do with how you assign and organize tasks. We could simply assign "Sub-task: C1" as a sub-task for D and call it "Sub-task: D1". This would indicate D1 need to be finished before user can start Task E.

Answer 2

The mock-up below should be a robust approach, even if more visual styling recommended, but it is critical to clearly communicate "Done / Not Done" and "Available / Not Available"

While user may default to doing "Task C2" before "Task D", nothing is preventing the discovery that "Task D" is available.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Note: if clicks the unavailable "Task E" in current state it should provide feedback on dependant tasks.