Workflow reporting - support for IFrames, Fancy Tables.

[hexylena]

There are a couple of features from iReport that are important to @shiltemann and myself, and we'd like to know if they're in scope for workflow reports at some point in the future, @jmchilton? (Or anyone else interested in workflow reporting.)

• Embedded html/iframe type datasets?
  • Use case: krona plots
  • Use case: a JBrowse instance that's live/browseable
  • Would need dataset + query string.
• Fancier tables (datatables style) that are browseable/filterable/sortable.
  • Especially for large tables like blast outputs.
• Tabs or multiple pages with an index or something where content can be on multiple pages and doesn't have to be scrolled entirely through to get to next region.

All of the features are very interactive, and I know the PDF generation is considered important. And in some cases a PDF with a link to the item works, or just e.g. the top 10 results in a table is fine, but for some of our reports for clinical use they need to be a bit more interactive.

[nsoranzo]

I haven't touched much of the workflow reports code, but it looks to me that the first 2 could be implemented on the web version of the report without affecting the PDF generation. Tabs/multiple pages look a bit trickier though.

[dannon]

@hexylena I've definitely been interested in this lately. Do you have any specific ideas for wide table support? I have one report I was working on that had ~15 column wide data that was just abysmal to get formatted right in a usable pdf. I ended up doing a landscape pdf and a terribly small font for the tables, which was okay, but I'm wondering if you have put more thought into better ideas for static content display.

[hexylena]

Super cool @dannon! My thoughts are "reports should not be converted directly to PDFs" more or less because it loses so much from our iReports. For producing PDFs sometimes I feel like authors should be forced to reduce the amount of data they want to display to just the important things, and attach the rest as "supplementary tables 1..9", like we do for publications.

[dannon]

@hexylena Yeah, there's a lot of room for adding dynamic content in the web version of an invocation report like @nsoranzo mentions, I think that's a pretty natural fit -- I was just wondering if you had an idea to solve my "bench scientist who wants to print out hard copies but still wants the data included" problem :)

[hexylena]

Yeah, no, it's a problem for us too, we have collaborators that do ask for the same thing. landscape is pretty natural, but just zipping up the "report + suppl files", and telling them to print out the spreadsheet in whatever way makes sense for them is probably an acceptable compromise?

[hexylena]

Or, "if this won't fit in the PDF, then it's in the supp." and for small tables try and include them under a certain content width.

[jmchilton]

For tabs, I was originally imagining some markdown rendering option (there is metadata next to the report in the database or it could be embedded in the markdown in some way) that makes H2 titles automatically turn into tabs in the web browser but just keeps the content as sections for the PDF.

Probably easier to implement would be a new macro block like the other for "tab headers". This would let you add mouseovers and stuff on the tabs also in the browser. Then just make this render as an H2 in the PDF renderer. That would be relatively easier to implement on both ends I think.

But either way I think just rendering the tabs as sections in the PDF is probably the way to go. There will be things that PDFs simply cannot render though - and I think this is fine but it would be cool if we could capture those and warn users during editing.

Update: I should mention in terms of scope, I'm perfectly happy to see any of those implemented. I maybe don't have time to implement it but I'd love to see it. Just be careful about maintenance burden - pick good general syntax and tests are always appreciated.

[hexylena]

Ok, sounds like both of these are in-scope then, and we should just implement features directly in the workflow report then!