Update documentation v0.1

docs/commands.rst

@@ -1,10 +0,0 @@
-Commands
-========
-
-The Makefile contains the central entry points for common tasks related to this project.
-
-Syncing data to S3
-^^^^^^^^^^^^^^^^^^
-
-* `make sync_data_to_s3` will use `aws s3 sync` to recursively sync files in `data/` up to `s3://[OPTIONAL] your-bucket-for-syncing-data (do not include 's3://')/data/`.
-* `make sync_data_from_s3` will use `aws s3 sync` to recursively sync files from `s3://[OPTIONAL] your-bucket-for-syncing-data (do not include 's3://')/data/` to `data/`.

docs/conf.py

@@ -41,7 +41,7 @@ source_suffix = '.rst'
 master_doc = 'index'
 
 # General information about the project.
-project = u'moshi-aware'
+project = u'Pipeline'
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the

docs/features/screen.rst

@@ -0,0 +1,16 @@
+Screen features
+===============
+
+Available epochs: daily, morning, afternoon, evening, and night
+
+Notes. An unlock episode is considered as the time between an unlock event and a lock event. iOS recorded these episodes reliable (albeit duplicated lock events within milliseconds from each other). However, in Android there are multiple consecutive unlock/lock events so we keep the closest pair. This happens because ACTION_SCREEN_OFF and ON are "sent when the device becomes non-interactive which may have nothing to do with the screen turning off" see this link
+
+-	Count on: count of screen on events (only available for Android)
+-	Count unlock: count of screen unlock events
+-	Diff count on off: For debug purposes, on and off events should come in pairs, difference should be close to zero then.
+-	Diff count unlock lock, For debug purposes, unlock and lock events should come in pairs, difference should be close to zero then.
+-	Sum duration unlock: sum duration of unlock episodes 
+-	Max duration unlock: maximum duration of unlock episodes
+-	Min duration unlock: minimum duration of unlock episodes
+-	Average duration unlock: average duration of unlock episodes
+-	Std duration unlock: standard deviation of the duration of unlock episodes

docs/getting-started.rst

@@ -1,6 +0,0 @@
-Getting started
-===============
-
-This is where you describe how to get set up on a clean install, including the
-commands necessary to get the raw data (using the `sync_data_from_s3` command,
-for example), and then how to make the cleaned, final data sets.

docs/index.rst

@@ -3,22 +3,14 @@
    You can adapt this file completely to your liking, but it should at least
    contain the root `toctree` directive.
 
-moshi-aware documentation!
-==============================================
+Pipeline for Human Behavior Analysis Using Mobile Data
+======================================================
 
 Contents:
 
 .. toctree::
    :maxdepth: 2
 
-   getting-started
-   commands
-
-
-
-Indices and tables
-==================
-
-* :ref:`genindex`
-* :ref:`modindex`
-* :ref:`search`
+   usage/getting-started
+   usage/installation
+   features/screen

docs/usage/getting-started.rst

@@ -0,0 +1,20 @@
+Getting started
+===============
+
+The goal of this pipeline is to standardize the data cleaning, featuring extraction, analysis, and evaluation of mobile sensing projects. It leverages Cookiecutter, Snakemake, Sphinx, Scypy, R, and Conda to create an end-to-end reproducible environment that can be published along with research papers. 
+
+At the moment, mobile data can be collected using different sensing frameworks (Aware, Beiwe) and hardware (Fitbit). The pipeline is agnostic to these data sources and can unify their analysis. The current implementation only handles data collected with Aware. However, it should be easy to extend it to other providers. 
+
+We recommend reading Snakemake docs, but the main idea behind the pipeline is that every link in the analysis chain is a rule with an input and an output. Input and output (generally) are files, and these files can be manipulated using any programming language (although Snakemake has wrappers for Python, R, and Julia that can make development slightly more comfortable). Snakemake also allows us to spread the execution of rules over multiple cores, which means that a single analysis pipeline can be executed in parallel for all participants in a  study without any code changes.
+
+Available features:
+
+- SMS
+- Calls
+- Bluetooth
+- Google Activity Recognition
+- Battery
+- Location (Barnett's)
+- Screen
+
+We are updating these docs constantly, but if you think something needs clarification, feel free to reach out or submit a pull request in GitHub.

docs/usage/installation.rst

@@ -0,0 +1,48 @@
+Installation
+===============
+
+	- Install MySQL
+
+       - brew install mysql
+	   - brew services start mysql
+
+	- Install R:
+
+       - brew install r
+
+	- Install miniconda
+
+       - brew cask install miniconda
+
+	- Clone our repo
+
+       - git clone https://github.com/JulioV/moshi-aware.git
+
+	- Create a python virtual environment
+
+       - conda env create -f environment.yml
+       - conda init zsh/bash
+       - Restart terminal if necessary
+       - conda activate moshi-env
+
+	- Install r packages:
+
+       - snakemake packrat_install
+       - snakemake packrat_init
+       - snakemake packrat_restore
+
+	- Configure the participants to analyze
+
+       - Add a file per participant. Name it with the label for that participant (p01 for example): "/data/external/pxx" (no extension is necessary)
+       - Add a line with the device_id for that participant as it appears on the db
+       - Add a line with the mobile platform (Android, or iOS)
+
+	- Configure the db connection
+
+       - Create an empty .env file in the root folder
+       - Add and complete the following lines
+			[MY_GROUP_NAME]
+			user=MyUSER
+			password=MyPassword
+			host=MyIP
+			port=3306