Deployed c734c8b to 0.1 with MkDocs 1.1.2 and mike 0.5.5

0.1/features/feature-introduction/index.html

@@ -984,6 +984,10 @@
 <p class="admonition-title">Hint</p>
 <p>We recommend reading this page if you are using RAPIDS for the first time</p>
 </div>
+<div class="admonition hint">
+<p class="admonition-title">Hint</p>
+<p>All sensor features are stored under <code>/data/processed/features</code> on files per sensor, per participant and per study (all participants).</p>
+</div>
 <div class="admonition example">
 <p class="admonition-title">Config section example for <code>PHONE_ACCELEROMETER</code></p>
 <div class="highlight"><pre><span></span><code><span class="c1"># 1) Config section</span>
@@ -1016,14 +1020,14 @@
 </code></pre></div>
 </div>
 <h2 id="sensor-parameters">Sensor Parameters<a class="headerlink" href="#sensor-parameters" title="Permanent link">&para;</a></h2>
-<p>Each sensor configuration section has a <code>Parameters</code> subsection (see <code>#2</code> in the example). These are parameters that affect different aspects of how the raw data is downloaded, and processed. The <code>TABLE</code> parameter exists for every sensor, but some sensors will have extra parameters like <a href="../phone-locations/"><code>[PHONE_LOCATIONS]</code></a>. We explain these parameters in a table at the top of each sensor documentation page.</p>
+<p>Each sensor configuration section has a &ldquo;parameters&rdquo; subsection (see <code>#2</code> in the example). These are parameters that affect different aspects of how the raw data is downloaded, and processed. The <code>TABLE</code> parameter exists for every sensor, but some sensors will have extra parameters like <a href="../phone-locations/"><code>[PHONE_LOCATIONS]</code></a>. We explain these parameters in a table at the top of each sensor documentation page.</p>
 <h2 id="sensor-providers">Sensor Providers<a class="headerlink" href="#sensor-providers" title="Permanent link">&para;</a></h2>
 <p>Each sensor configuration section can have zero, one or more behavioral feature <strong>providers</strong> (see <code>#3</code> in the example). A provider is a script created by the core RAPIDS team or other researchers that extracts behavioral features for that sensor. In this example, accelerometer has two providers: RAPIDS (see <code>#4</code>) and PANDA (see <code>#5</code>).</p>
 <h3 id="provider-parameters">Provider Parameters<a class="headerlink" href="#provider-parameters" title="Permanent link">&para;</a></h3>
 <p>Each provider has parameters that affect the computation of the behavioral features it offers (see <code>#4.1</code> or <code>#5.1</code> in the example). These parameters will include at least a <code>[COMPUTE]</code> flag that you switch to <code>True</code> to extract a provider&rsquo;s behavioral features. </p>
 <p>We explain every provider&rsquo;s parameter in a table under the <code>Parameters description</code> heading on each provider documentation page.</p>
 <h3 id="provider-features">Provider Features<a class="headerlink" href="#provider-features" title="Permanent link">&para;</a></h3>
-<p>Each provider offers a set of behavioral features (see <code>#4.2</code> or <code>#5.2</code> in the example). For some providers these features are grouped in an array (like those for <code>RAPIDS</code> provider in <code>#4.2</code>) but for others they are grouped in a collection of arrays (like those for <code>PANDAS</code> provider in <code>#5.2</code>) depending on the meaning and purpose of those features. In either case you can delete the features you are not interested in and they will not be included in the sensor&rsquo;s output feature file. </p>
+<p>Each provider offers a set of behavioral features (see <code>#4.2</code> or <code>#5.2</code> in the example). For some providers these features are grouped in an array (like those for <code>RAPIDS</code> provider in <code>#4.2</code>) but for others they are grouped in a collection of arrays depending on the meaning and purpose of those features (like those for <code>PANDAS</code> provider in <code>#5.2</code>). In either case, you can delete the features you are not interested in and they will not be included in the sensor&rsquo;s output feature file. </p>
 <p>We explain each behavioral feature in a table under the <code>Features description</code> heading on each provider documentation page.</p>
 <div class="admonition hint">
 <p class="admonition-title">Hint</p>

0.1/features/fitbit-heartrate-intraday/index.html

@@ -938,11 +938,12 @@
 <tbody>
 <tr>
 <td><code>[TABLE]</code></td>
-<td>Database table name or file path where the heart rate intraday data is stored. Source data type and column format are defined in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a>.</td>
+<td>Database table name or file path where the heart rate intraday data is stored. The configuration keys in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a> control whether this parameter is interpreted as table or file.</td>
 </tr>
 </tbody>
 </table>
-<p>Column format could be <code>JSON</code> or <code>PLAIN_TEXT</code>. Data with <code>JSON</code> column format is obtained from Fitbit API directly. Summary data and intraday data come together in <code>JSON</code> format. Each row doesn&rsquo;t have to contain the data for a single day as it depends on the way Fitbit API is queried. Examples of the source data with two formats are as follows. Data with <code>JSON</code> format is chunked.</p>
+<p>The format of the column(s) containing the Fitbit sensor data can be <code>JSON</code> or <code>PLAIN_TEXT</code>. The data in <code>JSON</code> format is obtained directly from the Fitbit API. We support <code>PLAIN_TEXT</code> in case you already parsed your data and don&rsquo;t have access to your participants&rsquo; Fitbit accounts anymore. If your data is in <code>JSON</code> format then summary and intraday data come packed together. </p>
+<p>We provide examples of the input format that RAPIDS expects, note that both examples for <code>JSON</code> and <code>PLAIN_TEXT</code> are tabular and the actual format difference comes in the <code>fitbit_data</code> column (we truncate the <code>JSON</code> example for brevity).</p>
 <details class="example"><summary>Example of the structure of source data</summary><div class="tabbed-set" data-tabs="1:2"><input checked="checked" id="__tabbed_1_1" name="__tabbed_1" type="radio" /><label for="__tabbed_1_1">JSON</label><div class="tabbed-content">
 <table>
 <thead>

0.1/features/fitbit-heartrate-summary/index.html

@@ -938,11 +938,12 @@
 <tbody>
 <tr>
 <td><code>[TABLE]</code></td>
-<td>Database table name or file path where the heart rate summary data is stored. Source data type and column format are defined in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a>.</td>
+<td>Database table name or file path where the heart rate summary data is stored. The configuration keys in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a> control whether this parameter is interpreted as table or file.</td>
 </tr>
 </tbody>
 </table>
-<p>Column format could be <code>JSON</code> or <code>PLAIN_TEXT</code>. Data with <code>JSON</code> column format is obtained from Fitbit API directly. Summary data and intraday data come together in <code>JSON</code> format. Each row doesn&rsquo;t have to contain the data for a single day as it depends on the way Fitbit API is queried. Examples of the source data with two formats are as follows. Data with <code>JSON</code> format is chunked.</p>
+<p>The format of the column(s) containing the Fitbit sensor data can be <code>JSON</code> or <code>PLAIN_TEXT</code>. The data in <code>JSON</code> format is obtained directly from the Fitbit API. We support <code>PLAIN_TEXT</code> in case you already parsed your data and don&rsquo;t have access to your participants&rsquo; Fitbit accounts anymore. If your data is in <code>JSON</code> format then summary and intraday data come packed together. </p>
+<p>We provide examples of the input format that RAPIDS expects, note that both examples for <code>JSON</code> and <code>PLAIN_TEXT</code> are tabular and the actual format difference comes in the <code>fitbit_data</code> column (we truncate the <code>JSON</code> example for brevity).</p>
 <details class="example"><summary>Example of the structure of source data</summary><div class="tabbed-set" data-tabs="1:2"><input checked="checked" id="__tabbed_1_1" name="__tabbed_1" type="radio" /><label for="__tabbed_1_1">JSON</label><div class="tabbed-content">
 <table>
 <thead>

0.1/features/fitbit-sleep-summary/index.html

@@ -938,11 +938,12 @@
 <tbody>
 <tr>
 <td><code>[TABLE]</code></td>
-<td>Database table name or file path where the sleep summary data is stored. Source data type and column format are defined in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a>.</td>
+<td>Database table name or file path where the sleep summary data is stored. The configuration keys in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a> control whether this parameter is interpreted as table or file.</td>
 </tr>
 </tbody>
 </table>
-<p>Column format could be <code>JSON</code> or <code>PLAIN_TEXT</code>. Data with <code>JSON</code> column format is obtained from Fitbit API directly. Summary data and intraday data come together in <code>JSON</code> format. Each row doesn&rsquo;t have to contain the data for a single day as it depends on the way Fitbit API is queried. Examples of the source data with two formats are as follows. Data with <code>JSON</code> format is chunked.</p>
+<p>The format of the column(s) containing the Fitbit sensor data can be <code>JSON</code> or <code>PLAIN_TEXT</code>. The data in <code>JSON</code> format is obtained directly from the Fitbit API. We support <code>PLAIN_TEXT</code> in case you already parsed your data and don&rsquo;t have access to your participants&rsquo; Fitbit accounts anymore. If your data is in <code>JSON</code> format then summary and intraday data come packed together. </p>
+<p>We provide examples of the input format that RAPIDS expects, note that both examples for <code>JSON</code> and <code>PLAIN_TEXT</code> are tabular and the actual format difference comes in the <code>fitbit_data</code> column (we truncate the <code>JSON</code> example for brevity).</p>
 <details class="example"><summary>Example of the structure of source data with Fitbit’s sleep API Version 1</summary><div class="tabbed-set" data-tabs="1:2"><input checked="checked" id="__tabbed_1_1" name="__tabbed_1" type="radio" /><label for="__tabbed_1_1">JSON</label><div class="tabbed-content">
 <table>
 <thead>

0.1/features/fitbit-steps-intraday/index.html

@@ -938,11 +938,12 @@
 <tbody>
 <tr>
 <td><code>[TABLE]</code></td>
-<td>Database table name or file path where the steps intraday data is stored. Source data type and column format are defined in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a>.</td>
+<td>Database table name or file path where the steps intraday data is stored. The configuration keys in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a> control whether this parameter is interpreted as table or file.</td>
 </tr>
 </tbody>
 </table>
-<p>Column format could be <code>JSON</code> or <code>PLAIN_TEXT</code>. Data with <code>JSON</code> column format is obtained from Fitbit API directly. Summary data and intraday data come together in <code>JSON</code> format. Each row doesn&rsquo;t have to contain the data for a single day as it depends on the way Fitbit API is queried. Examples of the source data with two formats are as follows. Data with <code>JSON</code> format is chunked.</p>
+<p>The format of the column(s) containing the Fitbit sensor data can be <code>JSON</code> or <code>PLAIN_TEXT</code>. The data in <code>JSON</code> format is obtained directly from the Fitbit API. We support <code>PLAIN_TEXT</code> in case you already parsed your data and don&rsquo;t have access to your participants&rsquo; Fitbit accounts anymore. If your data is in <code>JSON</code> format then summary and intraday data come packed together. </p>
+<p>We provide examples of the input format that RAPIDS expects, note that both examples for <code>JSON</code> and <code>PLAIN_TEXT</code> are tabular and the actual format difference comes in the <code>fitbit_data</code> column (we truncate the <code>JSON</code> example for brevity).</p>
 <details class="example"><summary>Example of the structure of source data</summary><div class="tabbed-set" data-tabs="1:2"><input checked="checked" id="__tabbed_1_1" name="__tabbed_1" type="radio" /><label for="__tabbed_1_1">JSON</label><div class="tabbed-content">
 <table>
 <thead>

0.1/features/fitbit-steps-summary/index.html

@@ -938,11 +938,12 @@
 <tbody>
 <tr>
 <td><code>[TABLE]</code></td>
-<td>Database table name or file path where the steps summary data is stored. Source data type and column format are defined in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a>.</td>
+<td>Database table name or file path where the steps summary data is stored. The configuration keys in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a> control whether this parameter is interpreted as table or file.</td>
 </tr>
 </tbody>
 </table>
-<p>Column format could be <code>JSON</code> or <code>PLAIN_TEXT</code>. Data with <code>JSON</code> column format is obtained from Fitbit API directly. Summary data and intraday data come together in <code>JSON</code> format. Each row doesn&rsquo;t have to contain the data for a single day as it depends on the way Fitbit API is queried. Examples of the source data with two formats are as follows. Data with <code>JSON</code> format is chunked.</p>
+<p>The format of the column(s) containing the Fitbit sensor data can be <code>JSON</code> or <code>PLAIN_TEXT</code>. The data in <code>JSON</code> format is obtained directly from the Fitbit API. We support <code>PLAIN_TEXT</code> in case you already parsed your data and don&rsquo;t have access to your participants&rsquo; Fitbit accounts anymore. If your data is in <code>JSON</code> format then summary and intraday data come packed together. </p>
+<p>We provide examples of the input format that RAPIDS expects, note that both examples for <code>JSON</code> and <code>PLAIN_TEXT</code> are tabular and the actual format difference comes in the <code>fitbit_data</code> column (we truncate the <code>JSON</code> example for brevity).</p>
 <details class="example"><summary>Example of the structure of source data</summary><div class="tabbed-set" data-tabs="1:2"><input checked="checked" id="__tabbed_1_1" name="__tabbed_1" type="radio" /><label for="__tabbed_1_1">JSON</label><div class="tabbed-content">
 <table>
 <thead>

0.1/index.html

@@ -976,7 +976,7 @@
 <li><strong>Private</strong>. All your data is processed locally.</li>
 </ol>
 <h2 id="how-is-it-organized">How is it organized?<a class="headerlink" href="#how-is-it-organized" title="Permanent link">&para;</a></h2>
-<p>In broad terms the <code>config.yaml</code>, <code>.env</code> files, participant files, and day segment files are the only ones that you will have to modify. All data is stored in <code>data/</code> and all scripts are stored in <code>src/</code>. For more information see RAPIDS&rsquo; <a href="file-structure/">File Structure</a>.</p>
+<p>In broad terms the <code>config.yaml</code>, <a href="../setup/configuration/#database-credentials"><code>.env</code> file</a>, <a href="../setup/configuration/#participant-files">participants files</a>, <a href="../setup/configuration/#day-segments">day segment files</a> are the only ones that you will have to modify. All data is stored in <code>data/</code> and all scripts are stored in <code>src/</code>. For more information see RAPIDS&rsquo; <a href="file-structure/">File Structure</a>.</p>
                 
               
               

latest/features/feature-introduction/index.html

@@ -984,6 +984,10 @@
 <p class="admonition-title">Hint</p>
 <p>We recommend reading this page if you are using RAPIDS for the first time</p>
 </div>
+<div class="admonition hint">
+<p class="admonition-title">Hint</p>
+<p>All sensor features are stored under <code>/data/processed/features</code> on files per sensor, per participant and per study (all participants).</p>
+</div>
 <div class="admonition example">
 <p class="admonition-title">Config section example for <code>PHONE_ACCELEROMETER</code></p>
 <div class="highlight"><pre><span></span><code><span class="c1"># 1) Config section</span>
@@ -1016,14 +1020,14 @@
 </code></pre></div>
 </div>
 <h2 id="sensor-parameters">Sensor Parameters<a class="headerlink" href="#sensor-parameters" title="Permanent link">&para;</a></h2>
-<p>Each sensor configuration section has a <code>Parameters</code> subsection (see <code>#2</code> in the example). These are parameters that affect different aspects of how the raw data is downloaded, and processed. The <code>TABLE</code> parameter exists for every sensor, but some sensors will have extra parameters like <a href="../phone-locations/"><code>[PHONE_LOCATIONS]</code></a>. We explain these parameters in a table at the top of each sensor documentation page.</p>
+<p>Each sensor configuration section has a &ldquo;parameters&rdquo; subsection (see <code>#2</code> in the example). These are parameters that affect different aspects of how the raw data is downloaded, and processed. The <code>TABLE</code> parameter exists for every sensor, but some sensors will have extra parameters like <a href="../phone-locations/"><code>[PHONE_LOCATIONS]</code></a>. We explain these parameters in a table at the top of each sensor documentation page.</p>
 <h2 id="sensor-providers">Sensor Providers<a class="headerlink" href="#sensor-providers" title="Permanent link">&para;</a></h2>
 <p>Each sensor configuration section can have zero, one or more behavioral feature <strong>providers</strong> (see <code>#3</code> in the example). A provider is a script created by the core RAPIDS team or other researchers that extracts behavioral features for that sensor. In this example, accelerometer has two providers: RAPIDS (see <code>#4</code>) and PANDA (see <code>#5</code>).</p>
 <h3 id="provider-parameters">Provider Parameters<a class="headerlink" href="#provider-parameters" title="Permanent link">&para;</a></h3>
 <p>Each provider has parameters that affect the computation of the behavioral features it offers (see <code>#4.1</code> or <code>#5.1</code> in the example). These parameters will include at least a <code>[COMPUTE]</code> flag that you switch to <code>True</code> to extract a provider&rsquo;s behavioral features. </p>
 <p>We explain every provider&rsquo;s parameter in a table under the <code>Parameters description</code> heading on each provider documentation page.</p>
 <h3 id="provider-features">Provider Features<a class="headerlink" href="#provider-features" title="Permanent link">&para;</a></h3>
-<p>Each provider offers a set of behavioral features (see <code>#4.2</code> or <code>#5.2</code> in the example). For some providers these features are grouped in an array (like those for <code>RAPIDS</code> provider in <code>#4.2</code>) but for others they are grouped in a collection of arrays (like those for <code>PANDAS</code> provider in <code>#5.2</code>) depending on the meaning and purpose of those features. In either case you can delete the features you are not interested in and they will not be included in the sensor&rsquo;s output feature file. </p>
+<p>Each provider offers a set of behavioral features (see <code>#4.2</code> or <code>#5.2</code> in the example). For some providers these features are grouped in an array (like those for <code>RAPIDS</code> provider in <code>#4.2</code>) but for others they are grouped in a collection of arrays depending on the meaning and purpose of those features (like those for <code>PANDAS</code> provider in <code>#5.2</code>). In either case, you can delete the features you are not interested in and they will not be included in the sensor&rsquo;s output feature file. </p>
 <p>We explain each behavioral feature in a table under the <code>Features description</code> heading on each provider documentation page.</p>
 <div class="admonition hint">
 <p class="admonition-title">Hint</p>

latest/features/fitbit-heartrate-intraday/index.html

@@ -938,11 +938,12 @@
 <tbody>
 <tr>
 <td><code>[TABLE]</code></td>
-<td>Database table name or file path where the heart rate intraday data is stored. Source data type and column format are defined in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a>.</td>
+<td>Database table name or file path where the heart rate intraday data is stored. The configuration keys in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a> control whether this parameter is interpreted as table or file.</td>
 </tr>
 </tbody>
 </table>
-<p>Column format could be <code>JSON</code> or <code>PLAIN_TEXT</code>. Data with <code>JSON</code> column format is obtained from Fitbit API directly. Summary data and intraday data come together in <code>JSON</code> format. Each row doesn&rsquo;t have to contain the data for a single day as it depends on the way Fitbit API is queried. Examples of the source data with two formats are as follows. Data with <code>JSON</code> format is chunked.</p>
+<p>The format of the column(s) containing the Fitbit sensor data can be <code>JSON</code> or <code>PLAIN_TEXT</code>. The data in <code>JSON</code> format is obtained directly from the Fitbit API. We support <code>PLAIN_TEXT</code> in case you already parsed your data and don&rsquo;t have access to your participants&rsquo; Fitbit accounts anymore. If your data is in <code>JSON</code> format then summary and intraday data come packed together. </p>
+<p>We provide examples of the input format that RAPIDS expects, note that both examples for <code>JSON</code> and <code>PLAIN_TEXT</code> are tabular and the actual format difference comes in the <code>fitbit_data</code> column (we truncate the <code>JSON</code> example for brevity).</p>
 <details class="example"><summary>Example of the structure of source data</summary><div class="tabbed-set" data-tabs="1:2"><input checked="checked" id="__tabbed_1_1" name="__tabbed_1" type="radio" /><label for="__tabbed_1_1">JSON</label><div class="tabbed-content">
 <table>
 <thead>

latest/features/fitbit-heartrate-summary/index.html

@@ -938,11 +938,12 @@
 <tbody>
 <tr>
 <td><code>[TABLE]</code></td>
-<td>Database table name or file path where the heart rate summary data is stored. Source data type and column format are defined in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a>.</td>
+<td>Database table name or file path where the heart rate summary data is stored. The configuration keys in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a> control whether this parameter is interpreted as table or file.</td>
 </tr>
 </tbody>
 </table>
-<p>Column format could be <code>JSON</code> or <code>PLAIN_TEXT</code>. Data with <code>JSON</code> column format is obtained from Fitbit API directly. Summary data and intraday data come together in <code>JSON</code> format. Each row doesn&rsquo;t have to contain the data for a single day as it depends on the way Fitbit API is queried. Examples of the source data with two formats are as follows. Data with <code>JSON</code> format is chunked.</p>
+<p>The format of the column(s) containing the Fitbit sensor data can be <code>JSON</code> or <code>PLAIN_TEXT</code>. The data in <code>JSON</code> format is obtained directly from the Fitbit API. We support <code>PLAIN_TEXT</code> in case you already parsed your data and don&rsquo;t have access to your participants&rsquo; Fitbit accounts anymore. If your data is in <code>JSON</code> format then summary and intraday data come packed together. </p>
+<p>We provide examples of the input format that RAPIDS expects, note that both examples for <code>JSON</code> and <code>PLAIN_TEXT</code> are tabular and the actual format difference comes in the <code>fitbit_data</code> column (we truncate the <code>JSON</code> example for brevity).</p>
 <details class="example"><summary>Example of the structure of source data</summary><div class="tabbed-set" data-tabs="1:2"><input checked="checked" id="__tabbed_1_1" name="__tabbed_1" type="radio" /><label for="__tabbed_1_1">JSON</label><div class="tabbed-content">
 <table>
 <thead>

latest/features/fitbit-sleep-summary/index.html

@@ -938,11 +938,12 @@
 <tbody>
 <tr>
 <td><code>[TABLE]</code></td>
-<td>Database table name or file path where the sleep summary data is stored. Source data type and column format are defined in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a>.</td>
+<td>Database table name or file path where the sleep summary data is stored. The configuration keys in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a> control whether this parameter is interpreted as table or file.</td>
 </tr>
 </tbody>
 </table>
-<p>Column format could be <code>JSON</code> or <code>PLAIN_TEXT</code>. Data with <code>JSON</code> column format is obtained from Fitbit API directly. Summary data and intraday data come together in <code>JSON</code> format. Each row doesn&rsquo;t have to contain the data for a single day as it depends on the way Fitbit API is queried. Examples of the source data with two formats are as follows. Data with <code>JSON</code> format is chunked.</p>
+<p>The format of the column(s) containing the Fitbit sensor data can be <code>JSON</code> or <code>PLAIN_TEXT</code>. The data in <code>JSON</code> format is obtained directly from the Fitbit API. We support <code>PLAIN_TEXT</code> in case you already parsed your data and don&rsquo;t have access to your participants&rsquo; Fitbit accounts anymore. If your data is in <code>JSON</code> format then summary and intraday data come packed together. </p>
+<p>We provide examples of the input format that RAPIDS expects, note that both examples for <code>JSON</code> and <code>PLAIN_TEXT</code> are tabular and the actual format difference comes in the <code>fitbit_data</code> column (we truncate the <code>JSON</code> example for brevity).</p>
 <details class="example"><summary>Example of the structure of source data with Fitbit’s sleep API Version 1</summary><div class="tabbed-set" data-tabs="1:2"><input checked="checked" id="__tabbed_1_1" name="__tabbed_1" type="radio" /><label for="__tabbed_1_1">JSON</label><div class="tabbed-content">
 <table>
 <thead>

latest/features/fitbit-steps-intraday/index.html

@@ -938,11 +938,12 @@
 <tbody>
 <tr>
 <td><code>[TABLE]</code></td>
-<td>Database table name or file path where the steps intraday data is stored. Source data type and column format are defined in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a>.</td>
+<td>Database table name or file path where the steps intraday data is stored. The configuration keys in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a> control whether this parameter is interpreted as table or file.</td>
 </tr>
 </tbody>
 </table>
-<p>Column format could be <code>JSON</code> or <code>PLAIN_TEXT</code>. Data with <code>JSON</code> column format is obtained from Fitbit API directly. Summary data and intraday data come together in <code>JSON</code> format. Each row doesn&rsquo;t have to contain the data for a single day as it depends on the way Fitbit API is queried. Examples of the source data with two formats are as follows. Data with <code>JSON</code> format is chunked.</p>
+<p>The format of the column(s) containing the Fitbit sensor data can be <code>JSON</code> or <code>PLAIN_TEXT</code>. The data in <code>JSON</code> format is obtained directly from the Fitbit API. We support <code>PLAIN_TEXT</code> in case you already parsed your data and don&rsquo;t have access to your participants&rsquo; Fitbit accounts anymore. If your data is in <code>JSON</code> format then summary and intraday data come packed together. </p>
+<p>We provide examples of the input format that RAPIDS expects, note that both examples for <code>JSON</code> and <code>PLAIN_TEXT</code> are tabular and the actual format difference comes in the <code>fitbit_data</code> column (we truncate the <code>JSON</code> example for brevity).</p>
 <details class="example"><summary>Example of the structure of source data</summary><div class="tabbed-set" data-tabs="1:2"><input checked="checked" id="__tabbed_1_1" name="__tabbed_1" type="radio" /><label for="__tabbed_1_1">JSON</label><div class="tabbed-content">
 <table>
 <thead>

latest/features/fitbit-steps-summary/index.html

@@ -938,11 +938,12 @@
 <tbody>
 <tr>
 <td><code>[TABLE]</code></td>
-<td>Database table name or file path where the steps summary data is stored. Source data type and column format are defined in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a>.</td>
+<td>Database table name or file path where the steps summary data is stored. The configuration keys in <a href="../../setup/configuration/#device-data-source-configuration">Device Data Source Configuration</a> control whether this parameter is interpreted as table or file.</td>
 </tr>
 </tbody>
 </table>
-<p>Column format could be <code>JSON</code> or <code>PLAIN_TEXT</code>. Data with <code>JSON</code> column format is obtained from Fitbit API directly. Summary data and intraday data come together in <code>JSON</code> format. Each row doesn&rsquo;t have to contain the data for a single day as it depends on the way Fitbit API is queried. Examples of the source data with two formats are as follows. Data with <code>JSON</code> format is chunked.</p>
+<p>The format of the column(s) containing the Fitbit sensor data can be <code>JSON</code> or <code>PLAIN_TEXT</code>. The data in <code>JSON</code> format is obtained directly from the Fitbit API. We support <code>PLAIN_TEXT</code> in case you already parsed your data and don&rsquo;t have access to your participants&rsquo; Fitbit accounts anymore. If your data is in <code>JSON</code> format then summary and intraday data come packed together. </p>
+<p>We provide examples of the input format that RAPIDS expects, note that both examples for <code>JSON</code> and <code>PLAIN_TEXT</code> are tabular and the actual format difference comes in the <code>fitbit_data</code> column (we truncate the <code>JSON</code> example for brevity).</p>
 <details class="example"><summary>Example of the structure of source data</summary><div class="tabbed-set" data-tabs="1:2"><input checked="checked" id="__tabbed_1_1" name="__tabbed_1" type="radio" /><label for="__tabbed_1_1">JSON</label><div class="tabbed-content">
 <table>
 <thead>

latest/index.html

@@ -976,7 +976,7 @@
 <li><strong>Private</strong>. All your data is processed locally.</li>
 </ol>
 <h2 id="how-is-it-organized">How is it organized?<a class="headerlink" href="#how-is-it-organized" title="Permanent link">&para;</a></h2>
-<p>In broad terms the <code>config.yaml</code>, <code>.env</code> files, participant files, and day segment files are the only ones that you will have to modify. All data is stored in <code>data/</code> and all scripts are stored in <code>src/</code>. For more information see RAPIDS&rsquo; <a href="file-structure/">File Structure</a>.</p>
+<p>In broad terms the <code>config.yaml</code>, <a href="../setup/configuration/#database-credentials"><code>.env</code> file</a>, <a href="../setup/configuration/#participant-files">participants files</a>, <a href="../setup/configuration/#day-segments">day segment files</a> are the only ones that you will have to modify. All data is stored in <code>data/</code> and all scripts are stored in <code>src/</code>. For more information see RAPIDS&rsquo; <a href="file-structure/">File Structure</a>.</p>