Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add draft design vignette #5

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion epiparameterDashboard.Rproj
Original file line number Diff line number Diff line change
Expand Up @@ -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
8 changes: 6 additions & 2 deletions inst/WORDLIST
Original file line number Diff line number Diff line change
@@ -1,5 +1,8 @@
CFR
CMD
Codecov
DT
Epireview
Epiverse
Lifecycle
ORCID
Expand All @@ -8,12 +11,13 @@ codecov
com
epiparameter
epireview
etc
flexdashboard
gh
github
io
lifecycle
packagename
packagetemplate
plotly
svg
tidyverse
yaml
41 changes: 28 additions & 13 deletions vignettes/design-principles.Rmd
Original file line number Diff line number Diff line change
@@ -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}
---
Expand All @@ -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.

Expand All @@ -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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

crosstalk could also be a good solution for a static (i.e., non-reactive) dashboard with some interactivity: https://rstudio.github.io/crosstalk/

- Shiny (for dashboard)
- flexdashboard (for dashboard)
- epiparameter (for data and functions)
- epireview (for data and functions)
- DT (for tables)
Copy link
Member Author

@jamesmbaazam jamesmbaazam Jul 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noting down here that {constructive} may be useful for printing the code that was used to produce output.