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

Define scope and use case of each report more clearly #41

Open
Bisaloo opened this issue Nov 8, 2022 · 2 comments
Open

Define scope and use case of each report more clearly #41

Bisaloo opened this issue Nov 8, 2022 · 2 comments

Comments

@Bisaloo
Copy link
Member

Bisaloo commented Nov 8, 2022

As suggested by Sam Abbott.

@avallecam, do you know if some people have already used some kind of equivalent of user persona to define in which situation a given tool should be used? In other words, not defining the target user but the target situation. Can you recommend resources for this?

@Bisaloo Bisaloo changed the title Define scope and use case of each repo more clearly Define scope and use case of each report more clearly Nov 8, 2022
@avallecam
Copy link
Member

Interesting and critical topic!

I think target situations can be much more diverse than user profiles.

  • We can be very specific; for example, make a model report for each of the most common disease outbreaks (r4epis https://r4epis.netlify.app/outbreaks/), highlighting the most relevant thematic-specific questions to solve. Very useful to standardize critical questions to solve, like in a gastroenteritis case study and find the source of contamination (reconlean https://www.reconlearn.org/categories/case-studies.html). * An important point here is that "the most common diseases" should be stratified by regions because not all countries have the same disease burden.

  • Or, be less specific, focusing on the type of disease (communicable, non-communicable), similar to how departments within MoH/CDCs are organized. Each has different needs, although they may use similar chunks of code or modules. (following their organigrams: USA https://www.cdc.gov/about/organization/cio.htm, Peru https://www.dge.gob.pe/portalnuevo/institucional/organigrama/ MSF https://www.msf.org/focus). Although this could face the situation that most institutions already have their typical communication formats, providing an alternative reproducible way is not always their first need.

  • Also, we can classify situations by how fast the response needs to be (outbreaks, disasters, massive events, or long-term surveillance). Here the scenario could be raw and unexpected. But having a prepared toolbox or emergency kit for them could be highly relevant and positively impact the faster creation of sitreps and decision-making in the field.

Given this diversity, I just got the idea of also providing "modules" (inspired by a systems biology concept). I mean, a modularized way to produce reports according to expected or unexpected needs. From my user's POV, it could be incredible that instead of looking at one page of packages (like recon https://www.repidemicsconsortium.org/projects/), I could also look at a page of reprex'es easy to implement in an external workflow (or join them in a shiny (?) maybe not code but connected task as a first stage).

In a visualization parallel, moving from this https://exts.ggplot2.tidyverse.org/gallery/ to these data-to-viz https://www.data-to-viz.com/ or r-graph-gallery https://r-graph-gallery.com/ but logically in a pipeline, if needed. With space to talk about the limitations and needs to make rigorous conclusions, if possible.

@Bisaloo
Copy link
Member Author

Bisaloo commented Nov 8, 2022

Thanks for your answer!

You are anticipating on the 2nd phase of this project, which will allow users to create their own reports by joining modules 😄. But this is a longer-term project.

In the meantime, it would still be good to try and guide users through the premade templates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants