Register for Appsilon & RStudio’s Community X-Session: Enterprise Shiny Apps from Concept to Production
Shark Attack is an environmental video game designed and built by Appsilon engineer Marcin Dubel. Marcin’s creative approach to raising environmental awareness and ingenious methods for implementing his Shiny video game has earned him a Grand Prize at the 2021 RStudio Shiny Contest.
Each year the competition becomes tougher with submissions from around the globe. Developers are implementing Shiny in innovative ways, providing unique solutions to a wide array of issues, and pushing the limits for what’s possible with Shiny.
Usually, when working on a Shiny application, the idea and content are predefined in the project. However, in a contest, you have free range to build your dream application. That is a blessing and a curse.
I wanted to participate in previous editions of the RStudio Shiny Contest, but I never found my dream idea. Unsurprisingly, this time around, my initial idea still wasn’t up to par. Yet, I proceeded anyway. So even if you feel that your planned application is not a perfect one, I encourage you to start and adjust as you go. Worst case scenario, you’ll have some fun and practice Shiny along the way.
My initial idea was to create a dashboard presenting global shark attack data (yup, that’s where the name originated from – I decided that it was catchy enough to keep). I started gathering the data, information, even building the dashboard until… I realized all I was making was just another dashboard. Even if I created the fanciest dashboard you’d ever laid eyes on, it would still be built around easy-to-google data (and likely to be better presented).
I still wanted to do an app connected with sharks (possibly because I recently saw “Jaws” for the first time), but I needed a better idea. I recalled that my friend Pedro won the Contest last year with another game created in Shiny [Shiny Decisions]. The game was really fun to play so I thought that I’d try to create something similar.
In the first version of my game, the purpose was to collect sunken treasure. The diver collected a key to the chest while avoiding sharks. I made a lot of progress with that idea in mind. However, after working on the app (and going through dozens of test runs), I realized that the game was not engaging for the user.
There was no real purpose, nothing that made players care about success in the game. I thought about the mislabeling of sharks as aggressors and the damage caused to ocean ecosystems and realized maybe the sharks could be angry about all the trash in the ocean!
This new idea made something click, and the Shiny video game started to flow better. That’s another lesson learned: if you work on a topic that interests you, the tasks go smoother.
An important reason why I gave up with the shark attack dashboard – the data. Collecting, cleaning, maintaining, checking, updating the data is always a big chunk of any project. During regular work hours, you can spend enough time to make it right. And as any good data scientist knows, this is a crucial part of the application.
Make data validation a breeze with Appsilon’s data.validator package
In the case of a contest, there’s simply not enough time to do this correctly (I assume that you also create the app after hours). All the hard work you did to get the correct data into the app won’t be visible to the judges. The final effect is what matters and creates a great impression. Even if the jury digs down deep enough to spot all of your hard work in the backend, it’d be hard to recover from the first impression.
Of course, this does not apply to all cases – I can imagine datasets so unique, interesting, and clean that it could be worth it to build contest apps around them. Whenever you are considering an app like this, adjust your plans to this additional risk factor.
So far, I’ve discussed the challenges related to the unknown scope and limited time for building a contest app. With that in mind, you should start early, long before the deadline. Give yourself space for adjustments and changing the plans. Often, I had just 30 minutes a day to work. Yet, it was crucial to keep making progress, to keep thinking about improvements and implementation.
To keep your work organized, write down tasks in a planner. I used a Github project connected to my repository – whenever I had an idea for a single feature of the application, I wrote it down and prioritized it. Prioritization is the key. You can’t afford to waste time on some minor, nice-to-have feature while your app is still not doing its main job.
Another crucial rule you may know from big development projects: separate work into small, independent tasks. This allowed me to implement some features while being stuck in another branch. Also, it helped to optimize the workday (e.g., dealing with quick and simple tasks when I didn’t have much time).
To avoid wasting too much time, start your work with a Proof of Concept – the minimal application that checks if key technical challenges can be overcome. If it doesn’t work, you still have enough time to turn around and change the scope. If the plan is impossible or too complicated to implement, you will need to cut your losses.
Each colored icon represents a different object; the yellow icon is the diver, the red is the treasure/trash, and the blue is the shark. The envelope is an icon that I had available from a previous project. Details are not important at this stage of the project. Once completed, I was sure that I could proceed with the idea.
Along the way, there were other challenges, like adding multiple sharks or different trash classes of moving objects. But from the very beginning, I paid special attention to the code quality. This allowed me to easily overcome challenges throughout the project. Often, we sacrifice this during the initial stages of a project with the “we can fix it later” approach, but this is wishful thinking. And technical debt accumulates, making further progress slow and painful. While working on Shark Attack, I was often surprised and satisfied seeing the initial extra effort of making functions clean. The general payoffs while extending the features were well worth the effort.
Improve your code with 5 Tips for Writing Clean R Code
The backbone of the clean code in the Shark Attack is the R6 class. R6 is an advanced object-oriented programming implementation for R that I consider a perfect match for Shiny applications. The concept of objects, their properties, and methods, can be applied to multiple parts of the app, like dataset, user info, or in my case, grid, trash, or score. Note that classes can inherit the methods to reduce code duplication (e.g., trash is controlled by the class, which is a special implementation of the more general class for all objects displayed on the grid). For the UI parts, remember to use modules – this is a way to keep app components separated and easy to maintain.
Remember, you know your app inside-out. However, the users or jury will enter it for the first time. And fresh eyes tend to uncover a lot of unintuitive, redundant, or missing features. They might use the app in a very different way than you expect. Don’t wait till the last minute to show your progress to a broader audience. You need to have enough time to implement the feedback that you receive.
And I don’t mean some sophisticated user feedback collection sessions – just show the current state to your friends or family and ask for their opinion. In commercial projects, this is often referred to as a “hallway test” because the point is to spend 5 minutes with your colleague and ask about the most basic feedback. It does not require any technical knowledge exchange.
Learn how Appsilon conducts user tests for enterprise Shiny dashboards
In my case, a friend mentioned that having a global shared leaderboard would be a nice touch. I was thinking about it but decided that it was not worth implementing – comparing the effort to gain. However, when I got such a request from three more sources, I began to see value for the user. Ultimately, I implemented it – albeit at the very last moment. The user feedback here was quite valuable, not to mention all the other bugs and fixes that they help me to find.
Whether a beginner or an advanced Shiny dev, I highly encourage you to take part in RStudio’s Shiny Contest next year. You can try your hand at a Shiny video game or gain inspiration from the hundreds of RStudio Shiny Contest applicants. The path to success is more of a trial and error, rather than a perfectly aligned plan. But these are opportunities to learn and grow as a developer. And who knows, maybe you’ll create the next best Shiny video game or something wholly unique!
If you’re interested in a deeper dive on how to create an award-winning Shiny video game or an enterprise-level Shiny dashboard, register here for the Appsilon and RStudio joint X-Session: Enterprise Shiny Apps from Concept to Production. The selected presentations in the webinar provide Shiny devs of all experience levels with something of value. So whether you’re a Shiny beginner or an advanced developer, you can level up your skills with the Shiny experts at Appsilon.
Appsilon provides innovative data analytics, machine learning, and managed services solutions for Fortune 500 companies, NGOs, and non-profit organizations. We deliver the world’s most advanced R Shiny applications, with a unique ability to rapidly develop and scale enterprise Shiny dashboards. Our proprietary machine learning frameworks allow us to deliver Computer Vision, NLP, and fraud detection prototypes in as little as one week.
Discover our growing list of open-source R Shiny packages at shiny.tools. If you find our open-source packages useful, please consider dropping a star on your favorites at our Github. It helps let us know we’re on the right track. And if you have any comments or suggestions, swing by our feedback threads like the discussion at our new shiny.fluent package or submit a pull request. We value the R community’s input.