Based on JOSS guidelines https://joss.readthedocs.io/en/latest/review_criteria.html#documentation

• it is not clear where to find documentation
  • as an R user I can find the help(package = 'FielDHub') and I see this is great!
  • for the community the README can be substantially improved
    • a lot of the content can come directly from the JOSS paper - including the figures and some additional examples ... or have a section on getting help and running examples using help() and example() functions
    • link to the pkgdown site
• use return only once per function
• flesh out run_app documentation. This is the key user facing function! What are some options that can be passed as ...?
• in both the paper and the docs, it could be more clear that there are a large number of useful standalone functions

Hi, I just tried to run the following code and received this error:

r <- 2
k <- 2
trt <- 1:8

length(trt) / k # = s
#> [1] 4

FielDHub::alpha_lattice(t = trt,
                        k = k,
                        r = r)
#> Error in if (numbers::isPrime(t)) shiny::validate("Combinations for this amount of treatments do not exist."): Bedingung hat Länge > 1

^{Created on 2023-01-31 with reprex v2.0.2}

Maybe I am missing something, but is r = 2 and k = 2 not a valid option here?
Note that agricolae::design.alpha() also throws an error - see myaseen208/agricolae#5

Dear authors,

I realized you have several wide tables as output in your shiny app. When a table is too wide, you can fix certain columns using the FixedColumns extension to be visible when you scroll the table horizontally. Thus, I suggest you fix the first column related to row labels (see image) and also include a scroll on the x-axis to facilitate end-user interaction with the output. You can include a scrolling row by adding in the datatable options scrollX = TRUE.

Ex.:

datatable(
  your_data, 
  extensions = 'FixedColumns',
  options = list(
    dom = 't',
    scrollX = TRUE,
    fixedColumns = TRUE
  )
)

Does this suggestion make sense to you?
Best regards,

Good Day All,
Please I will like to know if there are any plan to add function to analyze P-Rep Design on this package ?

Hi,

I noticed that there are no print and summary functions for each function proposed in the package. I have felt the need for print and summary functions because when, for example, we increase the number of treatments, locations and so on, and print the object, a list of two objects is automatically printed, which sometimes ends up polluting the R output, mainly, due to the "fieldBook" object in that list.

In this sense, I have worked on the following possible suggestions for you:

##' @rdname print.CRD
##' @method print CRD
##' @title Print an \code{CRD} object
##' @usage \method{print}{CRD}(x, ...)
##' @aliases print.CRD
##' @description Prints information about randomization of Completely
##'   Randomized Design (CDR)
##' @return an object inheriting from class \code{CRD}
##' @param x an object inheriting from class
##'   \code{\link[FielDHub]{CRD}}
##'
##' @param ... not used

print.CRD <- function(x, ...){
  cat("Completely Randomized Design (CRD)", "\n\n")
  cat("  Information on the design parameters:", "\n")
  str(x$infoDesign)

  cat("\n", " Head of the data frame with the CRD field book:","\n")
  head(x$fieldBook)
}


##' @rdname summary.CRD
##' @method summary CRD
##' @title Summary an \code{CRD} object
##' @usage \method{summary}{CRD}(object, ...)
##' @aliases summary.CRD
##' @description Summarise information on the design parameters and data frame structure
##' @return an object inheriting from class \code{summary.CRD}
##' @param object an object inheriting from class
##'   \code{\link[FielDHub]{CRD}}
##'
##' @param ... not used

summary.CRD <- function(object, ...) {
  structure(object, oClass=class(object),
            class = "summary.CRD")
}

##' @rdname print.summary.CRD
##' @method summary CRD
##' @title Print the summary of an \code{CRD} object
##' @usage \method{print}{summary.CRD}(object, ...)
##' @aliases print summary.CRD
##' @description Print summary information on the design parameters and data frame structure
##' @return an object inheriting from class \code{CRD}
##' @param object an object inheriting from class
##'   \code{\link[FielDHub]{CRD}}
##'
##' @param ... not used

print.summary.CRD <- function(x, ...){
  cat("Information on the design parameters:", "\n")
  str(x$infoDesign)  
  cat("\n", "Data frame structure with the CRD field book:","\n")
  str(x$fieldBook)
}

See the new output example below:

crd1 <- CRD(t = 3, 
            reps = 5, 
            plotNumber = 101, 
            seed = 1987, 
            locationName = "Fargo")

• Print output:

print(crd1)

Completely Randomized Design (CRD) 

  Information on the design parameters: 
List of 5
 $ numberofTreatments: num 3
 $ treatments        : chr [1:3] "T1" "T2" "T3"
 $ Reps              : num 5
 $ locationName      : chr "Fargo"
 $ seed              : num 1987

Data frame head with the CRD field book: 
  ID LOCATION PLOT REP TREATMENT
1  1    Fargo  101   3        T2
2  2    Fargo  102   1        T1
3  3    Fargo  103   1        T2
4  4    Fargo  104   3        T3
5  5    Fargo  105   2        T3
6  6    Fargo  106   3        T1

• Summary output

s1 <- summary.CRD(object)
s1

Information on the design parameters: 
List of 5
 $ numberofTreatments: num 3
 $ treatments        : chr [1:3] "T1" "T2" "T3"
 $ Reps              : num 5
 $ locationName      : chr "Fargo"
 $ seed              : num 1987

 Data frame structure with the CRD field book: 
'data.frame':	15 obs. of  5 variables:
 $ ID       : int  1 2 3 4 5 6 7 8 9 10 ...
 $ LOCATION : Factor w/ 1 level "Fargo": 1 1 1 1 1 1 1 1 1 1 ...
 $ PLOT     : int  101 102 103 104 105 106 107 108 109 110 ...
 $ REP      : int  3 4 1 3 4 1 1 4 5 2 ...
 $ TREATMENT: Factor w/ 3 levels "T1","T2","T3": 2 2 2 1 1 1 3 3 1 3 ...

I would suggest the authors consider both print and summary functions for each function related to experimental design. Clearly, feel free to modify my first suggestion, you also can add some more parameters in each function, e.g.:

print.CRD <- function(x, n=10,...){
  cat("Completely Randomized Design (CRD)", "\n\n")
  cat("  Information on the design parameters:", "\n")
  str(x$infoDesign)
  
  cat("\n", "Data frame head with the CRD field book:","\n")
  head(x$fieldBook, n=(min(n, nrow(x$fieldBook))))
}

Another alternative could be to include only a print function with the output of the summary function. Just think about it. The optimal idea is to have both functions with non overlapped outputs.

I've noticed a consistent issue regarding the generation of full factorial designs in the Shiny application. When entries in the 'FACTOR' column contain spaces (e.g., 'No nitrogen'), the app fails to create the factorial design. Currently, the workaround involves removing or replacing spaces in these entries, such as changing 'No nitrogen' to 'No-nitrogen'. The app should work seamlessly regardless of whether the 'FACTOR' column entries contain spaces or not.

Per requirements, need to add link to repository in the references section, or add a section such as

## Availability and Community Guidelines

The software is available at the Comprehensive R Archive Network CRAN and also at the
GitHub repository https://github.com/DidierMurilloF/FielDHub/. The GitHub repository also contains the source code for this paper.

Users and contributors are welcome to contribute, request features, and report bugs in this GitHub repository.

It would also be helpful to have a CONTRIBUTING.md or similar that could be referenced here, and would meet the JOSS requirements https://joss.readthedocs.io/en/latest/review_criteria.html#community-guidelines. Mozilla provides some ideas https://mozillascience.github.io/working-open-workshop/contributing/

Per JOSS criteria:

Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

see also: https://mozillascience.github.io/working-open-workshop/contributing/

Hi there. I've been running FielDHub locally on my laptop for a while and now started looking into running a Docker image using your Dockerfile on a server.

I can make the application start up fine, but I run into issues with it running on a sub-path on my domain, so something like

https://test.domain.com/fieldhub

When I access the application on this path (using a reverse proxy), the app tries to load resources like JS and CSS files as well as images from https://test.domain.com/<filename> instead of https://test.domain.com/fieldhub/<filename>.

I currently cannot see a way to tell FielDHub to adjust those paths based on the folder it lives in. Is this something that is currently possible and if not, do you think you'll be able to add this in the future?

Updated R to v 4.3.1 and the crossprod() function has been discontinued, so the package and shiny app don't work and produce the following error:

Error in crossprod(cbind(TM, BM)) : "crossprod" is not a BUILTIN function

When producing a randomization for a resolvable row-column design with 36 entries, 6 reps, 2 rows, and a random seed of 20243, each entry does not appear in every replicate.

In the summary of your manuscript, you describe: "One of the problems that life scientists often face is the lack of freely available and user-friendly interactive tools to create designs that fit their needs". I absolutely agree with the author's phrase. Thus, I proposed here a discussion about this topic.

By user-friendly definition, I understand that common attributes of it should be

1. Interface should be simple/straightforward. It should provide quick access to common features or commands.
2. Clean. A good user interface is well-organized (users cannot feel confounded among inputs)
3. Intuitive. The interface must make sense to the average user and require a minimal explanation for using it.
4. Reliable. It is something that doesn't cause undue frustration for the user.

Let us discuss each of these items now.

1. The shiny interface that the authors provided looks nice, and the inclusion of a box with all inputs is well defined. It is quite easy for the end-user to interact with the dashboard, and it puts the app as a simple/straightforward tool to create designs.
2. Although the authors proposed some complex experimental designs, their app seems very clean and with an organized interface.
3. Unfortunately, some inputs of experimental designs proposed in the app are not intuitive and require some improvement to the end-user to understand the whole idea. I can use myself as an example here. I have never worked with the unreplicated design before be presented to this manuscript/package. In this way, I can tell the authors that a student or people with no background won't use this interface because it is too hard to set up each input means. This is due to the app didn't provide any description of each input. Consequently, the user needs to kind of guess the meaning of each one. To turn the app intuitive, I suggest that the authors work a little more in the description step and perhaps include a concise introduction to each design (say one paragraph).
4. As the app is sometimes not intuitive, it also causes frustration for the user. However, it is reliable because it does not malfunction or crash.

With these improvements, the application will greatly impact universities and be something easy to use.

Dear authors,

Could you provide authorship for each function in the package rather than just in the description file? This is an important step to see how authors/contributors have contributed to this package's development. Please, remember that each contributor should appear in the description file. Sorry to be a little bit pedantic about it, but you will see this step is important over the next releases (years). When you describe contributors and authors only on the description file, I assumed they have contributed to all functions, which, probably, is not true.

Please, check the box when you have attributed authorship for the following functions:

• get_golem_config()
• app_server()
• app_ui()
• alpha_lattice()
• CDR()
• diagonal_arrangement()
• full_factorial()
• incomplete_blocks()
• latin_square()
• optimized_arrangement()
• partially_replicated()
• RCBD()
• RCBD_augmented()
• rectangular_lattice()
• row_column()
• split_families()
• split_plot()
• split_split_plot()
• square_lattice()
• strip_plot()

Thanks.

Dear Didier,

I am still experimenting with FielDHub, this time with the app. Is it possible to allow more flexibility in the field layout, for example for 1 36 entries experiment, I would like to plan 3 by 12 (in reality almost rectangular), but the app does not suggest that.

Best Gregor

Dear authors,

I have been testing all examples provided in the package. However, this particular example using the function diagonal_arrangement() has reported an issue due to the getData() function. The issue starts in line 169 of function diagonal_arrangement() regarding getData() function output, which returns that it produces NAs by coercion. However, when I checked the dataset generated by getData(), no NA was introduced by coercion. Perhaps, some minor changes in the getData() function will correct this issue.

Please test the example below:

R> spatDB <- diagonal_arrangement(nrows = 30, ncols = 26,
+                                 checks = 5, 
+                                 plotNumber = 1, 
+                                 kindExpt = "DBUDC", 
+                                 planter = "serpentine", 
+                                 splitBy = "row", 
+                                 data = treatment_list)
> [1] 725
> [1] 725
> [1] 725
> [1] 725
> [1] 725
> [1] 725
> [1] 725
> [1] 725
> Error in (1 + s):cuts_max[i] : NA/NaN argument
   In addition: Warning messages:
   1: In getData() : NAs introduced by coercion
   2: In getData() : NAs introduced by coercion
   3: In getData() : NAs introduced by coercion
   4: In getData() : NAs introduced by coercion
   5: In getData() : NAs introduced by coercion
   6: In getData() : NAs introduced by coercion
   7: In getData() : NAs introduced by coercion
   8: In getData() : NAs introduced by coercion

Dear authors,

I know we can use checks/tester to determine the effectiveness of manipulation in an experimental design related to social/medial science. Furthermore, checks can also be used in agriculture (mainly in genetics) and generally are commercial varieties because you know their characteristics and associated parameters.

You defined checks as an integer number of genotypes checks or a numeric vector. This argument definition is a bit confusing to me. Firstly, what do you mean by a numeric vector? What happens when end-users include a numeric vector there? I suggest you re-write this argument explaining to the end-user all the details, not just part of them.

Another point is in the Shiny App. Why did you decide to work with percentage for checks? Why you restricted this percentage to vary from 6.67 to 10%? It is not clear what is the difference between %Checks and Input # of checks. Alternatively, could you describe each shiny input in the dashboard?

Hi,

I am really enjoying the package, and I would like to congratulate all authors on their work. This package has many ideas I had a few years ago; however, with several improvements and covering several experimental designs.

My suggestion here is minimal but can contribute to the output of some functions you have there. I think you should be more explicitly when reporting replication in your output, e.g., function latin_square() has the following output:

R> latin_data <- data.frame(list(ROW = paste("Period", 1:5, sep = ""),
+                                                COLUMN = paste("Cow", 1:5, sep = ""),
+                                                TREATMENT = paste("Diet", 1:5, sep = "")))
R> latinSq2 <- latin_square(t = NULL, 
+                                          reps = 2, 
+                                          plotNumber = 101, 
+                                          planter = "cartesian",
+                                          seed = 1981, 
+                                          data = latin_data)
R> print(latinSq2)

$squares
$squares[[1]]
        Cow1    Cow2    Cow3    Cow4    Cow5   
Period1 "Diet4" "Diet3" "Diet2" "Diet1" "Diet5"
Period2 "Diet1" "Diet2" "Diet4" "Diet5" "Diet3"
Period3 "Diet3" "Diet5" "Diet1" "Diet2" "Diet4"
Period4 "Diet2" "Diet4" "Diet5" "Diet3" "Diet1"
Period5 "Diet5" "Diet1" "Diet3" "Diet4" "Diet2"

$squares[[2]]
        Cow1    Cow2    Cow3    Cow4    Cow5   
Period1 "Diet2" "Diet4" "Diet5" "Diet3" "Diet1"
Period2 "Diet1" "Diet2" "Diet3" "Diet4" "Diet5"
Period3 "Diet3" "Diet5" "Diet1" "Diet2" "Diet4"
Period4 "Diet4" "Diet1" "Diet2" "Diet5" "Diet3"
Period5 "Diet5" "Diet3" "Diet4" "Diet1" "Diet2"


$plotSquares
$plotSquares[[1]]
     [,1] [,2] [,3] [,4] [,5]
[1,]  101  102  103  104  105
[2,]  106  107  108  109  110
[3,]  111  112  113  114  115
[4,]  116  117  118  119  120
[5,]  121  122  123  124  125

$plotSquares[[2]]
     [,1] [,2] [,3] [,4] [,5]
[1,]  201  202  203  204  205
[2,]  206  207  208  209  210
[3,]  211  212  213  214  215
[4,]  216  217  218  219  220
[5,]  221  222  223  224  225

...

In this case, replication output has been reported as list numbers. I think should be useful for end-users to see these numbers actually representing replication numbers. Thus, I did a modification in your function latin_square() including this information in the output, where the results now is reported as:

$squares$rep1
        Cow1    Cow2    Cow3    Cow4    Cow5   
Period1 "Diet4" "Diet3" "Diet2" "Diet1" "Diet5"
Period2 "Diet1" "Diet2" "Diet4" "Diet5" "Diet3"
Period3 "Diet3" "Diet5" "Diet1" "Diet2" "Diet4"
Period4 "Diet2" "Diet4" "Diet5" "Diet3" "Diet1"
Period5 "Diet5" "Diet1" "Diet3" "Diet4" "Diet2"

$squares$rep2
        Cow1    Cow2    Cow3    Cow4    Cow5   
Period1 "Diet2" "Diet4" "Diet5" "Diet3" "Diet1"
Period2 "Diet1" "Diet2" "Diet3" "Diet4" "Diet5"
Period3 "Diet3" "Diet5" "Diet1" "Diet2" "Diet4"
Period4 "Diet4" "Diet1" "Diet2" "Diet5" "Diet3"
Period5 "Diet5" "Diet3" "Diet4" "Diet1" "Diet2"


$plotSquares
$plotSquares$rep1
     [,1] [,2] [,3] [,4] [,5]
[1,]  101  102  103  104  105
[2,]  106  107  108  109  110
[3,]  111  112  113  114  115
[4,]  116  117  118  119  120
[5,]  121  122  123  124  125

$plotSquares$rep2
     [,1] [,2] [,3] [,4] [,5]
[1,]  201  202  203  204  205
[2,]  206  207  208  209  210
[3,]  211  212  213  214  215
[4,]  216  217  218  219  220
[5,]  221  222  223  224  225

...

What do you think about including this modification in other functions you have?

Here is the raw code I've included:

latin_square <- function(t = NULL, reps = 1, plotNumber = 101,  planter = "serpentine",
                         seed = NULL, locationNames = NULL, data = NULL) {
 ...
  # line 106----------------------------------------------------------
  plotSquares <- setNames(vector(mode = "list", length = reps),
                          paste0("rep", seq(1:reps))) # set names
  #line 152-----------------------------------------------------------
  ...
  #---------------------------------------------------------------------
  lsd.reps <- setNames(lsd.reps, paste0("rep", seq(1:reps))) # set names
  #---------------------------------------------------------------------
  ...
  return(list(squares = lsd.reps, plotSquares = plotSquares,
              fieldBook = latin_design))
}

Sometimes in a p-rep design, the number of field plots is prime. In this case, it is impossible to factorize this number to offer users a set of field dimensions (Rows, Columns). One option to overcome this issue is allowing a few Filler plots that enable the user to make the randomization.
The tricky part of implementing this is the optimization process behind the p-rep design.

Is it possible in future updates to fully optimize the row column design option (not just rows)? Cheers if you get around to it!

Dear Didier,

I am trying to generate a number of designs using FielDHub::partially_replicated. I would like to specify where in the list of the genotypes a particular replication appears i.e. have the replicated entries at the end or in the middle of the genotype list, but it seems the function orders the genotype IDs by replications and puts the higher replications first. Do you see a possiblity to circumvent this?

Best Gregor

replicated entries first

mydes1 <- partially_replicated(nrows = 6, ncols = 6,
repGens = c(6,24),
repUnits = c(2,1))
mydes1$dataEntry

replicated entries last

mydes2 <- partially_replicated(nrows = 6, ncols = 6,
repGens = c(24,6),
repUnits = c(1,2))
mydes2$dataEntry

Hey, I want to make use of your plot() function (instead of manually creating my own desplots) for teaching purposes (see here) , but I would like to use other colors/layout. I thought I could simply create the resulting plot into an object and alter it afterwards, but the function isnt acutally returning the plot, right? It's just showing it:

library(FielDHub)

x <- CRD(
  t = letters[1:3],
  reps = 3,
  seed = 42
)

y <- plot(x)

str(y)
#> List of 1
#>  $ field_book:'data.frame':  9 obs. of  7 variables:
#>   ..$ ID       : int [1:9] 1 2 3 4 5 6 7 8 9
#>   ..$ LOCATION : num [1:9] 1 1 1 1 1 1 1 1 1
#>   ..$ PLOT     : int [1:9] 101 102 103 104 105 106 107 108 109
#>   ..$ ROW      : int [1:9] 1 1 1 2 2 2 3 3 3
#>   ..$ COLUMN   : int [1:9] 1 2 3 3 2 1 1 2 3
#>   ..$ REP      : Factor w/ 3 levels "1","2","3": 1 2 2 3 2 3 1 1 3
#>   ..$ TREATMENT: chr [1:9] "a" "b" "b" "c" ...

I guess I would only want something like this instead. And as you may know, updating such a plot would be quite simple:

z <- desplot::desplot(
  data = y$field_book,
  form = TREATMENT ~ ROW + COLUMN,
  text = TREATMENT,
  col.regions = c("#00923f", "#bce2cc", "#e9ecef"),
  cex = 1,
  show.key = FALSE,
  main = NULL
)

z

update(z, col.regions = c("red", "blue", "green"))

^{Created on 2023-11-09 with reprex v2.0.2}

Dear authors,

Please, include a new argument like the factorLabels I have suggested here (DidierMurilloF/FielDHub#7). This argument can help end-users to understand the treatment output better.

A suggestion of alternative expected output:

• Function full_factorial() - Done!

     ID LOCATION PLOT REP FACTOR_A FACTOR_B FACTOR_C   TRT_COMB
1     1   Loc1    101   1       a0       b0       c1   a0*b0*c1
2     2   Loc1    102   1       a1       b0       c1   a1*b0*c1
3     3   Loc1    103   1       a1       b1       c0   a1*b1*c0

• Function split_plot():

     ID LOCATION    PLOT    REP   WHOLE-PLOT    SUB-PLOT     TRT_COMB
1     1    A        101      1       Fung4       Beans5     Fung4|Beans5
2     2    A        101      1       Fung4       Beans1     Fung4|Beans1
3     3    A        101      1       Fung4       Beans2     Fung4|Beans2

• Function split_split_plot():

   ID LOCATION PLOT REP WHOLE-PLOT SUB-PLOT SUB-SUB-PLOT TRT_COMB
1   1        A  101   1     IRR_NO    Fung3       Beans3    IRR_NO|Fung3|Beans3
2   2        A  101   1     IRR_NO    Fung3       Beans9    IRR_NO|Fung3|Beans9
3   3        A  101   1     IRR_NO    Fung3      Beans10    IRR_NO|Fung3|Beans10

• Function strip_plot () - Done!