.. STATUS: draft .. role:: red ################## Experiment Manager ################## This document will describe what choices were made regarding the user interface of the box-demo. User Interface =============== The experiment manager for the SeizeIt experiment wants to use the user interface for status-checks of the measurements. The interface should contain the necessary information for the manager to instantly see the experiment status. What he/she wants to know is wether Faros and Empatica have measured at least once a day. Workflow ~~~~~~~~ The experiment manager has a certain workflow. By analyzing it we can decide which elements can influence the current workflow and make it more efficient. The workflow is visually defined in the image beneath. Every red computer-mouse means that the experiment manager has to click one time in this scenario. .. image:: images/Workflow.png :width: 100% :alt: Workflow Experiment Manager The workflow starts by accessing the computer, to do this the manager has to click. The goal of the manager is to see if both the devices, Faros and Empatica have measured that day. To see this the experiment manager has to click through the boxes, the devices, a device and finally the manages has access to the data they want to see. It is also not possible for the manager to see the results of multiple boxes. In the new interface we want to **reduce the amount of clicking.** All the necessary information should be displayed on the box so the manager can access this with just one look. Box --- One box should contain the following information. - A name - An indication of the device that is measuring. - The duration of the recordings (as well as which device has recorded it). - A reassign button - An indication of activity for the box With this information the experiment manager has overview over the most important data and can work more efficiently. The design of the boxes are in the image beneath. .. image:: images/boxoverview.png :width: 100% :alt: Workflow Experiment Manager User experience for the box ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In each box a certain user experience is designed. For now the boxes are not completely interactive but this is something to aim towards in the future. The user can reassign the boxes to different patients. Before this happened on a different page and required page hopping. Now the user can click on the "reassign"-button and a pop-up screen will appear. Within this screen the user can enter the new details for the box. .. image:: images/reassign.png :width: 100% :alt: Workflow Experiment Manager .. image:: images/datepicker.png :width: 100% :alt: Workflow Experiment Manager Within the reassignment screen on the box, the user can enter the date through a pop-up calendar. Login-screen ------------ For the project, a login screen was designed so that some of the data is secured. .. image:: images/login.png :width: 100% :alt: Workflow Experiment Manager Experiment overview ------------------- For the selection of experiments, a grid is designed. The grid shows the multiple ongoing experiments. When hovering over an experiment the color changes. .. image:: images/experiment.png :width: 100% :alt: Workflow Experiment Manager .. image:: images/experimenthover.png :width: 100% :alt: Workflow Experiment Manager Long term --------- Over time the box is supposed to be more interactive. Right now it provides only the right information and an option for reassigning the boxes. The interaction we want to add is a link to a detailed patient-page. On this page the experiment manager can access a lot more data that is not available on the box view. This can be data such as recordings from previous patients, errors that occurred and ongoing recordings. Development & Deployment ======================== Development ~~~~~~~~~~~ The application is built using Angular 2 as its framework. The application code is hosted on `github `_. ``git clone git@github.com:byteflies/dashboard.git`` To run the application in development mode with a live-reload server run ``npm start``, then go to ``http://localhost:4200`` in your favorite browser (let's say Chrome). Configuration ~~~~~~~~~~~~~ The application has 2 configuration files: - development: ``src/environments/environment.ts`` - production: ``src/environments/environment.prod.ts`` Currently the only important configuration in there is the **api url**. By default the development configuration is used. When building for production that file is automatically replaced by the production configuration. Deployment ~~~~~~~~~~~ To build and host the application for production execute the following steps: 1. Build for production: ``npm run build-prod``. The output is in a ``dist`` folder. 2. Run ``docker-compose up --build`` to host the application using the included *docker-compose* and *nginx* configuration files.