search

greenelab / meta-review

Manuscript describing open collaborative writing with Manubot
https://greenelab.github.io/meta-review
Other
48 stars 21 forks source link

Reviewer 2 comment 3 #132

Closed agitter closed 5 years ago

agitter commented 5 years ago

For now, the primary Manubot output is HTML intended to be viewed in a web browser. → I would insist a bit more on this part because it is a real strength if you consider a future integration with interactive figures (e.g. bokeh) and/or Jupyter notebooks. Being able to produce both a nice PDF and a HTML dynamic version would be a nice feature.

vincerubinetti commented 5 years ago

I'm not originally from the academic world, and I'm not familiar with Bokeh or Jupyter. Would this relate to the html front-end I'm designing? If so, any references or insight regarding these tools would be useful @agitter @dhimmel

agitter commented 5 years ago

@vincerubinetti Bokeh is one interactive visualization library. There are others as well. Jupyter notebooks combine documentation, code, and visualization, like this example from our analysis in this particular manuscript.

I interpret this comment more generally as asking how we could support interactive manuscripts (graphics and/or code) in the HTML version of Manubot manuscripts. We touch on related work in the Concepts for the future... paragraph but don't say much. Distill, Idyll, and Stencila remain good references as we consider our response.

agitter commented 5 years ago

Some related previous discussion https://github.com/greenelab/manubot-rootstock/issues/116

slochower commented 5 years ago

Plotly is also something to consider.

agitter commented 5 years ago

Aside from the technical feasibility, do we have a strong vision of the desired behavior for a Manubot manuscript with interactive graphics? Specifically, would the PDF version have a static snapshot in some default initial setting in the place of the interactive graphics?

slochower commented 5 years ago

I don't have a strong vision, no. I think it would be something like what you say: maybe a snapshot of the first frame or some key frame. That looks like the approach taken by the remote_refocus manuscript mentioned in https://github.com/manubot/rootstock/issues/116.

dhimmel commented 5 years ago

would the PDF version have a static snapshot in some default initial setting in the place of the interactive graphics?

Currently, we create the PDF by rendering the HTML. Essentially, it's like we're printing the webpage to PDF. While we are likely going to switch the engine that goes from HTML to PDF as per https://github.com/manubot/rootstock/issues/170, this will almost certainly remain our strategy.

Therefore, ideally interactive HTML element would convert properly to PDF. Furthermore, their default state should be the desired static view. I believe most interactive visualizations fulfill these properties.

Specifically, would the PDF version have a static snapshot in some default initial setting in the place of the interactive graphics?

Yes, exactly. Another option could be polymorphic elements where they would get replaced by a user specified static version for PDF export. For example, how the CSS @page element only affects printing. However, not sure whether this is possible? CC @vincerubinetti. And even if it is, it's probably not desirable. I don't think we really want PDF and HTML outputs diverging too much.

agitter commented 5 years ago

Our Binder additions can be discussed in response to this.