I haven't done this for my own papers, but I have developed a couple of visualisations to accompany colleagues' papers. The advice I'd give you depends on what you want to achieve. Do you want something to help readers of the paper explore the results, or do you want something to help non-readers (stakeholders, the public) digest them?
I want a resource to assist readers of my paper/users of my data
The easiest option is to put your Shiny app up on shinyapps.io (along with instructions for users to deploy it locally if they have R running, so that they can use it in the event you've blown the free tier) and link to it in the paper. If the journal has some sort of capability for accompanying visuals and it allows general iframe embeds, use that; if not, just link to it in the abstract or intro. You might also want to consider getting a separate DOI either for the dataset or just for the Shiny app, if it's complex enough to be considered a 'product' in its own right.
Following on from that, if you want this to be a product that researchers or stakeholders access when they want to work with this data, you could choose to:
- Have it hosted (on shinyapps.io or elsewhere) and accessed as a web app. This will either come with usage limits or ongoing costs, so you'll need to do some budgeting.
- Have people run it on their local R installations. There're a few ways to do this, but they all assume that users have R installed and at least enough knowledge to type in an expression to run the app. If you go this route, I would probably consider creating an R package to distribute your app and the starter function.
- Package your Shiny app as a downloadable executable. There're also a few options for this, and I'm not super experienced with them. You might also find that the options vary a little depending on the platforms (Windows, Mac, Linux) you're targeting.
I want to get eyeballs on my work
If you want something that'll help the public or stakeholders understand, or something to help put a spotlight on the paper, I'd skip Shiny entirely and use
htmlwidgets. Media attention on papers—either social or traditional—is going to hit in a wave and then die off quickly, so you need something that you can receive a lot of traffic within a day or two without bankrupting you. Packages that work with
htmlwidgets can output a self-contained HTML file, and that file can be deployed to static hosts like GitHub Pages and Netlify and receive basically unlimited traffic for free.
In this case, it's helpful if your journal can embed the visuals in an iframe, but it's not super necessary because you can just write a press release and embed it in that. Even better, if you include the embed code in the press release, reporters can jut copy it straight into their reports and include the visuals in their news articles. In fact, you can open up the
htmlwidgets output file, pop a Google Analytics code in there and track how news organisations use your work.
I did this for a colleague's paper on heatwaves late last year. It was a fantastic paper, so it would've done brilliantly anyway, but it was great to see the visuals included in a lot of domestic and international media reports, and it gave us a lot of insight into how the story was picked up.
We saw a lot of traffic within 24-48 hours of press release and another massive surge domestically later that week when a couple of other bits of work were released that tied in well (the reporter had decided to publish them all at once). We also saw smaller surges weeks-to-months later when various outlets used the work in features on heatwaves, as well as on subsequent heatwaves later in the summer—whether older articles were being re-run by outlets or users were simply seeking them out on their own, I'm not sure.
The downsides of using
htmlwidgets over Shiny are:
- No reactivity. Some
htmlwidgets packages, like Plotly for R, feature limited interacitvity like zooming or brushing, but essentially everything needs to be 'pre-crunched': you won't be running any R code when your users access the visuals.
- Since everything is rendered in the browser, plot complexity is limited by the abilities of your users' devices, and it's going to be variable. You might want to test how your visuals look and perform on a few desktops and phones (especially if you're shooting for media attention: lots of media traffic will come in over mobile). It'll probably be fine, but things like 1000+ points or many layers of spatial data could slow things down. In the exampleI included above, I wasn't great at working with Leaflet, and the map ended up rather bloated, even with me simplifying the regions to cut the polygon count (which also resulted in some weird looking seams). Not a big problem given it rarely headlined articles, but something to keep in mind.