iheatmapr

[AliciaSchep]

Summary

• What does this package do? (explain in 50 words or less):

Makes complex, interactive heatmaps. The package includes a modular system for iteratively building up complex heatmaps, as well as the iheatmap function for making relatively standard heatmaps.

• Paste the full DESCRIPTION file inside a code block below:

Package: iheatmapr
Type: Package
Title: Interactive Complex Heatmaps
Version: 0.2.4
Authors@R: c(person("Alicia", "Schep", email = "aschep@gmail.com",
                  role = c("aut", "cre")),
              person("Sarah","Kummerfeld", email = "kummerfeld.sarah@gene.com",
                  role = c("aut")),
              person("Genentech", role = "cph"))
Description: iheatmapr is a package for making complex, interactive heatmaps.
    The package includes a modular system for iteratively building up complex
    heatmaps, as well as the iheatmap function for making relatively standard
    heatmaps.
License: MIT + file LICENSE
Depends:
    plotly (>= 4.1.1),
    R (>= 2.10)
Imports:
    methods,
    plyr,
    utils,
    magrittr,
    S4Vectors,
    stats,
    ggdendro,
    fastcluster,
    RColorBrewer,
    htmlwidgets,
    jsonlite,
    scales,
    knitr
Suggests:
    htmltools,
    datasets,
    shiny,
    testthat,
    rmarkdown,
    reshape2,
    roxygen2,
    covr
biocViews: Visualization
RoxygenNote: 6.0.1
VignetteBuilder: knitr
URL: https://github.com/AliciaSchep/iheatmapr
BugReports: https://github.com/AliciaSchep/iheatmapr/issues
Collate:
    'AllClasses.R'
    'AllGenerics.R'
    'annotations.R'
    'as_plotly.R'
    'axes.R'
    'axis_labels.R'
    'axis_titles.R'
    'barplot.R'
    'clustering.R'
    'clusters.R'
    'colorbars.R'
    'colors.R'
    'components.R'
    'dendogram.R'
    'generic_subplots.R'
    'groups.R'
    'main_heatmap.R'
    'iheatmap.R'
    'iheatmapr.R'
    'layout.R'
    'shiny_click_test.R'
    'signal.R'
    'subplot.R'
    'summary.R'
    'utils.R'

• URL for the package (the development repository, not a stylized html page):

https://github.com/AliciaSchep/iheatmapr

• Who is the target audience?

Anyone who wants to visualize data using heatmaps. Package is not intended to be domain specific, although some fields tend to use heatmaps more than others.

• Are there other R packages that accomplish the same thing? If so, what is different about yours?

There are great tools in R for creating relatively simple interactive heatmaps (plotly, d3heatmap, heatmaply) or creating static complex heatmaps (ComplexHeatmap). However, there are no tools (that I am aware of) facilitating easy creation of complex, interactive heatmaps.

Requirements

Confirm each of the following by checking the box. This package:

• does not violate the Terms of Service of any service it interacts with.
• has a CRAN and OSI accepted license.
• contains a README with instructions for installing the development version.
• includes documentation with examples for all functions.
• contains a vignette with examples of its essential functions and uses.
• has a test suite.
• has continuous integration with Travis CI and/or another service.

Publication options

• Do you intend for this package to go on CRAN?
• Do you wish to automatically submit to the Journal of Open Source Software? If so:
  • The package contains a paper.md with a high-level description in the package root or in inst/.
  • The package is deposited in a long-term repository with the DOI:
  • (Do not submit your package separately to JOSS)

Detail

• Does R CMD check (or devtools::check()) succeed? Paste and describe any errors or warnings:

• Does the package conform to rOpenSci packaging guidelines? Please describe any exceptions:

• If this is a resubmission following rejection, please explain the change in circumstances:

• If possible, please provide recommendations of reviewers - those with experience with similar packages and/or likely users of your package - and their GitHub user names:

[maelle]

Editor checks:

• Fit: The package meets criteria for fit and overlap
• Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
• License: The package has a CRAN or OSI accepted license
• Repository: The repository link resolves correctly
• Archive (JOSS only, may be post-review): The repository DOI resolves correctly
• Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

---

Editor comments

Thanks for your submission @AliciaSchep! 😀 Currently looking for reviewers.

A few comments:

• The repository doesn't have a DOI yet but I guess you'd archive it after the review?

• Here is the output from goodpractice::gp() that can help you and the reviewers

It is good practice to

  ✖ write unit tests for all functions, and all package code in
    general. 78% of code lines are covered by test cases.

    R/AllGenerics.R:93:NA
    R/AllGenerics.R:96:NA
    R/AllGenerics.R:141:NA
    R/AllGenerics.R:144:NA
    R/AllGenerics.R:201:NA
    ... and 587 more lines

  ✖ not use "Depends" in DESCRIPTION, as it can cause name clashes,
    and poor interaction with other packages. Use "Imports" instead.
  ✖ avoid long code lines, it is bad for readability. Also, many
    people prefer editor windows that are about 80 characters wide.
    Try make your lines shorter than 80 characters

    R\AllGenerics.R:34:1
    R\axes.R:389:1
    R\axes.R:390:1
    R\axes.R:510:1
    R\axes.R:630:1
    ... and 37 more lines

  ✖ not import packages as a whole, as this can cause name clashes
    between the imported packages. Instead, import only the specific
    functions you need.
  ✖ fix this R CMD check NOTE: Namespace in Imports field not
    imported from: 'fastcluster' All declared Imports should be
    used.
  ✖ fix this R CMD check NOTE: add_col_clustering,Iheatmap: no
    visible global function definition for 'hclust'
    add_row_clustering,Iheatmap: no visible global function
    definition for 'hclust' Undefined global functions or variables:
    hclust Consider adding importFrom("stats", "hclust") to your
    NAMESPACE file.

• Using devtools::spell_check() I found the following typos
  • pallette add_main_heatmap.Rd:37
  • heirarchical add_col_clustering.Rd:17, add_row_clustering.Rd:17
  • annotion add_col_annotation.Rd:26, add_row_annotation.Rd:26

---

Reviewers: @andeek @carlganz
Due date: 2017-04-23

[AliciaSchep]

Thanks @maelle!

I have updated the typos, long lines, and some of the NAMESPACE issues.

For the use of DEPENDS, I think it is appropriate in this case to force user import of plotly. For importing the packages as whole, I am only importing S4Vectors and methods -- as I am using a lot of functions & classes from these packages I thought that might be appropriate, but am of course open to more guidance on this question.

I will work on adding more tests to get closer to 100% test coverage.

[maelle]

Great but note that 100% coverage isn't compulsory 😉

[maelle]

@AliciaSchep the reviewers are now assigned! 😀

Thanks for agreeing to review this package @andeek @carlganz! 😃

As a reminder here are links to the recently updated reviewing and packaging guides and to the review template.

[carlganz]

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

Documentation

The package includes all the following forms of documentation:

• A statement of need clearly stating problems the software is designed to solve and its target audience in README

  Consider adding a more concrete statement of need in the readme. The paper.md and the vignette both provide good statements of need.

• Installation instructions: for the development version of package and any non-standard dependencies in README

  Consider mentioning the dependency on BiocInstaller since there may be users who are not familiar with how to install packages from BioConductor.

• Vignette(s) demonstrating major functionality that runs successfully locally

  Excellent vignette

• Function Documentation: for all exported functions in R help

• Examples for all exported functions in R Help that run successfully locally

  setup_colorbar_grid and save_iheatmap do not include examples.

• Community guidelines including contribution guidelines in the README or CONTRIBUTING, and URL, Maintainer and BugReports fields in DESCRIPTION

Paper (for packages co-submitting to JOSS)

The package contains a paper.md with:

• A short summary describing the high-level functionality of the software
• Authors: A list of authors with their affiliations
• A statement of need clearly stating problems the software is designed to solve and its target audience.
• References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

• Installation: Installation succeeds as documented.
• Functionality: Any functional claims of the software been confirmed.
• Performance: Any performance claims of the software been confirmed.
• Automated tests: Unit tests cover essential functions of the package
  and a reasonable range of inputs and conditions. All tests pass on the local machine.
• Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

• The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 3

---

Review Comments

This package provides R users with a collection of easy-to-use functions for iteratively building complex interactive heatmaps. The iheatmap function initiates a heatmap, and a variety of function of the form add_* allow thee user to include annotations, barplots, clustering, grouping, dendrograms, labels, plots, titles, and summaries to both the rows, and columns as well as additional heatmaps. The package makes nice use of magrittr pipes, and plotly graphics, which gives it a nice modern feel.

The package is extremely well documented with an extensive vignette, and examples for almost every function. The package is also well tested with 79% code coverage. It contains a library of graphs, which are recreated, and then compared to in the tests.

Overall the package is very well done, and meets all the rOpenSci packaging guidelines. Functions have proper names, and documentation. Use of plotly in depends makes sense.

A few suggestions:

• Add clearer statement of need in readme. The first paragraph nicely explains what iheatmapr does, but I don't think it is a clear statement of need. The JOSS paper, and the vignette both make clearer statements of need.

• Consider mentioning how to install BiocInstaller in the installation instructions. I'll confess, I had to google how to install BioConductor packages because I hadn't done it before.

• Add examples for setup_colorbar_grid and save_iheatmap (you already fixed Small typo in documentation iheatmapr#1)

• Add DOIs for references in paper.md if they exist

• Consider adding Travis tests for Mac, and App-Veyor tests for Windows.

• Consider adding a badge in readme for minimum R version (i.e. badgecreatr::minimal_r_version_badge("2.10"))

• The vignette is very well done. Only suggestion is to maybe explain the differences between clustering vs clusters vs groups since they all seem like similar concepts to me.

Hope that helps.

Kind Regards,
Carl

[maelle]

Thanks a lot for your review @carlganz !

[AliciaSchep]

@carlganz thank you for the review and helpful suggestions! I will follow up on all the suggestions and post an update to this thread when that is complete.

[andeek]

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

Documentation

The package includes all the following forms of documentation:

• A statement of need clearly stating problems the software is designed to solve and its target audience in README
• Installation instructions: for the development version of package and any non-standard dependencies in README
• Vignette(s) demonstrating major functionality that runs successfully locally
• Function Documentation: for all exported functions in R help
• Examples for all exported functions in R Help that run successfully locally
• Community guidelines including contribution guidelines in the README or CONTRIBUTING, and URL, Maintainer and BugReports fields in DESCRIPTION

Paper (for packages co-submitting to JOSS)

The package contains a paper.md with:

• A short summary describing the high-level functionality of the software
• Authors: A list of authors with their affiliations
• A statement of need clearly staing problems the software is designed to solve and its target audience.
• References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

• Installation: Installation succeeds as documented.
• Functionality: Any functional claims of the software been confirmed.
• Performance: Any performance claims of the software been confirmed.
• Automated tests: Unit tests cover essential functions of the package
  and a reasonable range of inputs and conditions. All tests pass on the local machine.
• Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Estimated hours spent reviewing: 3

---

Review Comments

Overall, this package is really great. I had a really fun time playing with and and definitely see the importance of the work. I think the modular structure fits really nicely with how R is trending lately (in terms of piping) and I appreciate that that must not have been super straightforward to create. Overall, I think is a wonderful contribution and is very fun as well!

In addition, the vignette was extremely well put together and I appreciate the thorough documentation.

I have a few suggestions and explanations for any tasks above that did not receive an "X".

Explanations for no "X"s above and suggestions for improvement

Perhaps you could explain the difference between add_col_clustering() and add_col_dendrogram(), it looks like they are very similar in the result.

Documentation

• Examples: Here is are the functions that I found without examples: save_iheatmap, setup_colorbar_grid
• Community guidelines: There is a CONDUCT file, but not a CONTRIBUTING file. I'm not sure if you need both.

Paper (for packages co-submitting to JOSS)

• References: You are missing some DOI's.

Functionality

• Performance: I didn't see any "performance claims", but the package seemed to work well for me.

• Automated tests: I received the following warnings using the test_that script:

  Warning messages:
  1: In .removePreviousCoerce(class1, class2, where, prevIs) :
    methods currently exist for coercing from "IheatmapMainX" to "IheatmapAxis"; they will be replaced.
  2: In .removePreviousCoerce(class1, class2, where, prevIs) :
    methods currently exist for coercing from "IheatmapMainY" to "IheatmapAxis"; they will be replaced.
  

• Packaging guidelines: Avoid starting the description with the package name.

[AliciaSchep]

Thanks @andeek for the review! I hope to have time soon to address all issues in both reviews.

[maelle]

Thanks a lot @andeek ! 😸

@AliciaSchep now the two reviews are in, let us know if you have any question!

[maelle]

@AliciaSchep I see you've done some work on the package, do you think you'll soon be able to answer to the reviews? 😉

[AliciaSchep]

Sorry, I'm behind on everything! I have made most of the changes suggested, although I still need to figure out why the tests on Appveyor are failing...

[maelle]

No problem! I work on Windows, so if you need me to test anything, just ask 😉

[AliciaSchep]

Thanks @maelle, I may finally have figured it out -- I think it is a question of precision as the tests seem to pass with 64 bit architecture but not 32 bit (updating appveyor to use 64 bit led to tests passing)... I'll need to change the tests a bit to not be so sensitive to precision (no good reason for the test data to have so many significant digits anyways)

[maelle]

Oh cool, nice catch! 🎣

[AliciaSchep]

I have now addressed almost all of the reviewer concerns, thanks again to @andeek and @carlganz for taking the time to review the package.

• DOIs for references

Most of the references are other packages, and I couldn't find DOI, but I have added the DOI for the reference that is a paper.

• Examples

I added examples for save_iheatmap and setup_colorbar_grid

• Statement of need in README

I added statement of need into README, similar to what was in vignette and paper.

• Add travis mac testing

• Add appveyor testing for windows [now passes!]

• Add BiocInstaller instructions

Added to README

• Add badge for minimal R

• Clarify clusters vs clustering vs groups functions [Reviewer 1] and clustering vs dendrogram [Reviewer 2]

Edited vignette to make more clear [basic idea is that add_*_clustering functions do the work of clustering for you, but if you want to do clustering yourself there are are lower level functions for adding dendrogram or cluster annotation]

• Add contributing guidelines

• Avoid starting description with package name

Have changed description field to avoid this

The main comments I haven't resolved:

• warning with tests

I haven't been able to reproduce these warnings, so not sure how best to go about addressing them!

• Any performance claims of the software been confirmed.

README & vignette don't make performance claims, the goal is not better performance than other similar packages, but more features & flexibility. Should I add performance tests?

[maelle]

Thanks @AliciaSchep! Nice Work!

Regarding what you say about performance do you cite these other packages in a Vignette? That'd be enough. 😊

@andeek and @carlganz are you happy with the changes? Please tell me if you don't have time to have a look, in which case I'll do that.

[AliciaSchep]

Thanks @maelle. With regards to other related packages, I cite them in README and paper.md, but not currently in vignette -- I can add that there as well.

[maelle]

Many thanks @andeek! 👌

@AliciaSchep I'll do some last checks next week 😺

[maelle]

@AliciaSchep reg your questions I don't know, we can ask in the slack/on the forum 😉

But as a quick answer now here you can see an example of an author list where they acknowledge the authors of code that was adapted from elsewhere.

[maelle]

@AliciaSchep Looking at the package right now, looks great. Could you add the rOpenSci footer to the bottom of the README? This is the code [![ropensci_footer](http://ropensci.org/public_images/github_footer.png)](http://ropensci.org) .

Reg. your question about the new JS code, was it settled or should we try finding an answer via the Slack or forum? I think that's the last thing before accepting your package.

After acceptance I'll ask you to transfer the repo to rOpenSci, and you'll need to:

• Update the URLs.
• Do a new release with a new DOI for then proceeding with the JOSS submission.

But first let's solve this JS code issue. 😉

[AliciaSchep]

Thanks @maelle. I have not yet figured out the JS code, been meaning to post a question, but haven't gotten around to it yet. Any suggestion of best place to post question? Not very familiar with the Slack, so don't know what 'channel' is appropriate

[maelle]

general is fine!

[maelle]

@AliciaSchep did the answer you got on slack help you?

[AliciaSchep]

@maelle yes it did, sorry i haven't made the change yet, will try to do so this weekend

[AliciaSchep]

@maelle, I finally updated the DESCRIPTION to add the plotly.js authors, using comment to indicate that they are authors of the js package, as suggested by Jim on ropensci slack and similar to what was done in package you suggested. I also added an acknowledgment section, in which I included a thanks to plotly r package for code that was adapted for this package. Let me know if you have additional suggestions for making sure appropriate credit is being given! I also added the ropensci footer

[maelle]

Great, now all problems have been solved as far as I can tell, good work! Approved!

To-dos:

• Transfer the repo to the rOpenSci organization under "Settings" in your repo. I have invited you to a team that should allow you to do so.

• OPTIONAL You can add the reviewers in DESCRIPTION as "rev" if you want to (and if they agree). See e.g. this example. It might raise a NOTE but you can then explain it in CRAN comments and it'll be accepted.

• Add the (brand new!) "Peer-reviewed" badge to your README (in the future people will add this on submittal; it updates through the stages of review):

[![](https://ropensci.org/badges/107_status.svg)](https://github.com/ropensci/onboarding/issues/107)

• Fix any links in badges for CI and coverage to point to the ropensci URL. (we'll turn on the services on our end.)
• Activate Zenodo watching the repo
• Tag and create a release so as to create a Zenodo version and DOI
• Submit to JOSS using the Zenodo DOI. We will tag it for expedited review.

Welcome aboard! We'd also love a blog post about your package, either a short-form intro to it (https://ropensci.org/tech-notes/) or long-form post with more narrative about its development. ((https://ropensci.org/blog/). Let me know if you are interested.

[AliciaSchep]

woohoo! I transferred the repo to ropensci and added the peer review badge. @maelle For CI, what are the new links? Anything else I need to do setup the CI? I noticed that OpenCPU CI sent me an email saying build had failed, due to BiocInstaller not being installed (package has one BioC dependency, S4Vectors).

[AliciaSchep]

@carlganz and @andeek may I add you as "rev" to the package description? thanks again for reviewing the package! (feel free to let me know either here or ropensci slack or email-- aschep is my gmail address)

[maelle]

@AliciaSchep awesome, thanks for transferring it!

• For OpenCPU let me pink @jeroen

• For Appveyor here is the new badge [![Build status](https://ci.appveyor.com/api/projects/status/ds0vrh047h196vqj?svg=true)](https://ci.appveyor.com/project/ropensci/iheatmapr)

• For Travis you just need to replace your username by "ropensci" in the old badge.

[jeroen]

Don't worry about OpenCPU, it doesn't really support BioConductor yet :)

[maelle]

Thanks @jeroen

@AliciaSchep I forgot to mention to update the links in DESCRIPTION

[AliciaSchep]

I updated the links in Description & README. I tried doing the zenodo thing, but the repository doesn't show up in the list of repos to be able to archive? Is there some kind of access that has to be set @maelle?

[maelle]

@AliciaSchep I’ve just made you admin of the repo so now it should work, sorry about that!

[AliciaSchep]

Thanks @maelle, it shows up now! Question about timing of things -- I want to now submit package to CRAN, should I do that before doing the DOI & JOSS submission? Does it matter?

[maelle]

Hi @AliciaSchep, as far as I know it doesn't matter but if you wait before the CRAN submission then you can have the JOSS paper in citation so that users of the CRAN version know how to cite your package. 😊

[maelle]

@AliciaSchep Are you going to submit the package to JOSS soon?

For info yesterday I submitted a package to CRAN after JOSS acceptance, this is how CITATION looks like. https://github.com/ropensci/rtimicropem/blob/master/inst/CITATION

If you do the optional item of asking reviewers whether they'd like to be included in DESCRIPTION as "rev", when submitting the package to CRAN you'll have to build it on R-devel (or wait until R3.5 :-)) because otherwise this non-standard role isn't translated well from Authors@R to Authors.

[maelle]

@AliciaSchep any plan to submit the package to JOSS soon?

[AliciaSchep]

I have added the reviewers to the DESCRIPTION and made a release. For JOSS submission, there is a dropdown of suggested editors -- any recommendation there?

[maelle]

I actually don't think it makes a difference but when I submitted a paper to JOSS I chose Karthik because he's an rOpenSci editor as well 😉

[maelle]

Did you ask/inform the reviewers that they were added to DESCRIPTION? I've never seen anyone say no but better to ask. :-)

[AliciaSchep]

Yes I asked the reviewers, both were fine with it!

[AliciaSchep]

And now have also submitted to JOSS! Thanks @maelle

[maelle]

Awesome, closing this issue!