Add draft design vignette

epiparameterDashboard.Rproj

@@ -6,12 +6,15 @@ AlwaysSaveHistory: Default
 
 EnableCodeIndexing: Yes
 UseSpacesForTab: Yes
-NumSpacesForTab: 2
+NumSpacesForTab: 4
 Encoding: UTF-8
 
 RnwWeave: Sweave
 LaTeX: pdfLaTeX
 
+AutoAppendNewline: Yes
+StripTrailingWhitespace: Yes
+
 BuildType: Package
 PackageUseDevtools: Yes
 PackageInstallArgs: --no-multiarch --with-keep.source

inst/WORDLIST

@@ -1,5 +1,8 @@
+CFR
 CMD
 Codecov
+DT
+Epireview
 Epiverse
 Lifecycle
 ORCID
@@ -8,12 +11,13 @@ codecov
 com
 epiparameter
 epireview
+etc
+flexdashboard
 gh
 github
 io
 lifecycle
 packagename
-packagetemplate
+plotly
 svg
-tidyverse
 yaml

vignettes/design-principles.Rmd

@@ -1,8 +1,8 @@
 ---
-title: "Design Principles for {packagetemplate}"
+title: "Design Principles for {epiparameterDashboard}"
 output: rmarkdown::html_vignette
 vignette: >
-  %\VignetteIndexEntry{Design Principles for {packagetemplate}}
+  %\VignetteIndexEntry{Design Principles for {epiparameterDashboard}}
   %\VignetteEngine{knitr::rmarkdown}
   %\VignetteEncoding{UTF-8}
 ---
@@ -14,7 +14,7 @@ knitr::opts_chunk$set(
 )
 ```
 
-This vignette outlines the design decisions that have been taken during the development of the `{packagetemplate}` R package, and provides some of the reasoning, and possible pros and cons of each decision.
+This vignette outlines the design decisions that have been taken during the development of `{epiparameterDashboard}`, and provides some of the reasoning, and possible pros and cons of each decision.
 
 This document is primarily intended to be read by those interested in understanding the code within the package and for potential package contributors.
 
@@ -24,25 +24,40 @@ None of the sections are required, feel free to remove any sections not relevant
 
 ## Scope
 
-< Outline the aims of the package, potentially mention some of the key exported functions, and maybe how it links with other R packages. It is also possible to mention certain aspects that fall outside of the package's scope. >
+`{epiparameterDashboard}` aims to provide a user-friendly interface for exploring the parameters provided by the `{epiparameter}` and `{epireview}` packages.
 
-## Naming conventions
+## Use cases
 
-< Description of the scheme and/or conventions used for naming functions and arguments. This can be the use of a prefix on all exported functions, a name mould ("all function are named verb_object"), or any other naming convention that is used throughout the package. >
+- Modellers who would like to compare existing parameters in the database to choose the most appropriate for their model.
+- Researchers who would like to compare new estimates to existing parameters.
+- Individuals who would like to generate a report of the parameters in the database, including key summary statistics and plots for a report.
+
+## Minimal interface
 
-## Input/Output/Interoperability
+- Sufficient summary statistics: show multiple studies at the same time. 
+- A comparison of available distributions for the same disease, allowing user interactivity by selecting citations to visualise.
+- Ability to highlight/select individual lines on the plot and see its associated information.
+- Context from which parameters were obtained (available in `{epireview}`): community-based, health care workers, etc.
+- An option to download a report containing the code used to generate the dashboard visuals, and information on the disease, delay distribution, and other associated information (citation, etc).
+- Provide an easy way to copy parameter estimates and citation.
 
-< Describe the data structures (i.e. vectors, `<data.frames>` or classes) that are given as input to the key functions and what data structures the functions return. The design decisions around these I/O choices could also mention how it enhances interoperability with other R packages or pipelines (e.g. with `%>%`). >
+### Out of scope
 
+- Impact of different parameters on downstream estimates of $Rt$, $CFR$, etc.
 
 ## Design decisions
 
-< A list of bullet points each explaining a design decision and its reasoning. >
+## Input/Output/Interoperability
+
+- `{epiparameterDashboard}` will read in the data provided by `{epiparameter}` and `{epireview}` as `<data.frame>` and output the dashboard that provides options to visualise parameters from the two packages separately and compare values across the two packages.
 
 ## Dependencies
 
-< A list of dependencies used by the package with some explanation as to why they are required. Not all dependencies need to be explained and it is best to explain the key dependencies. It can be used to give context to why certain dependencies are used (e.g. "This package is expected to be used in tidyverse pipelines and as such, we consider these tidyverse packages good dependencies that will already be installed on a user's computer."). This section can also mention dependencies that are planned to be removed or added in future development. Suggested dependencies do not need to be explained unless they are unusual and may surprise developers with their inclusion. >
-
-## Development journey
+- The ability to download static output, for example, a report, will determine whether to use `{flexdashboard}` vs `shiny`.
 
-<  If the package has undergone any large refactoring this section can be used to explain the changes. >
+- plotly (for interactivity with plots)
+- Shiny (for dashboard)
+- flexdashboard (for dashboard)
+- epiparameter (for data and functions)
+- epireview (for data and functions)
+- DT (for tables)