Resources

Mine Çetinkaya-Rundel | Making the Shiny Contest | RStudio (2020)

In January 2019 RStudio launched the first-ever Shiny contest to recognize outstanding Shiny applications and to share them with the community. We received 136 submissions for the contest and reviewing them was incredibly inspiring and humbling. In this talk, we shine a spotlight on the backstage: the inspiration behind the contest, the process of evaluation, what we learned about Shiny developers and how we can better support them, and what we learned about running contests and how we hope to improve the Shiny Contest experience. We also highlight some of the winning apps as well as the newly revamped Shiny Gallery, which features many noteworthy contest submissions. Finally, we introduce the new process for submitting your apps to the Shiny Gallery and, of course, to Shiny Contest 2020! https://rstudio.com/resources/rstudioconf-2020/making-the-shiny-contest/

image: thumbnail.jpg

Transcript#

This transcript was generated automatically and may contain errors.

I want to start by the inspiration behind it first. And the inspiration actually was the bookdown contest. And this is one thing I want to read off of the slides because I really like UA's words here. He said, with this contest I want to encourage bookdown users to share your authoring experience and the extensions you have developed to make it even easier for other users to write their own books, reports and dissertations, etc. This was basically the inspiration behind the Shiny Contest as well.

We really love seeing the apps you all develop and the dashboards and the interactive documents. And when you openly share your code and your process with others, it actually is incredibly beneficial for the community. And we also realized that the user showcase that we had since Shiny Package has been around, that featured really fantastic apps actually didn't have links to the code for all of those apps and it would be kind of difficult to go back and try to get all of that, especially because some of the code gets out of date. So we've been thinking about a way to refresh that. And we thought, hey, maybe we can make it into a fun game. So we did.

And, my God, it must have been a fun game. So we started January 7th and gave a two-month deadline. And I was thinking, okay, this is not going to be so bad. I can work on other stuff for a while. And then you can see that last bit. People wait for the last minute, I suppose. So we had 136 submissions, which was very, very cool.

Contest requirements and submission process

So what I kind of want to talk about first of all is I'm going to show you some amazing Shiny apps today. And I feel like I've really kind of scored a good talk, because I can show really amazing stuff, but I'm not the one who made them. But at the same time, I want to also show you what it takes to enter the contest, because it's really not much. This is all we required. Your code.

Many people use a GitHub repository, though that was not necessarily a requirement. We asked that you use an RStudio Cloud project to host your app in. There were some cases where that wasn't the case, and we still accepted that. I'll mention one important thing in case people are thinking. So if you have an app that requires an API key, obviously you're not necessarily going to want to share that. And we completely understand that. So we kind of hope that you will discuss why certain things may or may not be fully reproducible by somebody else, but we ask that you kind of provide some description as to how I could reproduce it. But the idea is that every app is hosted. We have the code, and we have it in an RStudio Cloud project, and we also want to link to your deployed app. And you can simply use Shiny apps.io, or if you have another Shiny server you want to deploy on, that's fine as well.

And many people added these. That was really, really nice to have a brief summary. Some of the highlights, because there's a lot in some of these apps, and they may not be kind of very clear to the eye right at the beginning, and at least a screenshot so we can kind of see what it's going to look like. And so this was one of the posts from RStudio community where the submissions are made. You can see, I mean, the app is fantastic, but to the entry to the contest, there isn't a whole lot going on.

This was actually one of our runner-ups. People have been kind of submitting their Tidy Tuesday plots on Twitter, so this basically pulls from that. It's a really cool app. And what we said was that we're going to be judging the apps based on their technical merit and or their artistic achievement. So what does the UI look like? And we're going to keep in mind that some apps may score really highly on both of these, but some might score higher on one aspect and not the other. And we also said that we would be considering feedback and reaction on RStudio community. So each submission actually ends up being a post on RStudio community, and we hope that people actually like the apps and actually comment.

Evaluation process and rubric

So I actually started by getting the data out of RStudio community and calculated percentiles of likes just to see if binning these into categories in terms of being able to maybe consider the number of likes would be a good criteria or not. And ultimately, even though I did that calculation, that didn't factor a whole lot into it, because there was the aspect that if you submit earlier, obviously there's more time for you to get more likes. That doesn't seem entirely fair if we said that you can submit any time during that time frame, but that was useful for us to find out.

And then what I did is I took a random sample of 15 of these apps, so it wasn't the earlier or the later ones, but a truly random sample, and literally went through it all. What does the UI look like? What does the code look like? What was the ambition? Did they actually fulfill that? And used that to develop a rubric for it. So this is what the rubric looked like. Five points for technical merit. Five points for artistic achievement. We also looked at the narrative on the post on RStudio community about how well you described what you were trying to do. And then those binned categories for feedback.

And then we had to narrow things down. So the first pass is I literally clicked through all of the 136 deployed apps to categorize them into either we should consider these further or not. And then all of those that were categorized as yes, we should consider these further got scored on the rubric that I shared with you. And then for any app that was on top 30, I actually went through and tried to reproduce them. So I went to RStudio Cloud and see if I can actually reproduce it. If there wasn't a good reason described for why that couldn't be done, as I mentioned something like an API key, then I skipped that one and added another one and narrowed things down to about 15 apps, at which point I pinged Joe and I was like, all right, I'm going to need one other person to actually go through these. So he helped out and we basically picked the winner.

And then for any app that was on top 30, I actually went through and tried to reproduce them. So I went to RStudio Cloud and see if I can actually reproduce it.

The winning apps

So it was a process. But I think we learned a lot about how we can evaluate these things. So I think the mechanism is going to be a little smoother next time. So let's take a look at what the winners are. So the first one is the most technically impressive award, the IC app. The IC stands for Interactive Summarized Experiment Explorer. So that's by Kevin Ure, Charlotte Sonnison, Federica Marini, and Aaron Lund. And the app is incredibly impressive internally.

So it is designed for interactive exploration of high throughput biological data sets. And what it is, is these panels that you're seeing in this screenshot, and I could only get so many of them, there are actually six of those, they're really nicely linked together. So as you're playing with one and doing some selection on one panel, you can see it reflected in the other ones. And I think this last bit is going to be relevant to a later on talk that's coming up here. You can actually generate a reproducible R script. So the idea here is that maybe somebody who is not an R programmer is doing a little bit of the analysis interactively, but then they're able to reproduce, they're able to get a reproducible R script of the results that they achieved. And this predates Shinymeta, so that's incredibly, I think, impressive.

The next one is just beautiful. It was the best design award, 69 Love Songs. So that is a, the album is called 69 Love Songs. This is by David Smalley. He actually has a wonderful blog post explaining what it looks like. So there is a lot of technical things going on there that are great, but most importantly, it had an incredible visual appeal. The colors actually match the album colors, the font matches the font used on the album. So a lot of attention to detail happening here. And in terms of the analysis, there's web scraping to get the lyrics to begin with, and then some text analysis methods. And in each one of these tabs, there are different ways of visualizing the text data using a variety of different text analysis packages, some of which I actually wasn't really familiar with prior to playing around with it. And really, really thoughtful storytelling.

So even if you're not a fan of the Magnetic Fields album, you actually can find something to enjoy, I think, in this app. And the code is available. So if there's an album that you do like, you might want to try to see if it actually will carry over.

The next one is the most fun one. I think what happens during the breaks at this conference is a testament to how much we love our hexes. And this is a hex memory game, basically. It is a lot of fun to play. It's by Victor Perrier. It's not the first game that I've seen on Shiny, but it is incredibly impressive and works really, really well. And if you actually start looking through the code, even though it is complex, it's written so nicely. It's very possible to follow along, even if you might be newer to Shiny. And so I thought that really kind of earned it the spot on one of the winning apps.

The last one is so cute. And if you have a pet, this is just going to make you feel bad. I can just tell you that. So if you take your pet to the vet and then you stash away the papers they give you for medical records in a folder, thinking if you have an emergency, you're going to be able to find it out, forget about it. You're not a good enough pet owner. I have four cats, so I know how I felt. So this is basically an app by Jen Allen. It's a dashboard. And the dogs are called Layla and Lloyd. And apparently one of the dogs actually had some medical issues, so there was a lot of vet visits that were happening. Technically speaking, that timeline visualization that you're seeing is really, really effective in terms of figuring out which medication the dogs were taking during which time. And also, you can use drill down. So click on these bars, drill down, and actually get to a PDF of the certificate, so either a record, the medical record, or a vaccination certificate. Just an incredible use of the database she was using on the back end and actually an ability to interact with that. And very cute dogs, so that obviously helps.

What we learned and what's next

So what did we learn? And one of the things we did say initially was that we were going to do awards as in an open category and a novice category in order to make sure that people who might be just starting off with Shiny also feel like they can be a part of this. But I'd say I'd made a mistake that I didn't actually record that information. And it's really difficult to look at an app and kind of assign someone to that category. So one of the things we'll do differently next time is to actually ask people to categorize themselves into experience levels to see if we might actually consider that to make sure that we're actually giving some awards to people who might be recently starting to work with Shiny as well.

As I said, we looked through some of the code, and I think one of the really difficult things is to do code review across developers who don't work in the same framework. They might have choices they're making in terms of how they code up their app. That works for them. Maybe that is not how I do it or Joe does it or somebody else on the team does it. But there is no requirement of following a certain guideline. So that actually makes it really difficult. But I'll give you one example of one of our runner-ups. So this is a CRAN Explorer. It is not the only CRAN Explorer out there. But it is a really visually kind of striking CRAN Explorer. And one of the things we liked about this app was that it made really good use of HTML templates. And the code was written so nicely that you could really kind of factor out what parts of the code was building out the UI using the R and Shiny code and what parts of it was coming from HTML. So in this case, it was a little bit more straightforward to say, yes, this is well-written code. But I think that's a challenge that's just going to stick with the Shiny contest or any similar contest forever.

Well, this one you can imagine. We should start reviewing them earlier because my guess is that curve is going to go up again closer to the deadline. So the review took a little bit longer than what we had promised. But now we have some more experience. So hopefully we'll be able to turn around the results a little bit faster. And I think it will be useful now that we've seen creativity from other contestants as to how they submitted their apps by providing more guidance for what makes a good submission.

So one of the things is when you're posting on RStudio Community, so this is one of the runner-ups of the contest as well, give some more information than what's needed. This one was particularly long. But what you're seeing is there are some screenshots, there are some GIFs, and there's also narrative to go along with it. And I think this is really helpful. And also, you know, maybe you don't have the most performant app. But if you give me something to read through while that's loading, that's not a bad thing. The other thing is this idea of actually providing a walkthrough. So a few of the apps that were submitted had this where you come in and you don't have to just stare to see what you need to do or you don't have to just read static text. You can actually walk through the app, and that's how the developers decided to highlight the important features of the apps.

Remember all of the contest submissions from last year are openly available still as posts on RStudio Community, whether they were winners or not. So if you would like to do something like that and are looking for the code, you should be able to go and track it down.

So what's next? Well, two things. One is we have actually reinvented the Shiny User Showcase, and it's actually it sits along with the Shiny Gallery on the Dev Center. So this is the URL for it. And we have moved over the winning apps as well as many of the honorable mentions and runner-ups if the app developers agree to have their apps featured here. And we will be adding more to this. I actually have plans to add a form here so you can submit your app for consideration to be kept there. But I decided I'm going to hold off on it for a while, because for the next two months, you have a different way of submitting it. We have another contest.

So I actually just posted this on RStudio Community, Shiny Contest 2020 is live. And what we're going to do this time is if you go to this community post, it will actually take you to a form that looks somewhat like a Google form, and it will feel restrictive initially, where we are asking you to put in certain pieces of information we want to make sure everybody has so that we can export this data easily. So in addition to your name or whatever, a description, and also giving you some guidance about how long these things should be, links to certain things we're requiring, what happens is once you submit that form, it actually turns into a community post, and you can do further editing there. So the idea is we're going to collect some information initially, but if you want to customize how you're presenting your app, you still have the opportunity to do so.

So the idea is we're going to collect some information initially, but if you want to customize how you're presenting your app, you still have the opportunity to do so.

So I usually give links to my slides at the end of my talk, but at this point, as I said, a lot of the work I presented is not really mine, but of the people who contributed to the contest. So up top is the link to the Shiny Gallery, and if you see any issues with any of the apps that are there, anything that's not working, I'm the person to contact, and I'd be happy to take care of that. And also the bottom link is the link to the Shiny Contest 2020. We are going to follow up with a blog post in the next week or so, but, hey, you guys are here, so you get a preview of it before the blog post goes live. Thank you very much.

Q&A

How do you build a walkthrough?

So I don't know that I can actually walk you through how to build a walkthrough on the spot here, but what I can do is what we'll do in terms of the blog post that will follow up for what makes a good submission, I'd be happy to provide the links to some of the apps that actually did that. It requires a bit more than just using Shiny, but the code seems pretty reproducible to me, so I feel like it will be possible for somebody to learn from the code.

Will there be a student category, like undergraduate students, possibly with the prize of free attendance at the conference next year?

That question is above my pay grade. So I think the idea is that by asking for experience level, we are asking for so the cutoff is actually have you been building Shiny apps for less than a year or more? And we want to try to make sure that we're able to recognize some of the apps from people who have recently started as well. I would imagine that it's possible for an undergraduate student to fall into that. I don't know if one of the awards will be attendance, but I can tell you one of the really good awards is if you're one of the grand prize winners, you get a little bit of time with somebody from the Shiny team, like a 30-minute call where they can actually help you debug your app, and I feel like you probably can't put a price on that.

In the gallery, will you list what packages each app depends on so we can find apps that use packages that we're interested in learning more about?

That's a really good idea. So that is not something I pulled out, but that would be quite straightforward to do. So I will take that as a feature request. Currently the code is linked, so one could do that, but I will take a note of that, and I think that would be a good idea to include.

If you ask people to rank their skills, won't they sandbag to increase their chances of winning?

Probably not. Hopefully not. I'm going to say hopefully not, but I feel like the spirit of it is not necessarily to give anyone unfair advantage, but to make sure that people who may have just started working with Shiny actually feel welcome in the community. I am going to act optimistic for a second. I'm not known to be an optimist, but I think in this community people are going to want to encourage people to do that. I will also say that that's not going to be like a straight cut threshold for ranking apps. It's just I want to make sure that we're able to recognize some of the people who feel like they are new to this and take a look to see if there's something that we might be able to acknowledge there.

Finally, there's a question about the rubric, and will it be shared in an article? Yeah. So now that we have developed a rubric, the blog post that I'll write, I'll actually add to it in terms of what the selection criteria look like, and one thing I'll highlight from a rubric is that we gave equal points to technical merit and visual appeal, just basically acknowledging that some people like working on one aspect and some people like working on the other, and ultimately we'd want to recognize both of them.