# MVP - Deliverable
###### tags: `Build-Measure-Learn` `Deliverable` `MVP`

## PV

**For** any company that needs to accelerate obsolete submition processes,
**Who** need to make these submissions processes more efficient for both the company and its customers, improving their user experience and value co-creation and giving them a better and faster way to evaluate submission.
**The** Workflow Manager **is a** platform
**That** makes it easier and more intuitive to both create new submissions and also process them.
**Unlike** what some companies currently have, like email exchanges, that are un-transparent and difficult
**Our product** is user-friendly, simple and organized, and will enable for quicker evaluations on the companies' side and for more submissions on the client side, since the process will be clearer and easier.

## Business Model Canvas


## Requirements

#### Submission
- **[US001]** As a submitter I want to be able to see a tutorial in order to understand how the submission process will proceed.
- **[US002]** As a submitter I want to submit a digital content approval request in order to eventually be able to publish my content on the marketplace.

#### Custom Workflow Creation
- **[US003]** As a marketplace moderator, I want to create a new workflow, so that it can be later instantiated.
- **[US004]** As a marketplace moderator, I want to list all the workflows, so that I can easily manage them.
- **[US005]** As a marketplace moderator, I want to edit a workflow, so that I can keep it updated with the current needs.
- **[US006]** As a marketplace moderator, I want to remove a workflow, so that I can keep the list clean and organised.
- **[US007]** As a marketplace moderator, I want to access detailed documentation, so that I can easily understand how to create workflows.

#### Workflow Monitoring

- **[US008]** As a submitter, I want to login into the application in order to access my account information.
- **[US009]** As a submitter, I want to view a list of my submissions in order to check their state.
- **[US010]** As a submitter, I want to receive a notification through email about my submission in order to know if it has been approved.
- **[US011]** As a submitter, I want to filter my list of submissions in order to view my submissions in a more organized way.
- **[US012]** As a submitter, I want to search for a specific submission by its name in order to find a specific one among all my submissions.
- **[US013]** As a submitter, I want to view a submission process in order to read its submission details.
- **[US014]** As a submitter I want to cancel my ongoing submission process in order to make a new submission with corrected information.
- **[US015]** As a marketplace moderator, I want to login into the application in order to access my account information.
- **[US016]** As a marketplace moderator I want to access a dashboard with all the submitted content in order to manage each one of them.
- **[US017]** As a marketplace moderator I want to receive a notification on Slack when there is a new submission in order to know if there are new submissions on the application.
- **[US018]** As a marketplace moderator, I want to search for a specific submission in order to find a specific one among all the submissions.
- **[US019]** As a marketplace moderator, I want to filter the list of submissions in order to view the submissions in a more organized way.
- **[US020]** As a marketplace moderator I want to pause each submission process in order to temporarily pause its course in the workflow.
- **[US021]** As a marketplace moderator I want to resume each submission process in order to allow it to continue its course in the workflow.
- **[US022]** As a marketplace moderator I want to approve a manual checkpoint in order to give my approval to the checkpoint in question.
- **[US023]** As a marketplace moderator I want to reject a manual checkpoint in order to give my disapproval to the checkpoint in question.
- **[US024]** As a marketplace moderator I want to view the submission process log in order to see every event associated with the process.
- **[US025]** As a marketplace moderator I want to view the current workflow configuration in order to know what is its current composition.

## Architectural Vision
- Architecture diagram
- Technologies used for each module
- Client application: React
- Workflow Engine: Flowable
- Database: PostgresSQL
- Database Manage and Monitoring: PGAdmin
- Development Environment: Docker
- Deploy services: Netlify + Heroku
- Explanation for each technology choice


#### End-User Application - React
React is a front-end development tool, at first developed as a JavaScript library for Facebook. There are two parts to why we chose this tool for the Client Application.
First of all, our client used React on their own application. By also choosing this tool, we could more easily mimic the style and structure already used at Talkdesk. Secondly, React by itself provides a component based structure with clean abstraction. This allowed us to build an application ready for high user interaction and constant updates.

#### Workflow Engine - Flowable
Building an engine from scratch would demand very hard work from the team in such a short period of time, and it probably was impossible to build something sufficiently consistent and stable to present to our clients. That is why we looked into open-source sofwares, that could boost our development speed and allow us to build a specialized solution based on a already tested base. More precisely, we chose to use the Flowable Core, a set of open source business process engines, highy efficient and ready to be run on a server. By taking this path, we also gave our application new opportunities for expansion. The Flowable platform is big and we only chose to use its core. However, for future project iterations, other Flowable services could be paired with what we developed, and increase the value and flexibility of our application.

#### Database - PostgreSQL
PostgreSQL is an extremely flexible and robust open-source relational database. It allows for complex data structures to be created, stored and retrieved. Furthermore, Flowable has out-of-the-box support for it, which makes it more practical to setup a database connection to our back-end technology.
At last, it is also a well-known technology by our client, which increases the value of the final product.

#### Database Manage and Monitoring: PGAdmin
PgAdmin is a management tool for PostgreSQL. It allowed us to manage our PostgreSQL database during development, and also monitor it. Outside the development environment, this tool can be also used during production, being very useful to understand what is happening in the database, and even manage several databases at the same time if needed.

#### Development Environment: Docker
While we planned and worked on our product's architecture, we understood as a team we need a way to setup all of the previous technologies in an environment that would facilitate the technologies setup. It would we could focus more on the features of the product, and bring real value to the client. That is why we chose to use Docker containers to wrap up our application in several components, with benefits such as encapsulation, isolation, portability, and control. Furthermore, we had already discussed that the application should be a standalone application that could be launched from a simple server, which gave us one more reason to choose Docker.

#### Deploy services: Netlify + Heroku
We chose to use these services in order to have a fix location where we could simulate a real case scenario, and allow not only us but also our client to interact with the application. Heroku is a cloud platform that allows developers to build and deploy applications without the overhead of having to configure an infrastructure from scratch. We used it to deploy our backend, the process engineMeanwhile, Netlify is a web hosting infrastructure, where developers can easily run a build process to pre-render all pages in static HTML file. We used that to deploy our frontend application, a React Application.
Both of the services enabled us to quickly bootstrap our application, expose it in more "hostile" environment and get faster and better feedback from the client

## User Manual

### Login
Our project shares the same login page for both types of users. This page contains a form, with a name, password and button that when pressed sends the user to the dashboard.


### Talkdesk User

#### Dashboard/ Homepage
This page has a collection of the applications submmited and their respective states. By clicking on any row, a sidebar opens and shows the process history of that same submission. If we scroll down that sidebar, we will find a view more button that redirects the user to the detailed view of that respective application. Each application also has a gavel icon that redirects the user to the submission detailed page. The page also contains a search bar to find specific applications and a filter to check which apps are already approved, in-review or rejected.
#### Workflow
A page that shows the workflow configured in application.

#### Detailed View
This page has all the information about the application. The page also contains the application state, e.g. in Review, if the user clicks the "View Details" button, a sidebar will appear with the application's history. Besides this page contains two buttons, an accept button and a reject button.


Both these buttons will open a popup in which the moderator should add a comment on why the application was accepted or rejected.

Accept | Reject
:-------------------------:|:-------------------------:
|

### External User
#### Dashboard/ Homepage

The dashboard page has the purpose of showing all the submitted apps by the user. It has a filter tool that lets the user check filter which apps are already approved, in-review or rejected. On this page the user has the option of creating other apps by pressing the NEW APP button which will redirect the user to the submission form.
Besides, the user can check each app by clicking on it, this will redirect the user to the application detailed view.


#### Submission Form
This is form is the bulk of the application. It's objective is receive all of the relevant information. It consists of 9 pages. The user can navigate these 9 pages by using the NEXT button and the PREVIOUS button.
##### Overall App Info
A page on which the user fills the application name, the company, a brief description, a summary of the app and chooses the license type.


##### Contacts
Form on which the user provides the email and his keybase username to estabilish contact with the moderator.
##### Features
The feature page has the objective of describing the application in further detail, the user should give a name,description and summary for each feature. The user can add features with the ADD FEATURE button on the bottom left corner of the page.

##### Trial Plan
Page to describe the perks of the trial plan.

##### Plans and Pricing
The user in this stage of the form can add severall plans with different descriptions and prices for each of them.
##### Visual Assets
Here the user has the option of add images to the application, these images will be presented afterwards in the detailed view of the application.
##### API Scopes
This page informs the user of the default api scopes our application supports, and also gives additional scopes that the user can choose.

##### URLS
This page should be filled with the urls of the application made by the user.

##### Submitted

Informs the user the submission was succesfull.


#### Detailed View
This page has all the information that was submitted on the submitter page. The page also contains the application state, e.g. Rejected, if the user clicks the state a sidebar will appear with a list of the changes made in the application. There is also an edit button which redirects the user back to submission form and allows for changes on the application. The user can aswell delete de application if he so desires.
Approved | Rejected
:-------------------------:|:-------------------------:
|

##### Clicking on State

## Hand-over Process

Since we started listing the application requirements necessary, we agreed together with the client this should developed as a standalone application, that did not need to be integrated within any of Talkdesk's environemnt. That means we could investigate and come up with a solution that would allow the client to have a functional application, without having limitations on what environment it would be launched or extra work in connecting our application to a specific system.

The solution we found to be the best for this case is the use of Docker, more specifically Docker Compose. Firstly, it would just require the client minimum knowledge about how Docker works and what are the steps needed to launch the Docker Compose containers. Moreover, it made it easier to setup the technologies we chose to use on each component. At last, since we used a development environemnt, that will be very similar to the production environment, the effort it will take to make the handover will be small.

So the handover will consist of the following components:
- Application source code;
- Docker Compose and Docker configuration files;
- Client Manual, with all the indications needed to successfully launch the application in a Docker Environment, explaining each one of the services configured;

## Findings and Metrics

### Findings

Through the course of this project, there were valuable lessons that the group learnt. First of all, being the first time working in a multidisciplinary team, it was essential to develop new ways to communicate that worked for everyone. It was also essential to learn how to distribute tasks among the different knowledge areas of the team, which wasn't always easy.
Of course that the current COVID-19 situation forced us all to a detour that none of us were expecting, making us research for efficient ways to keep in contact. During this distance learning and working process, we all had to make adaptations to the way we work and communicate. With the cooperation of the whole team, this was achieved, having been implemented communication channels, like Slack, colaborative working tools, like HackMd, and also development routines, like our "team hacktons". This situation forced us to learn more with this Curricular Unit, since we had to learn what we would learn at any other ocurrence of LGP plus this challenge that was presented to the entire world, the full-remote work setup.

### Metrics

For actually measurable metrics for our project, the only metric used along the project and that the group found usefull was the number of User Stories written for the project versus the number of finished User Stories. In the beginning of the project, there were **25** User Stories. Along the evolution of the project, the group discarded **5** of those User Stories, which became irrelevant for the final project. From the **20** remaining User Stories, the group closed **19**.