This is the first SocketIO based interaction, after Client posts new request the app now works based on messages.

We will define the flow using lanes so that you can validate experience for both worker and client. It all starts when the client submits a new request from Client Home view, now the worker needs to apply for the work from Worker Home

The logic is very straight forward:

  1. Client Posts New Request
  2. SocketIO sends "new" message to channel or specific worker
  3. If Worker is Eligible then option appears in View
  4. If Worker doesn't want to accept then he discards the opportunity
  5. Client waits for 10mins if no reply then triggers request Cancel
  6. If Worker accepts then he posts to WorkerAccept and "Apply" Socket Message is Triggered
  7. When Client receives socket message changes view to Work in Progress
  8. When Worker accepts and sends message, view change to Work in Progress

The important considerations are:

  • Client needs to cancel request if timeout expires
  • Discards are managed and stored locally
  • Options are displayed based on eligibility, processed on app side
  • App needs to consider/retake state if closed or inactive
  • Error Messages (good or bad) need to be displayed before changing views

Work In Progress View Anatomy (Client)

When the Client switches to Work in Progress, this screen has free design but it needs to have the following elements for functionality:

1) Distance of Worker with respect to the client

2) Latest worker rating in stars

3) Worker avatar

4) Worker name

5) Description of Request

6) Category of Request

7) Pay Button

8) Chat Button

9) Call Button

10) Close Request Button

All buttons, and the distance text, link to New Views that will be described later.

Work In Progress View Anatomy (Worker)

When the Worker switches to Work in Progress, this screen has free design but it needs to have the following elements for functionality:

1) Name of the Client
2) Map of Current Location & Job Location
3) Work Information Button
4) Chat Button
5) Call Button
6) Close Request Button

Complimentary Views

All elements of the anatomy are self explanatory but some require more detail:

1) Work Information Button (Worker)

This is opened as an alert view on top of the active display and it summarizes the request so that the expert can view details about it. Again, design is free but the elements that It should contain are:

a) Name of Client

b) Address of Client

c) DateTime of Request

d) Category of Request

e) Description of Request

f) Image of Request (if any)

g) Close Alert Button

2) Close Request Button (Worker/Client)

This button is used to finalise the request as "active", this means that both worker and client will be released to do other requests, and from this point on, they can retrieve this request from the history on the side menu.

We will review this flow in detail, from a backend/API perspective, later. For now, the important thing is to remember that this button has 2 options

a) Yes I'm happy, all went well with contact
b) No I'm unhappy, this wasn't successful

Keep in mind that it has nothing to do with rating the experience yet (experience can be rated at any time from the side menu because work doesn't happen sequentially)

Other elements, such as Pay Button will be seen later in other flows.

Transitional Alerts

Whenever a message is received that triggers a change in view, it is important to alert user. Ideally this will be AFTER the change in view so that flow is non-dependant (unless success is false). The basic Transitional alerts for this flow are:

Worker Apply (Client View)

Whenever a Client gets an Apply SocketIO message it means that the worker accepted the job. After having transitioned from Waiting Screen with Counter to Work in Progress, you need to display an alert notifying the client that the worker accepted. Alert will simply include:

1) Title Message
2) Worker Avatar
3) Worker Rating
4) Ok Button to close

Please consider that worker can be new (with no rating), we suggest replacing stars with a "New Worker" label.
Worker Apply (Worker View: API-Success)

It is important to let the worker know that they got the job and that they are expected to contact client immediately. At the very least this alert should include:

1) Title of Confirmation
2) Subtitle with requested action
3) Motivational Image
4) Button to Close alert
5) Client Name
6) Client Address
Worker Apply (Worker View: API-Failure)

This alert should follow a standard error management format, notifying in this case the worker that his application failed. This could happen because a communication failure, a race condition, an eligibility validation or other reasons.

This view should be friendly to not discourage the worker. It should include friendly brief text description, error title, possibly an image and an OK button to close the alert.
Client Cancel (Auto-Timeout)

When timeout happens and there is no reply, Client app automatically cancels the request so that it is no longer available. Please note this does not apply to inquiries which we will see in a later flow. This is why the timer is important, it gives margin to apply and doesn't leave requests unattended.

Again, we should use the standard error alert with a nice friendly image and text.

Eligibility Rules

If Messages are sent to $channel, instead of being send directly to the target then you must filter eligibility. Typically this happens with new job opportunities where you must filter if the expert can apply or not.  Validations need to happen on appside as described in the flow, please note that when you get Job opportunities from the getJobs service, the backend does all these validations for you. so you need to worry only on the client side. This happens because on a general channel broadcast we cannot identify/filter who is receiving the information.

In order for the worker to be eligible for a job opportunity the following filter is required:

  1. Expert Needs to be active (meProfile.expertActive)
  2. Requests needs to be non-exclusive "0" or if it is exclusive, meProfile.expertSource needs to be equal to exclusive value (which is the ID of the partner that is requesting a job to only be posted to closed group)
  3. The expert needs to work in that category, meProfile.categories array must contain Req.CatID value.
  4. Using Harvesine formula for distance between two points, the distance needs to be within the allowed range for that expert meprofile.maxKms
  5. Worker cannot be contained in the userID array contained in BlockedXP (these are banned workers)
  6. You must add the Delay seconds contained in the message before displaying (worker penalisation)