Login to the service using provided Metaservice API

This window appears just after login and should be the main window for the service for users without active orders

1. Check geolocation
2. Show results (or results on the map) using geolocation (using Metaservice API)
3. Check filters, apply filters to the result
4. If the map is moved or other location specified any other way - the result is performed for the location specified

This window opens after a click to any position specified on Service discover window. It should provide detailed information about the service as it designed in the service. All the data appears using Metaservice API requests to the service.

This window appears after any type of order initialization executed. All communication with the service core using Metaservice API.

This step should perform assigning an order to service provider. The availability should be checked. Also the order should be confirmed by the service provider who normally will execute service to the customer later.

Mobile Applications and web apps uses only Metaservice API for this case. Metaservice API uses Metaservice Backend API that may use Platform Web API. XMPP used to make all the communication process between client, service provider and Metaservice server in make an order assigned to concrete service provider that is avaliable, accepted by the client and agreed to take an order.

Order process window uses only Metaservice API. This is the main application window during the order process. It is not avaliable without at least one active order.

Contact window is a standard chat window. It opens different chats according to the situation it was opened. It uses XMPP service communication server. Usually it is a room of one of the types below:

1. Client, support, service provider and service bot - to specify any common details, also bot describes current state of the order and listens to any service specific commands.
2. Client and support (for client application) - for contact support outside an order or without service provider (e.g. about service quality and strange accidents)
3. Provider and support (for provider application) - same but for provider needs.

It’s a window contains order details specified by client and discussions (using XMPP 1st type of rooms) about concrete parts of the order. That type of window may occur in some complex services that needs lot of communication on different cases with client.

This window based on TODO list of orders and may be the result of using iCalendar service. Communication only with local Metaservice interfaces.

Communication with Web API to gain client feedback. Web API itself communicated with local service backend and may provide some information to the platform about user rating if needed.

Communication with Web API. Web API itself communicated only with local service backend.

Communication with Web API service that makes calls to payment services.

Communication with Metaservice Wiki (usually static links)

Communication with Metaservice Web API. Metaservice web API might make calls to Platform Web API.

Each app developer specify this type of window according known restrictions and regulations by the service.