Comments on the main branch code and files

[facuxpalacio]

The code as you will see is pretty rough. My main idea was to set a draft as follows:

• Use different tabs for each step (8 tabs)
• The first tab is just the description of the protocol and link to the (future) paper
• Each tab has checkboxes for the user to check what has done or not (along headings briefly explaining what the step refers to).
• I thought to develop steps 5 and 6 a bit more to include data summaries, plots, FD metrics, etc. I'm not sure if the remaining steps are worth to include anything useful, but ideas are welcome.
• The text throughout the app is intended to be just a draft, we can refine it when the app comes to an end.

I've also uploaded two datasets, one is the classical "Iris" data and the other belongs to one of my publications. I included Iris because it has several measurements per species, so it can be thought as a trait dataset accounting for intraspecific variation.

Awaiting for your comments!

[emmajhudgins]

Hi Facundo,

This is a great start! I think making use of Iris data is a great idea. I only made a few small grammatical changes to the code in a branch. For me, the check boxes disappear when I click them, but I assume this is a work in progress.

I'd suggest we make this repo consistent with the reproducible code+data box I started drafting for part 8 (but you can edit this box to conform to whatever you think the minimum requirements are). https://docs.google.com/document/d/1tq-VYz9vNxLWMBkaoWyX8xfO9yqo1cK8IARNZnq_GRI/edit

If you agree, you could set up the file structure to include an 'data', 'output', and 'R' subfolder, and we can detail the steps required to use all of the files in the readme. I can do a first pass at this if you'd like.

@graco-roza might know whether keeping the shiny app in one script vs. separating ui and server components is best (I've seen arguments for the latter but the app is fairly simple so it might be ok).

I think it could be nice to convert parts of this checklist to a fillable form that people can download from the shiny app, and then upload to their own repos as proof they followed the steps. I am not skilled enough in shiny at this point to immediately know how to do this yet, but I can try to learn! This looks like a good starting point https://deanattali.com/2015/06/14/mimicking-google-form-shiny/

We could add examples to the fillable form for steps 1-2 based on the iris or bird data. The answers could be shown in the form before it gets filled as default answers.

step 1:

• The current MS draft actually makes having a specific research question optional, so it could be good to have an initial decision tree where people decide if they're going exploratory or question-driven. I think it could be cool to show examples of each type of question with iris and bird data.

step2:

• people could fill in their preregistration doi/other identifier if they check yes and provide the location of the power analysis (maybe in the focal repo).

step 3-4

• Could we have people upload their files at these stages rather than step 5?
• Could we make some dummy community data here? And then we could show the output of 'head' on the resulting data frames n both steps.
• The fillable form could include file paths to these data sources

step 4

• should we ask about accounting for phylogenetic structure here too?
• I think brief definitions of things like soft/hard traits could mean that people don't have to keep referring to the MS.

step5

• This one is super impressive!!!
• maybe we can reorder the left panel so that the things that happen before plotting are listed first (e.g. accounting for missingness/bias).
• The need to deal with multicollinearity and the need for transformation requirements could be shown visually - maybe we can have a tab for transformations that replot the histograms after some standard transformations. Maybe we can also discuss outliers here? e.g. having another tab for outlier detection?
• It also seems like the collinearity box is being printed far down the page
• people could fill in any transformations/outliers/multicollinearity fixes they had to do in the fillable form

step6

• again, here I think we can have some example answers from the example dataset in a fillable form
• i'm not sure what the subetting is in "Did you subset your trait data?" - maybe give a few examples

step 7

• could we provide examples of some validation types in tabs using the iris or bird data? e.g. jackknifing and permutation tests? I can help with this

step 8

• maybe we can integrate the reproducible code box into this step more fully

Let me know if you want me to expand on anything!

Emma

[facuxpalacio]

Hi Emma, thank you so much for your nice feedback, you've made me think about manys stuffs!

I'll do my best to follow your box on reproducible code+data, but feel free to indicate if I'm getting this wrong or missing something.

It is weird that check boxes disappear when you click them, it shouldn't happen, or at least, this never has happened to me. We should check this out.

As the app is pretty simple right now, I don't think we need to separate the ui and the server.

Step 1:

• Sounds good. Do you have an idea of what kind of input should we use? You can take a look at the available inputs in the shiny cheatsheet https://shiny.rstudio.com/images/shiny-cheatsheet.pdf

Step 2:

• Mmmh, I should figure out how to do this! Could we simulate this with fake data or something similar?

Step 3:

• I try to imagine how I'd use the app for my own analyses. Steps 3 and 4 are intended to check whether you collected, and how you collected the data. Some information could be directly retrieved when uploading a file (e.g. number of traits, types of traits), but this may become tricky as people upload their data in multiple forms with columns that may have nothing to do with the analysis. Besides, I think it would be best for the user to upload their files and see the dataset in the same output, rather than switching between files and output tabs.
• Thinking in your comment on a final report (which is a very cool idea), then we should move to textInput so that people can fill entries that will appear in the report. Or should se keep both, so people can check the boxes and add their own info?
• I agree to include a community matrix to the "data" subfolder ( I was going to include the corresponding bird community dataset). Indeed, I 've included a new file browser in Step 5, as well as a heading output.

Step 4

• If we include an entry for phylogenetic information, we should add it to the manuscript.

Step 5

• OK, I'll add your changes. This step and Step 6 are maybe the harder ones (but also the funniest)t o code, as they have many reactive programming.

Step 6

• Good. Subsetting means to group set of traits based on their ecological meaning (e.g., you have 10 traits but you compute FD using 3 only traits accounting for pollen dispersal).

Step 7

• Sure! It would be great if you can take on this.

Step 8

• I agree to include the reproducible code box here.

To summarize, Emma it would be great if you could take on:

1. Creating a fillable form.
2. Validation tools in Step 7.
3. Integrating the reproducible code into Step 8.

I'm handling the rest of steps meanwhile.

Facu

[facuxpalacio]

@emmajhudgins I've created a data folder. Before going on, I've got a few questions:

• Should I upload the app.R file in the R folder? If so, does the main branch remain unaltered?
• What should I put in the the output folder? If I understand correctly, I cannot create an empty folder.

Thanks in advance

Facu

[facuxpalacio]

@emmajhudgins maybe you're right to upload the community and trait datasets in Steps 3 and 4, respectively. I've put two file browsers in the "Dataset tab" in Step 5, and it looks a bit overloaded once both datasets appear.

[emmajhudgins]

Hi @facuxpalacio,

Sorry for the delay in replying - I need to figure out how to turn on email updates!

re: R folder, yes, but your main branch should be altered if you change the location of files (it'll look like a deletion and addition of a file).

re: empty folder
If you're using github desktop, you should be able to upload an empty folder (I've never had any issues). If you're imagining that people won't fork this repository, maybe an output folder isn't necessary. But, if you just wanted to show the file structure, a sample of the exportable report could go here based on the sample data. If you're having issues setting up the folders I can take this on.

I think a combo of either checkboxes/radiobuttons/selectinput and fillable text input would be ok! I would hesitate to switch to all text input in case the form became too overwhelming for people using it for the first time. Some of the steps don't need a lot of detail (e.g. step 1 part 1 for if you have a hypothesis can be a checkbox)

re: your earier comments:

step1: maybe selectInput?

step2:
Do you mean a fake example of a preregistration DOI? I would maybe just give an example URL of an existing preregistration, e.g. http://corinalogan.com/Preregistrations/g_flexforaging.html as the default in a textInput field

As for the location of the power analysis, I was thinking of a URL or filepath (either a github URL pointing to their own repository or a file path on their local machine/cloud storage). Maybe we can find an existing power analysis on github to point to to save time?

I'll try my best to work through those 3 items in the next few days!

Emma

[emmajhudgins]

Hi Facundo!

The shiny learning curve is steeper than I anticipated :P As an update, I've updated my versions of R and RStudio and the checkboxes no longer disappear!

I am partway through converting the checklist to a fillable form - currently if you hit submit it outputs a file in the output folder (not sure if this is the best solution if the app is web hosted).

See also the change I made to the format of the step 1 question - had to do some conditional statements on the reactive output which took some time to learn!

Emma

[facuxpalacio]

Hi Emma!

Thanks for the feedback. I agree with you, it's pretty hard at the beginning, but then you get used to it once you learn the logic behind. It's great that you could fix the issue with the checkboxes and learned how to include the fillable form😃

What I find cumbersome is the need of doing great changes in the code and then modifying this in the repo. I understand this is because gitHub is not intended for doing this (particularly when there are several people working on the same script), but mainly for storage.

I've made several other changes, but I will first merge what you did.

Facu

[facuxpalacio]

I've merged your changes with mine, it's looking pretty nice! (check the new plots I've included in the community data section). I'm just wondering if one "Submit" button at the end of the protocol wouldn't be better than one button per page.

Facu

[emmajhudgins]

Hi Facundo,

GitHub is actually built largely for version control, not storage, so while it is tricky with merge conflicts and stff, that is actually the main point of it.

I'm still unclear on whether you're working on the code using command line git/github desktop or if you're actually uploading new versions of files to the github website? It's much more streamlined if you use a desktop software.

I'll add a final tab with the submit button!

Emma

[facuxpalacio]

Got it Emma. I've been commiting changes to the website so far, mainly to understand how it works. From now on, I will commit changes from the desktop version.

Facu

[facuxpalacio]

Emma, the desktop version is like being in heaven! My only concern is what would happen if one of us commit changes while the other is working at the same time on the previous version. Should we fetch origin regularly (let's say every 30 min) while changing the code so the other is aware of this? Thanks!

Facu

[emmajhudgins]

Hi Facundo,

Glad you got the desktop version working! I think fetching the origin often is a good idea, but this is partly why I've been working in my own branch. You can work in the main branch while I work in EJH_edits to hopefully limit conflicts (different timezones help too :P).

If I make changes you don't fully agree with/that would overwrite yours, you can see what I did by looking at the history of my branch, or compare via a 'diff' with your copy (https://coderefinery.github.io/git-intro/08-conflicts/), and only incorporate the ones you like in your branch

If there still end up being two conflicting versions of the same file, it's a bit annoying to resolve but not terrible. See here: https://docs.github.com/en/github/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github

Emma

[facuxpalacio]

Emma, you're the best!! Little by little I'm understanding how all this stuff works, neato!

I've just realized Caio wasn't assigned to this issue, I'm not sure whether he's been receiving our discussions.

Facu

[graco-roza]

Hi all, I have been following the whole discussion from scratch. One of the main reasons I haven’t answered is that, in my experience, code gets too messy if 2, 3 people are editing at the same time. If you would like I can take a look at the app at some point to see if code is consistent and functional, but it seems to me that you are building it in a good pace, and a third person would only make it slower. Let me know if you want me to look at it at this stage and I can give my inputs. Otherwise I can wait and give the final improvements (if any) :).

…

On 17. Jun 2021, at 2.13, facuxpalacio ***@***.***> wrote:  Emma, you're the best!! Little by little I'm understanding how all this stuff works, neato! I've just realized Caio wasn't assigned to this issue, I'm not sure whether he's been receiving our discussions. Facu — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.

[facuxpalacio]

Great Caio!

I absolutely agree with you, it sounds pretty wise indeed.

You can give it a crack when we're ending with a first complete prototype then,

Facu