Removed top level docs folder

Avoids the need for `docs` in URL on published site, and needed prior to launch.

content/en/docs/_index.md → content/en/_index.md

@@ -34,15 +34,15 @@ Have questions? Want to learn alongside a community of users? Join our [communit
 
 ## Reference App for Antenatal Care
 
-While our ANC Reference App can be used as is, most organizations and projects will want to configure and customize the app's tasks, care cuides, reports and even branding. These changes are not made at the Core Framework code level, but often still require technical skills and experience. To explore how we use forms to build the Tasks, Care Guides, and Reports that take health workers through care protocols and provide decision support for interactions with patients, read our [Configuration Best Practices Guide]({{< ref "docs/design/apps" >}}).
+While our ANC Reference App can be used as is, most organizations and projects will want to configure and customize the app's tasks, care cuides, reports and even branding. These changes are not made at the Core Framework code level, but often still require technical skills and experience. To explore how we use forms to build the Tasks, Care Guides, and Reports that take health workers through care protocols and provide decision support for interactions with patients, read our [Configuration Best Practices Guide]({{< ref "design/apps" >}}).
 
-[![ANC Confuguration](preview-configuration-best-practices-overview.png)]({{< ref "docs/design/apps" >}})
+[![ANC Confuguration](preview-configuration-best-practices-overview.png)]({{< ref "design/apps" >}})
 
 To learn how to add your own logo, project name, and more to our Reference App, read our [App Branding Guide](resources/app-branding-overview.pdf).
 
 [![App Branding Overview](preview-app-branding-overview.png)](resources/app-branding-overview.pdf)
 
-We are in the process of writing additional guides and clearer API documentation. Check out the [tutorials]({{< ref "docs/apps/tutorials" >}}) for more info.
+We are in the process of writing additional guides and clearer API documentation. Check out the [tutorials]({{< ref "apps/tutorials" >}}) for more info.
 
 ## Contributing to the Core Framework
 

content/en/docs/apps/concepts/hierarchy.md → content/en/apps/concepts/hierarchy.md

@@ -15,7 +15,7 @@ A user logging into their app will see a custom set of people, tasks, reports, a
 
 The information hierarchy is configured in the administration console. The hierarchy levels can be given different titles depending on a particular health system’s program or reporting structures. 
 
-{{% see-also page="docs/apps/reference/hierarchy" title="Defining Hierarchy" %}}
+{{% see-also page="apps/reference/hierarchy" title="Defining Hierarchy" %}}
 
 
 ### Places

content/en/docs/apps/concepts/interoperability.md → content/en/apps/concepts/interoperability.md

@@ -13,7 +13,7 @@ keywords: interoperability dhis2 dhis openmrs
 
 [OpenHIE](https://ohie.org/), [HL7 FHIR](https://www.hl7.org/fhir/index.html), [ICD-10](https://www.who.int/classifications/icd/factsheet/en/), [LOINC](https://loinc.org/), etc... are examples of healthcare related protocols and standards used to achieve interoperability. CHT Core can be configured to support many of these standards and also exchange data with other systems through *integrations*.
 
-{{% see-also page="docs/apps/features/integrations" title="Integrations" %}}
+{{% see-also page="apps/features/integrations" title="Integrations" %}}
 
 
 

content/en/docs/apps/concepts/users.md → content/en/apps/concepts/users.md

@@ -19,7 +19,7 @@ Differing levels of access and permissions are assigned to each persona. A user
 | CHWs            | Logs in at CHW Area level                      | Phone     | Users at this level have online and offline access to view households and family members, submit reports about them, and view tasks and targets about them.                                                                                                         |
 | Family members  | Registered at Household level, does not log in | Messaging | Family members might include fathers, mothers, children, and other adults. The program model determines which family members should be registered in the app. However, they are not users of the app, and do not log in themselves.                      |
 
-{{% see-also page="docs/apps/reference/user-roles" anchor="" title="Defining User Roles" %}}
+{{% see-also page="apps/reference/user-roles" anchor="" title="Defining User Roles" %}}
 
 ### Online Users
 
@@ -33,6 +33,6 @@ Offline roles are for users who need to be able to access data on the go in the
 
 User Permissions are settings that can be individually toggled on or off to allow users with a particular Role to do a certain action or see a certain thing. CHT app developers and administrators can add as many User Roles as needed to grant permissions to different groups of users.
 
-{{% see-also page="docs/apps/reference/user-permissions" title="Defining User Permissions" %}}
+{{% see-also page="apps/reference/user-permissions" title="Defining User Permissions" %}}
 
 Viewing permissions determine which page tabs a user sees in the app and which types of data they do and don’t have access to. User action permissions include who can create (e.g., create new users), who can delete (e.g., delete reports), who can edit (e.g., edit profiles), and who can export (e.g., export server logs).

content/en/docs/apps/concepts/workflows.md → content/en/apps/concepts/workflows.md

@@ -17,16 +17,16 @@ Tasks can be triggered by a set of conditions, such as contact details or submit
 
 Data submitted in one form can generate several tasks at once, e.g., multiple ANC visits following one pregnancy registration. Some workflows involve a series of sequential forms and tasks, e.g., a child health assessment form, a follow up task scheduled 48 hours later, a referral form (only if the child’s condition hasn’t improved), and then a referral follow up task. Tasks are accessible on the Tasks tab, as well as the Tasks section of profiles. 
 
-{{% see-also page="docs/apps/reference/tasks" title="Defining Tasks" %}}
+{{% see-also page="apps/reference/tasks" title="Defining Tasks" %}}
 
 ## SMS Messaging
 
 Workflows can include notifications and interactions with CHWs, nurses, supervisors, and patients via SMS. A report can trigger SMS messages to be sent immediately or upon a set schedule. Responses via SMS or the app can update the workflows.
 
-{{% see-also page="docs/apps/reference/workflows-sms" title="Defining SMS Workflows" %}}
+{{% see-also page="apps/reference/workflows-sms" title="Defining SMS Workflows" %}}
 
 ## Interoperability 
 
 Workflows can incorporate other digital tools, such as a facility-based electronic medical record system for referral workflows. New contacts or reports can trigger an interoperabilty workflow using the [outbound push]() feature. Data can be received as reports using the [CHT API](https://github.com/medic/cht-core/tree/master/api)
 
-{{% see-also page="docs/apps/reference/outbound" title="Outbound Push" %}}
+{{% see-also page="apps/reference/outbound" title="Outbound Push" %}}

content/en/docs/apps/examples/anc.md → content/en/apps/examples/anc.md

@@ -13,4 +13,4 @@ To install the ANC Reference Application, follow the [easy installation instruct
 
 [![ANC Overview](preview-anc-ref-app-overview.png)](anc-reference-app-overview.pdf)
 
-If you want to modify our ANC Reference Application for your project or context, read our [configuration best practices]({{< ref "docs/design/apps" >}}) or learn how to [develop your own community health apps]({{< ref "docs/apps" >}}).
+If you want to modify our ANC Reference Application for your project or context, read our [configuration best practices]({{< ref "design/apps" >}}) or learn how to [develop your own community health apps]({{< ref "apps" >}}).

content/en/docs/apps/features/integrations/dhis2.md → content/en/apps/features/integrations/dhis2.md

@@ -54,7 +54,7 @@ There are a few very important considerations related to how you design workflow
 
 The CHT relies on your Place hierarchy to determine how data should be aggregated for DHIS2. As such, it’s important that you consider how Organization Units are configured in the DHIS2 instance that you need to integrate data into. If your CHT Place hierarchy does not align with the DHIS2 Organisation Unit structure, the CHT will not be able to aggregate data in the way DHIS2 needs it.
 
-See also: [Hierarchies]({{< ref "docs/apps/concepts/hierarchy" >}})
+See also: [Hierarchies]({{< ref "apps/concepts/hierarchy" >}})
 
 ##### Data and Indicators
 

content/en/docs/apps/reference/app-forms.md → content/en/apps/reference/app-forms.md

@@ -23,13 +23,13 @@ A CHT-enhanced version of the ODK XForm standard is supported.
 
 Data needed during the completion of the form (eg patient's name, prior information) is passed into the `inputs` group. Reports that have at least one of `place_id`, `patient_id`, and `patient_uuid` at the top level will be associated with that contact. 
 
-{{% see-also page="docs/apps/reference/contact-forms" anchor="care-guides" title="Passing contact data to care guides" %}}
+{{% see-also page="apps/reference/contact-forms" anchor="care-guides" title="Passing contact data to care guides" %}}
 
 A typical form ends with a summary group (eg `group_summary`, or `group_review`) where important information is shown to the user before they submit the form.
 
 In between the `inputs` and the closing group is the form flow - a collection of questions that can be grouped into pages. All data fields submitted with a form are stored, but often important information that will need to be accessed from the form is brought to the top level. To make sure forms are properly associated to a contact, make sure at least one of `place_id`, `patient_id`, and `patient_uuid` is stored at the top level of the form.
 
-{{% see-also page="docs/design/apps" anchor="content-and-layout" title="Content and Layout" %}}
+{{% see-also page="design/apps" anchor="content-and-layout" title="Content and Layout" %}}
 
 ## XLSForm
 

content/en/docs/apps/reference/tasks.md → content/en/apps/reference/tasks.md

@@ -15,7 +15,7 @@ keywords: tasks workflows
 
 Tasks are configured in the `tasks.js` file. This file is a JavaScript module which defines an array of objects conforming to the Task schema detailed below. When defining tasks, all the data about contacts on the device (both people and places) along with all their reports are available. Tasks are available only for users of type "restricted to their place". Tasks can pull in fields from reports and pass data as inputs to the form that opens when the task is selected, enabling richer user experiences.
 
-{{% see-also page="docs/apps/features/tasks" title="Tasks Overview" %}}
+{{% see-also page="apps/features/tasks" title="Tasks Overview" %}}
 
 ## `tasks.js`
 

content/en/docs/core/_index.md → content/en/core/_index.md

@@ -10,7 +10,7 @@ This section provides an overview and reference for development of the Core Fram
 
 App developers are able to define health system roles, permissions and reporting hierarchies, and make use of five highly configurable areas of functionality: messaging, task and schedule management, decision support workflows, longitudinal person profiles, and analytics.
 
-{{% see-also page="docs/apps" %}}
+{{% see-also page="apps" %}}
 
 The Core Framework can be used to support the unique needs of a given health system and the work of community health workers, frontline supervisors, facility-based nurses, health system managers, and even patients and caregivers. Visit the Commuity Health Toolkit website to request a [self-guided demo](https://communityhealthtoolkit.org/contact) of an app built with the Core Framework. You can also explore an [overview of the Core Framework]({{< ref "features" >}}) and its key features.