Let's suppose our user has two primary tasks. Task 1 is to review all of today's apples, and task 2 is to turn the apples into applesauce.
She is used to using an Apple Review Queue to review each of her apples individually. Then, she opens up an Applesauce Conversion Queue and starts converting the apples into sauce, either one at a time or as a batch.
We are creating the future state for this user, and would like to not make her work through so many queues. (The current state system has a lot of queues, which we're hoping to replace with workflow-based modules). Our user is still likely to review all of her apples before processing them into applesauce, however.
Would it make sense for each task to have its own table or view? Or would it be more appropriate for her to see all apples in one place, some of them having a Waiting for Review status and others with a Ready for Applesauce status?
Advantages for separate views:
- She can have a distinct signal of "clearing the queue" when the review task is done, which would make it easier for her to know when it's time to move on to the processing task
- Any problematic apples would be segregated into their own space, so there's less risk that they'll be forgotten
- She has one clear action per table row
Advantages for a combined view, mixing user tasks:
- The apples are still apples, it's just their status and next task that's changing
- It would be easy enough to filter by status (although a view is technically a filter)
- This would allow for all outstanding apples to be seen on one screen, which could be useful if more than one user is working in the system
What's the better pattern for this?