What’s a “successful” Shiny Application?

One of the things that we keep promoting in the ThinkR team are good practices for production software engineering in R. Of course, that implies Shiny Applications—and even more if we introduce the {golem} package, which promotes good practices for “production-grade” Shiny application.

But let’s take a step back and think about what makes a successful/production-grade Shiny Application.

It Exists

That seems like an obvious concept, but of course a Shiny application is successful and ready for production if the dev team was able to move from the idea to the actual implementation to the delivery of the app. It’s a very ‘engineer-oriented’ definition of success, but that’s a pragmatic one: a project that doesn’t exist can’t be labelled as a successful one.

And when it comes to a Shiny Application (or to any web application), the fact that an application exists means that the team has been able to organise itself in an efficient manner, so that they could work together on making this application a success. Anybody that has already worked on a code base as a team knows it is not an easy task.

Working in a framework like {golem} does help you reaching this goal: working inside a formalised structure will help you keep track of what is happening, and allows to grasp more easily what is contained in a given project. For example, if I today open a {golem} project I have never seen before, I will immediately be able to understand how the codebase is organised.

It’s Accurate

Once the application exists, the other parameter that defines a production-grade application is that it is accurate. In other words, the visualisation are correct, the algorithms return the answer they are supposed to, the information are the needed one, etc.

And yes, it happens that you deliver an application that works differently from the way it is expected to work. How do we prevent from that? First of all, by applying the “separation of concern”:

• Business logic should be strictly separated from the application logic: build the back end and the non interactive functions separately from the interactive elements, work on them, validate them, and only once everything is thoroughly tested you can start integrating both together.
• Build a strong and reliable testing suite, so that you can catch any bug that will come along your project.

If you use {golem} and the general philosophy that comes with it, that is something you will be applying from the very beginning: separate everything, build the business logic and the UI, organise everything in files, and of course, as you’ll be using the package structure, use widely used testing frameworks.

It’s Usable

Your application exists, it’s accurate, but now you should get sure it’s usable—in other words, your audience should visit the app and find it user-friendly. And if these people cannot use the application because it is too hard to use, too hard to understand, because it is too slow or there is no inherent logic in how the user experience is designed, then it is inappropriate to call the app a success.

It’s Immortal

Of course nobody expect your app to live forever, but that’s what you should reach for: robustness along the years.