R-shiny – how to set it up effectively and avoid common mistakes

Transcript

R-shiny – how to set it up effectively and avoid common mistakes

[00:00:00] Alexander: You are listening to the Effective Statistician podcast. The weekly podcast with Alexander Sha and Ben Pisca designed to help you reach your potential lead great science and serve patients while having a great [00:00:15] work life balance.

[00:00:23] In addition to our premium courses on the Effective Statistician Academy, we [00:00:30] also have. Lots of free resources for you across all kind of different topics within that academy. Head over to the effective statistician.com and find the [00:00:45] Academy and much more for you to become an effective statistician. I’m producing this podcast in association with PSIA community dedicated to leading and promoting use of statistics within the health industry.

[00:00:59] [00:01:00] For the benefit of patients, join PSI today to further develop your statistical capabilities with access to the ever-growing video on demand content library free registration to all PSI webinars and much, much more. [00:01:15] Head over to the PSI website@psiweb.org to learn more about PSI activities and become a PSI member to pick.[00:01:30] 

[00:01:30] Welcome to another visit of the Effective Statistician today, like last week, I’m having Daniel Sese on the line. Last time we talked about our packages today we wanna talk a little bit more [00:01:45] about data visualization and specifically, but before we. So more technical details around our shiny, let’s talk first about generally interactive [00:02:00] data visualizations, because I think this is an ever increasing area where we can, where we have big opportunities to cut core, increase quality, increase [00:02:15] efficiency, speed up processes.

[00:02:17] What field of big opportunities have you seen for interactive data visualizations in general? 

[00:02:24] Daniel: Yeah. Thanks Alexander. A great topic. I noted two big opportunities here on [00:02:30] my notes. The one is generally to iterate faster in an interdisciplinary team. So what do I mean by that Is that you don’t need to wait days or weeks anymore for an updated plot or table or some [00:02:45] anything.

[00:02:45] From the statistician programmer like maybe 20 years ago or something. And one important example here in clinical trials is the two framework developed by Roche, so TEAL. And it’s not [00:03:00] the the framework that talks about lean organizations, but it’s a shiny framework for clinical trial analysis. But this framework, it’s super simple to create interactive tables or graphs.

[00:03:10] For your study based on your data sets, and these things can be super [00:03:15] helpful, right? For example, if you have a study readout event with senior management and you are going through the plots, they ask, okay, how would it be in the subgroup? Right? How the results look like there. And you can just click and you can directly see it [00:03:30] within five seconds, right?

[00:03:31] And if you compare it to the past where you need to wait one or two weeks. For the machinery to run and produce the static files sent by email. So it’s a huge acceleration in terms of how you can iterate in an [00:03:45] interdisciplinary team where not everybody’s program. All right. And then the other note I have is that lowering the hurdle to basically be able to focus more on the question rather than the implementation.

[00:03:58] Right? So. [00:04:00] Sometimes what I mean by it is sometimes also for myself, I noticed that, oh, maybe I would like to play around, right? So for example, recently I had some kind of use case where I wanted to look at different dose [00:04:15] response profile. I had a certain kind of functional form as a R function, and of course I can play around with the code and I can just change the values of the keyboards.

[00:04:24] And execute it again, but it takes certain steps of manual [00:04:30] things on the keyboard. I can turn it very quickly into a quick shiny app to just play around with this function in a much more intuitive way so I can use a slider, slide it to change the values. So much more easy. So much more intermediate [00:04:45] feedback.

[00:04:45] Visual feedback. So. That’s what I mean by, yeah, these interactive data visualizations, it allows you to focus more on a question rather than the implementation. Yes. I lost the 

[00:04:56] Alexander: second example you brought. You can plan [00:05:00] for different scenarios like designing a clinical trial and you have different maybe subgroups that you look into.

[00:05:10] Always different effect sizes. You can have different [00:05:15] assumptions in terms of how fast you will have certain events showing up that drive your sample size. You can play with clinical operations kind of metrics and think, okay, what will be like [00:05:30] easy? How fast will get sites on board? How fast will it be?

[00:05:34] The recruitment for the different sites? All of these kind of different things. Scenario planning is another. Key area where you can use that, and that can be in [00:05:45] design, but then can also, of course, be in the analysis part where you have different assumptions maybe about your intercurrent events or what happens after the Intercurrent events.

[00:05:57] All of that leaves a space [00:06:00] for exploring. I think generally it’s always when you wanna explore your data and relationship. Yeah. 

[00:06:07] Daniel: Okay. And it makes exploration so much more easy and so much, you are so much more likely to explore things like this [00:06:15] rather than if you have a whole program and on the top you just define the hardcoded values for whatever, intercurrent events rates or whatever.

[00:06:23] Then you will maybe run it maybe one or two times with different values and that’s it. But if you have this in an app. [00:06:30] You’re likely to play around more mc quickly where things go wrong or how sensitive this results are. 

[00:06:37] Alexander: It’s also very nice to communicate with cross functionality. Yes, I completely agree.

[00:06:42] For data results, it’s [00:06:45] also super helpful for any kind of safety evaluations because said is by design a very interactive. Data exploration part, you wanna understand where the safety is coming from. [00:07:00] Other specific patterns and there, do they specific comorbidities? What are the confirmit medications that are given in these kind of areas?

[00:07:09] Is there a relationship between safety and efficacy of dose? There’s so many kind of different [00:07:15] exploratory questions that you have for safety. That’s a very important aspect. Work by different safety data visualizations groups. You can find use cases around the such interactive data visualizations. On the [00:07:30] data visualization special interest group side, just search for visualization.

[00:07:35] SIG on the PSI homepage and create. So what are typical challenges around trading such [00:07:45] visualization? How big is that hurdle? 

[00:07:47] Daniel: In the past without shiny, it was hard to implement this in practice, right? It was much harder. You needed, for example, to use Java or JavaScript to have these kind of interactive graphical user interfaces put [00:08:00] together.

[00:08:00] And of course, I mean, I have never done this really myself. Probably you need to have there. Computer scientist degree to really like doing that a lot, and it’s also hard to maintain if you have it like this because you then need to create R function calls from [00:08:15] Java and then it’s all kinds of hassle there.

[00:08:17] Shiny has revolutionized this process and made it easier because you can do everything in R itself basically. Of course, if you want to customize. Very [00:08:30] advanced things. You might still need to use some JavaScript or something, but this is really like a very expert kind of usage. Then it revolutionized this.

[00:08:37] It’s much easier, and nowadays, of course, with generative ai, it’s so much easier actually to [00:08:45] get started with writing your shiny app, right? You can, for example, dart from a function for given inputs that gives you a graph or table and then convert this function into a shiny app where I can play around with these inputs.

[00:08:57] It will probably get you 90% [00:09:00] there and you can go from there. Today, it’s much easier. 

[00:09:02] Alexander: That’s good advice. You have your raw material, give it to generative ais and go from there. What are best practices when developing shiny [00:09:15] applications? 

[00:09:16] Daniel: Yes, for small one-time use apps where it’s really just about playing around today with something and tomorrow you will not need anymore for sure.

[00:09:25] Then I think this geni based starting point is completely sufficient. So you [00:09:30] mentioned copilot. There is also a bit more tailored product from from poit called China assistant, which is also helpful. And so probably this will already be sufficient for this use case. And actually, I would say for many use [00:09:45] cases, maybe, okay, I don’t know how many percent, but for many use cases, having this small, very.

[00:09:51] Temporary kind of app maybe is already sufficient. Okay. That’s also the beauty of shiny. And it’s very fast and you can [00:10:00] just use it immediately and finished. Right. But not talking about best practices, we are talking about more like larger apps that are more persistent, reused, and multiple projects and so on.

[00:10:11] Right. And for those shiny [00:10:15] projects, it’s like similar like with for our packages, because. Before coding, you should start with a plan. I would start with paper and pencil, and of course if it’s across different locations, you will do that online with the kind of [00:10:30] drawing board and a pencil, and you will talk with your stakeholder immediately.

[00:10:33] Use the app with your medical doctors or safety scientists, and you will figure out with them how should the app look like in the end. Mm-hmm. So what will be the plot? What are the inputs they wanna [00:10:45] change? Maybe try to. Not have too many inputs, because otherwise it would be very confusing. So the fewer inputs the better, and that’s, that will be the start, which we think about this kind of wire framing of [00:11:00] your app.

[00:11:00] There’s also certainly software programs for that, but we will not go there now. But that, yeah, just a simple PowerPoint sheet or Google Slides sheet of something where you can draw stuff is good for a start. A piece of paper, of course, is nice to [00:11:15] start with. And then once you have that. Important for our packages.

[00:11:19] In our packages. You just have functions right here in this interactive world, we always have a server part and a UI part. So user interface part and the [00:11:30] shiny modules are basically the equivalence of functions now for shiny apps, right? So. Similar as for packages. We don’t just write our whole program from beginning to end.

[00:11:42] We instead we structure it into functions. [00:11:45] The same here for the Shiny app. We don’t just write it from beginning to end, but structure it in modules. So very important to use modules to build your app, because that way you will still be able to understand your shiny app, even if it grows [00:12:00] larger and larger.

[00:12:01] Okay? Mm-hmm. So you can then have one module in one file. One R script file and then put all these modules together and you build with those modules, you build the bigger app. Right? That’s a very important kind of [00:12:15] ingredient and design strategy. And then the last part is, again, similar as for R packages, where we talked about tests similar.

[00:12:22] Also here for shiny apps, it’s also important to have tests. Okay. That sounds surprising. Like how can you test this? [00:12:30] It works. You need tests for static parts of your code, right? You might still have functions, but also these modules you can write tests. So there’s packages which are called shiny tests.

[00:12:39] Two for example, shiny test or shiny test two. And with those kind of packages, you can [00:12:45] write tests for the modules. Tests can also work on your whole app and the headless browser, so that doesn’t show up anything visual. This has still the whole app running under the hood. Then you can basically have a test that says, okay, now I wanna click on this button that has this [00:13:00] ID and I wait sufficiently long so that something happens, and then I expect that in my output.

[00:13:07] I see this in this plot, or I expect that this other value in the table has changed and it has this value. Yeah, [00:13:15] so you can write these tests and this is super, super important and super, super powerful. As a best practice. And then of course I didn’t mention it yet. But of course you would also then again organize your code in an art package, even though it’s a shiny app.

[00:13:27] The shiny app will live ideally as [00:13:30] a best practice in an art package because that again allows you to document all of these modules. It allows you to put the test in the right place. It allows you to document everything and make it reusable, and you can easily ship it as a package. You can distribute it [00:13:45] as open source online and all of that.

[00:13:47] And if that sounds all a bit, a lot. There’s a very good YouTube video actually, that we recorded two or three years ago together with Paki and Adrian Mad from Roche, uh, search lessons for [00:14:00] designing scalable and maintainable shiny apps. It’s long, but very useful. 

[00:14:05] Alexander: I found the ui, the user interface part very interesting, and I love that you don’t directly go into programming, [00:14:15] but is that you’re first sketching it out.

[00:14:17] And explored, how will the workflow of the users to then design your interface accordingly? For example, maybe the first thing they need to do [00:14:30] is set certain variables, have that at the top left part of your interface, because we look into interfaces like that form. Look first left. [00:14:45] Top, bottom, left bottom, so at least the Western world.

[00:14:48] We do that this way. Organize an important aspect of your interface. Things that you first need to manage. Put that up there. Then you can have with your [00:15:00] graph in the middle potentially, and things that you maybe do with the graft afterwards. Below it we use so that it’s clear where is the interaction taking place.

[00:15:14] I have [00:15:15] seen, for example, during Covid, we had lots of these interactive dashboards that some parts of the interactive dashboard was not, it was not clear that there was an interactive part there. Just by chance you would find out, so make [00:15:30] sure that you use buttons and things like that to really clarify, oh, here is a button you can click on so that people.

[00:15:40] Don’t need to search for it or stumble over it by mistake or by chance. [00:15:45] Also use things like evolve functionality so people can see further information on these kind of different things. So all things that you can speak about before you have started programming. Yeah, and that [00:16:00] will make the user experience much easier.

[00:16:04] Also, think about pre attributes. Preattentive attributes are attributes that help you to focus the attention of the audience, [00:16:15] like how big are certain things or smaller certain things. What is the color coding, by the way? Talking about color coding. Make sure that you have colorblind proof coding, coding.

[00:16:28] And that you [00:16:30] create some kind of hierarchy in your data visualization. Things that are important should be bigger. Things that are less important should be smaller. Bigger buttons, smaller buttons, color buttons and shaded buttons that are in [00:16:45] grays are maybe less important. Think really cautiously about it, and of course, use color sparingly, but if you have a rainbow at the end, then you have overused color.

[00:16:57] It’s very important. First, create the [00:17:00] user experience that you have and then start coding with it, because that will make sure that the experience drives the coding, not your coding skills. Create [00:17:15] something, it prevents you from doing something that is default setting to accept without thinking, just because 

[00:17:23] Daniel: it was default.

[00:17:24] I just remembered there’s something called shiny UI Editor for very quickly building [00:17:30] the UI in a graphical way and then exporting that tool R code for your shiny episode. It’s also very useful as then as second step. So first of course you discuss with pencil and paper, let’s say, with stakeholders for coding to sketch out the code [00:17:45] line 

[00:17:45] Alexander: of Interac Interactive.

[00:17:45] And for that is, uh, really important to understand with c target audience what the, their workflow. So if yourself, target audience, then it’s easier that most, in most [00:18:00] cases, you are not to target audience. Yeah. Maybe it’s a safety physician, someone in clinical operations or other statisticians that will use it.

[00:18:10] Yeah. Test your user interface and [00:18:15] whether it matches the workflow. Is there the opportunity to embed in our shiny how it is used, so to see, for example, that certain parts of the hin are not used? Or 

[00:18:27] Daniel: is that what I thought already when you talked [00:18:30] about to make it clear for the user interface? I think there is a package where you can basically have a walkthrough when you enter the shiny big hovers over parts and explains step by step, I need to look up the name again.

[00:18:42] Can put it in show notes, but things like 

[00:18:43] Alexander: this can be very [00:18:45] useful. The more powerful it becomes comes with the cost in terms of user friendliness. The more options you have, the more easy you get lost and the more, of course, such kind of introductory training also is important. So [00:19:00] what you just said to walk through, you probably have seen that if you open a new app and then you know these small.

[00:19:11] Text comes up and shows, here’s what you could do with [00:19:15] that. Here’s another function you can alter or some input. Here’s some buttons where you can change the output. Things like that is helpful for you because yes, there’s nothing more [00:19:30] frustrating and building great app that a fully Yes, indeed. 

[00:19:37] Daniel: Having a complex app with many buttons and.

[00:19:41] So many things you can do, not just only makes the [00:19:45] user experience more challenging, but also the maintenance. Right. And that’s one of the mistakes with shiny applications, they become too large. And then in the worst case, everything is in one file. Yeah. Yeah. So you have one file that has thousands of lines of [00:20:00] code.

[00:20:01] And, and then within this file you also have duplicated code, so you don’t have modularization, not following the DRY principle. Those things make maintenance very hard. So that can be a challenge. Status. 

[00:20:11] Alexander: Yeah. If you have a new [00:20:15] audience, it’s better to create a segment, a shiny, then to use an old one and try to make it bigger.

[00:20:24] Yes. New use case doesn’t probably need all the functionalities [00:20:30] that you have had before, and therefore this, this added functionality becomes a burden from a usability. 

[00:20:38] Daniel: It’s usually not a good idea to have a central shiny app that handles [00:20:45] all many different kind of use cases for many different teams.

[00:20:48] So, because then again, you don’t have this. One app per use case, but you try to have one app for multi many multiple use cases. Yeah, your app will grow much larger and you have all kinds of other [00:21:00] problems regarding usability, and that’s also one reason why, for example, the framework I mentioned doesn’t supply a shiny app directly, but it supplies actually the modules for shiny apps.

[00:21:10] So you can basically consider it like a Lego system. [00:21:15] Take the parts you need and build for your use case. You build together for this clinical trial analysis for this readout. You want to have this safety analysis, this efficacy analysis, and that’s it. You put them together and that’s the app for this use case.

[00:21:29] The [00:21:30] reusability comes through the central modules, but it doesn’t come through a central app, and we have seen in practice that this. Philosophy is easier for maintenance, but it’s also much easier for the users, and that’s maybe another consideration for shiny is [00:21:45] also much easier to handle security and user access.

[00:21:48] The team owns the data. The team is responsible to launch this specific app and for user access restrictions. Right? Yeah. Then things like in a kind of federated way, each project has [00:22:00] their own app, has their own restrictions, 

[00:22:01] Alexander: right? Yeah. This is a good way of thinking about it. Have you seen any other typical mistakes that people and creating shiny application?

[00:22:13] Daniel: Yeah, those weren’t the big [00:22:15] ones. I haven’t seen that much of rainbow problems, but it could happen. One other thing that we also mentioned in our lessons for maintain shiny is that you should try to keep this reactivity graph simple. [00:22:30] So what does it mean? It means that both from a kind of usability point of view, but also from a maintenance view, it’s much easier if, for example, you just say.

[00:22:40] All the inputs are on the left side, and each input changes [00:22:45] only the outputs, right? As soon as you have things like, oh yeah, this one input changes, actually the options for this other inputs. And then, or maybe if you click somewhere, the output, it changes the input, or you have multiple outputs, and if you click in [00:23:00] one output, it changes the other.

[00:23:01] So as soon as you get into more complex reactivity. What depends on what and what changes based on what other input. Then things become much more complex, and not just for you as a programmer, [00:23:15] but also for the user to really understand what’s going on. Yeah, so simplifying this reactivity graph is another kind of important best practice.

[00:23:23] How can 

[00:23:24] Alexander: people leverage your company to create shiny [00:23:30] applications? 

[00:23:30] Daniel: Thanks to mention the beginning, this claim, of course, there’s not just our coness, there’s also many other good vendors and consulting companies for shiny apps. And of course we also don’t, cannot do everything, but we, particularly from our, that we specialize in [00:23:45] this intersection of the steep specific methodology and software engineering also for shiny apps, right?

[00:23:51] So we developed professional shiny apps for statistical analysis, clinical trial design, methodology implementations, right? And one. [00:24:00] Primary example is of course, pec Cloud. So you can go on cloud.pec.com to basically, you know, quickly try out designing a trial with group sequential or adaptive [00:24:15] design.

[00:24:15] It’s very easy, as I mentioned, for the R package topic. It’s good to realize when it might be good to reach out to an expert to get some help. So, for example, if you are inheriting a shiny app from somebody else, right? Some [00:24:30] colleague who’s leaving company or to another department, and now you need to maintain this, but you’re overwhelmed by the complexity of it.

[00:24:36] So for example, it’s one of those cases we mentioned before. You have thousands of lines and you have no idea how you ever will be able to [00:24:45] understand this. That might be a good indicator to reach out for help or. If you generally rely on the results of a shiny app for important, for example, executive decisions, you need to be always sure that the app works correctly because there’s millions of [00:25:00] euroes or dollars or Swiss francs depending on this app’s output.

[00:25:04] So then it might also be very good to invest resources into making this production grade and highest quality. Or if you have a good idea, but you don’t have time or interest to [00:25:15] do it yourself, that might also be a good use 

[00:25:17] Alexander: case. Think for this great discussion about our shiny and I myself have seen the benefits of using interactive data visualizations with teams In my career [00:25:30] early on it was always really nightmare to explore data.

[00:25:35] Nowadays it is so much easier, and I do hope you leverage interactive data visualization to explore [00:25:45] your data, to communicate your data, to discuss your data with your stakeholders. Thanks, Danielle, for another great episode. All the best. Thanks. Alexander. Under

[00:25:59] [00:26:00] this show was created in association with PSI. Thanks to Rain and her team at VVS well with assurance background, and thank you for listening. Reach your potential lead grade science and serve patients. Just be an [00:26:15] effective [00:26:30] statistician.