Process oriented UI

107 views
Skip to first unread message

belitre

unread,
Feb 20, 2012, 10:32:47 AM2/20/12
to DDD/CQRS, bog...@tracasa.es
I just wanted to explain a business case where synchrony seems to be
needed.

We are developing a kind of BPM engine that recommends tasks to users.
Tasks can be completed by a couple of people in an office (there is a
small risk of competition between users).

When the user submit a CompleteXXXXTaskCommand, the system deals with
the command, etc. etc. and updates the task recommendation list.
This process can last a few seconds.

Then the system can infer two kind of things:

1. There exists a logical task that should be completed next (users
follow that process 80% of times).
2. There are serveral posible tasks. The user must choose.

In the First case, we want to offer the user with the next task form.
In the latter, an updated recommendation list (which could include the
recent completed task, or not).

Although we can give entertaiment to the user while he waits the first
command to be finished, the overall process seems to be synchronous.

ShuriK

unread,
Feb 21, 2012, 3:25:10 AM2/21/12
to DDD/CQRS
It depends on your architecture. What about async callback from the
read side when the TaskProcessed event will be processed?

belitre

unread,
Mar 1, 2012, 1:14:48 PM3/1/12
to DDD/CQRS
I don't think it depends on my architecture.

The user is waiting for a response... so... Shouldn't I to make this
specific feature the fastest as posible to the user?

MrBretticus

unread,
Mar 2, 2012, 4:00:57 AM3/2/12
to ddd...@googlegroups.com
If the process can take a few seconds then I'd be inclined not to treat this as synchronous.

How likely do you consider the scenario of the task not completing successfully for whatever reason?

belitre

unread,
Mar 2, 2012, 7:17:12 AM3/2/12
to DDD/CQRS
>
> How likely do you consider the scenario of the task not completing
> successfully for whatever reason?
>

uncommon.

MrBretticus

unread,
Mar 2, 2012, 7:44:49 AM3/2/12
to ddd...@googlegroups.com
So if you pre-calculated the next task(s) you could let the user get on with their work, no synchronous behaviour required

belitre

unread,
Mar 4, 2012, 10:12:00 AM3/4/12
to DDD/CQRS

But I can't pre-calculate in this case, because the calculations of
next tasks depends on the results of last completed task.

So I guess just can minimize the effect by informing the user that
"next tasks are being calculated by the system" (obviously this can be
than in an async fashion). No magic :-)

MrBretticus

unread,
Mar 5, 2012, 1:36:07 AM3/5/12
to ddd...@googlegroups.com
Is it that the calculation depends on what is done within the task being completed, or just that you calculate based on the task that was completed? If the latter you could still pre-calculate if the calculation is not complex, based on a what if scenario.

Alternatively something like sending them back to a dashboard that listens for "new tasks available" and refreshes the screen with a list.

belitre

unread,
Mar 5, 2012, 5:01:06 AM3/5/12
to DDD/CQRS


On 5 mar, 07:36, MrBretticus <mrbretti...@gmail.com> wrote:
> Is it that the calculation depends on what is done within the task being
> completed, or just that you calculate based on the task that was completed?
> If the latter you *could* still pre-calculate if the calculation is not
> complex, based on a what if scenario.

The former :-(

> Alternatively something like sending them back to a dashboard that listens
> for "new tasks available" and refreshes the screen with a list.
>

That's it.
Reply all
Reply to author
Forward
0 new messages