From Concept to Impact: Building and Launching Shiny Apps in the Workplace - posit::conf(2023)
Presented by Tiger Tang Learn to build and launch a Shiny app like you are working on a start-up! Unlock the potential of Shiny apps for your organization! Join Tiger as he shares insights from implementing Shiny apps at his workplace, handling over 160,000 internal requests. Discover a practical mindmap to find, build, and enhance Shiny app use cases, ensuring robustness and improved user engagement. Materials: https://tigertang.org/posit_conf_2023/ Presented at Posit Conference, between Sept 19-20 2023, Learn more at posit.co/conference. -------------------------- Talk Track: Bridging the gap between data scientists and decision makers. Session Code: TALK-1074
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
So, picture this, it was a beautiful Tuesday morning in 2018, I've just wrapped up the final test of a Shiny app, which I'm convinced to be the game changer our team needs. My coffee even tastes like success.
Reality check, fast forward a month, the app I thought was gold had zero visits. Now I was no rookie in Shiny after Elephant back then, I've already built and launched half a dozen of those, but here's the twist, the popularity did not grow as I added more fancy widgets and functions.
One day, while watching Silicon Valley, a TV show about the ups and downs of a startup, it hit me, that building and launching a Shiny app is just like starting a company, where the app is the product. It is important, but also just one piece of the whole puzzle. There are other things to consider in the whole process.
In the next 16 minutes, I will walk through all the other similarities between the two, and trace back a mind map that helped turn my apps from zero usage to now handling 160,000 requests in the last few years.
Finding the idea
Now similar to a startup, a Shiny app also starts from idea. So in the startup world, there's a saying, there's a quote about why do you start a company that goes, don't build a startup for the sake of building a startup. Trying to get people more focused on the problem it tries to solve, which can be perfectly applied to Shiny apps.
To build a Shiny app, we need to first find out the problem. Well this is probably easy to say, but for me, I came up with absolutely nothing for the first few months after learning about Shiny. So where can we look for these ideas? Here are the directions I found.
Now think about all of these startups. Many of those ideas would fall under the following three categories. Things that everyone can use. Things that would replace repeated work processes. And things that would solve challenges in a few organizations or industries.
But now even with these directions, they're still hard to come up with. But luckily we are trying to implement a Shiny app at a workplace, which allows us to add one condition in the end. Now for Shiny apps, looking for things that everyone can use in the company is less difficult. And repeated work processes in a department are probably common to spot. And pain points for a specific team are much easier to identify.
Now these directions may provide you a more targeted view when you are trying to find the problem.
Now once you find the initial idea, it does not mean just go ahead and do it. We still need to validate them. So for startups, they would do market research to try to measure the need and talk to consumers to understand the problem. If they don't do that, I'm pretty sure we would all have a glow-in-the-dark sunglasses now.
So for Shiny apps, to make sure there is a real need, we can do our own market research by, for example, measuring the amount of efforts the Shiny app could save to try to quantify the impact. And we can also talk to the potential users, in this case, our colleagues, to understand the problem and how may the new solution affect their workflow.
Now if after a while, there is still no idea that comes to mind, we can still see what are the ideas we can copy. After all, not all startups were built on over-agent ideas. To save myself from unnecessary lawsuits, I'm not going to name any names, but it is totally fine to learn from cases that work for other companies and organizations and apply it to yours.
So with that, I've listed a few examples on my blog, which I'm going to share in the end, that may help you customize a solution for your organization. To dive deeper in just one example, oftentimes when stakeholders want to make, let's just say, data-informed decisions, they would reach out to the data teams, who then runs a set of SQL code to extract from databases, compile the results, and share it back with the stakeholders.
Now when those SQL codes are similar or easy to modify, it is possible for us to save some efforts. To do that, we can create a Shiny app that allows stakeholders to directly interact with the databases without having to go through the data teams. We can even make it possible to email the results so that nobody has to wait for the job to complete, and make it possible to handle multiple requests at the same time.
Securing resources
And now, after confirming the idea, startups will need financial support. So will your Shiny apps. So in that, in pitching for investments, there is another saying in the startup world that goes, don't pitch the product, pitch the business. We need to get people focused on pitching the broader business opportunities, which can also apply to Shiny apps.
And when asking resources for Shiny app development, we need to focus less on the Shiny app features and more on the impact. And you may already have the impact while doing the stage of validating your ideas. So we just need to find the right group of people to talk to.
So for startups, there are a few. The first one is the incubators. So this is where the incubator founder, who is more experienced, more resourceful, will guide you as you build your product. And more often, they will work together with you as with the investors when more investments are needed.
This could be a common case for Shiny apps where you are still you. The incubator founder in this case would be your manager, who would provide you the initial investments of time and resources. And instead of presenting together with the investors, you guys would present together with the stakeholders when more investments are needed.
Now for startups that do not work with incubators but still need investments, you will sometimes see them on pitch contests like Shark Tank, where they are directly pitching in front of the investors. For us, the idea is to look for internal opportunities like hackathon or innovation activities where you can directly bring your ideas forward in front of the stakeholders.
Now even if the previous two are not an option, you can still try the last option to get the funding via crowdfunding option like Kickstarter, where you are directly pitching from the users. Similarly for Shiny apps, we can do the same by directly connecting with the users, in this case your colleagues, to get them to promote your app and ask for the resources from their supervisor. One person may not provide enough help, multiple might. You get the idea.
Developing the product
Now once your investments are secured, time to develop product. Now when it comes to Shiny app development, there are so many great resources, I'm going to keep this one very brief. But when it comes to developing the product, there is another quote in the startup world that goes, it is not about building the best product, but building the right one. Trying to get people focused on just the necessary features.
And which also applies to the Shiny app, because the one thing that both startups and Shiny apps need to steer away from is to be overdeveloped. To do that, while startups would try to stick with the core features, for Shiny apps, we need to minimize all the nice-to-have widgets, which can be really hard to do.
Because I know for me, and also for some of the other Shiny app developers, coming up with the possible features to add to the app, it's almost like knee-jerk reaction. You just can't help it. For example, when there is state or province data, I would immediately think about possibly adding an interactive core of the platform. And when there is a plain text file export needed, I instantly think about possibly adding a download button, which will allow users to download the HTML document that would host the plots and tables, which often ended with functionality that wasn't utilized, as well as overwhelmed users.
And now, even if we can keep ourselves in check, it is still possible that new ideas may come up throughout the development. Now, for startups, while they will need to avoid scope from all areas, for Shiny apps, we will need to manage all the new feature requests coming from users or stakeholders. Now, oftentimes, it is going to be more than just the amount of efforts it takes to make the feature possible, but whether if it is a necessary one.
Because almost no one would mind waiting for a few extra days to get a Swiss army knife when all they needed is a toothpick.
Because almost no one would mind waiting for a few extra days to get a Swiss army knife when all they needed is a toothpick.
Getting users
Now, after the product is built or the Shiny app is built, time to take off the Shiny app you all have had and try to focus on getting users. After all, you can't expect the users to come to you automatically. As another saying also in the startup world goes, build it and they will come, only happens in the movies.
So what are the things that startups would try to do to get more customers? Well, for that, I would probably need to take the whole rest of the afternoon to talk about it, but luckily, I don't have the slides. So let me just mention a few examples there.
One of the first things the startup would try to do is to market the product by bringing a strong brand identity, which is something that we can do as well for the Shiny app development, to try to bring our own personality. For example, you may know some of these as the 80s action movies, but what you do not know is that they are also the names of the app that I built and launched at work.
For the record, these Shiny app functionalities have nothing to do with the movie content, but the truth is that no one is going to remember the app name if I try to name it solely based on what it really does. But combined with my personal interest and the weak connection I can find between the business goals as well as the app name, I was able to create a fun and a popular reference among users. And these are the apps that helped solve 160,000 requests in the last few years.
The other thing that startups would try to do is to try to make their product more accessible via, let's just say, enhancing the search engine results. Luckily, we don't have to do that for an internal Shiny app, but we can certainly try to make things more accessible by building a landing page with CNAME.
So imagine these are the list of Shinies that you have at your workplace, along with assimilated links. Now, if your users are not super organized with web links or a super user bookmarking, it is almost a certainty that someone will need to dig around the communication will ask you about the links of their Shiny app or the Shiny app that you built.
So instead of asking my users to do that, I've set up a CNAME, which in this case is an alias to an internal web address, and built a landing page that would host the directory for all the Shiny apps that I built. Now, for the users, instead of having to remember all of these links above, all they need to remember now is one word, the CNAME. Put it into the internal web browser, which will take them to the landing page that will host all of these applications. And based on the previous movie reference I had, you can probably guess what that CNAME might be for my landing page.
Now, the last thing the start-ups would want to do is to enable the product content sharing via what it does. For Shiny apps, we can achieve similar effects by allowing the users to share the following things. For example, the work results. And this is where we can easily enable by having an email-only option or download button of the results from the Shiny app.
Work progress can also be shared if we have a built-in functionality for the users to see the sessions that they have ever used and what are the before and after impact. And lastly, no one has ever said that Shiny apps couldn't be fun. We have created customized messages that will pop up randomly while a user is waiting for a job to complete. Now, for the record, Phyllis is a real co-worker and a user of the app.
Operations and continuous development
Now, after that, there's one more thing, operations. So like start-ups, Shiny apps is not something that's one and done. It is something that will require a continuous development. And for both start-ups and Shiny apps, the one thing that they need to take care of is customers.
So while you can see that the start-ups, they will spend a lot of efforts to try to ensure there is a smooth customer onboarding experience, for Shiny apps, we need to make sure our apps are still user-friendly or providing a smooth experience for the new users by placing resources like a detailed readme or recording instructions.
So while start-ups would also care about the customer success, we will need to think about if we are providing the ways to gather feedback to provide what the user needs. One of the other things that the start-ups will need to take care of are the communication with their investors.
And if you think about all of these quarterly financial calls, almost every single one of them will follow the following structure that will start with a financial performance review for the last quarter. And they'll talk about any operational highlights or wins or challenges and end it with guidance or outlook. For Shiny apps, it is also very important for us to connect with our stakeholders to let them know what's going on with the investments. Similarly, we can follow the structure that starts with the app usage and impact. Then we talk about any wins or challenges along the way and end it with what to expect next.
Putting it all together
Now you can probably see that building and launching a Shiny app is just like starting a company, where we will all start from an idea and then we need to validate the idea before any development. When we need resources, we need to reach out to the managers, stakeholders, or users for help. And when it comes to the product development or the app development, knowing that there are so many great resources out there, we still need to just try to keep only the necessary features and manage any new requests that come along the way.
Building the app is not enough. We need to market the product by giving it a brand identity, starting with a name, make it more accessible with CNAME as well as a landing page, and create shareable information for the users. Lastly, Shiny app is not something that's one and done. It is something that will require a continuous effort. While we're making sure we're engaging with both new and existing users, let's make sure also plan out the connection with the stakeholders to talk about what's happened, what's new, and what's next.
Overall, the whole journey is the Shiny app.
Overall, the whole journey is the Shiny app.
Now if you forgot everything we just talked about or if you just walked in, remember this. Whenever you feel lost in a Shiny app journey, just think about what the startup direction would be, and you will be just fine. Thank you.
Q&A
All right. Thank you, Tiger. We've got time for a couple of questions. You can find those in the Slido. So first up, what are your recommendations for hosting Shiny and making apps available? Oh, Pozit-Connect? All right.
How do you evaluate the success of an app beyond requests or user numbers? Beyond requests and what? User numbers. Oh, yeah. So let's just say user numbers and all that, it's almost like one of the generic ways. It's almost like you can apply it everywhere. But think about a Shiny app that would be able to share some of the business insights. Those are the ones maybe it's less frequently asked questions that you are getting the answer, but it is still possible that these will fund and then power all of these much more bigger business decisions that may impact some of the much bigger budgets there.
So I would say for different organizations, you would probably have different ways of evaluating that, but let's not just limit to the amount of users or the amount of requests that it handles. Okay. Fantastic. Thank you again, Tiger.