From Databricks to Posit Connect: Building and Deploying a Shiny for R Application

Creating the choropleth

The original data has UFO sightings around the entire world. But we wanted more detail than reports by country. The other reason was not knowing how each country subdivides itself (e.g., state, county, providence, etc), and finding the appropriate geospatial file for all the countries.

The plan was then to focus just on the continental USA where there are state breakdowns and further explore the individual points. We expected users of the application to be Americans and would look for areas directly relevant to themselves (e.g., where they currently live, their hometown, stereotypical UFO locations, etc.), and slowly drill down to a single sighting.

Providing the country-level choropleth gave the overall comparison between states and provided a means to provide state-level information on a click interaction. Shiny can interact with the {leaflet} package to react to clicks to make the rest of the reactive components in the application update.

We opted to show the overall counts at the state level because plotting all the observations in the country overplotted the points, and it was difficult to compare between states. Plotting the individual points at the state level gave a good balance between showing the total sightings and easily comparing them between states.

State observations

The overplotting issue at the country-level was alleviated by only plotting the observations at the state level. Since we are still using {leaflet} for plotting the observations, the user will be able to zoom into a specific geographic area to look for observations to click. The default OpenStreetMaps map overlay helps give context when exploring an unfamiliar region.

Separating out the state from the individual points is a cleaner way to show the information we wanted. Originally, we wanted to build off the SuperZip example, but it was impossible to clearly compare the relative number of observations between the 48 states. The choropleth and separate state plot made the exploration more linear and also gave us more room on the app to add in the text description of the sighting.

Individual reports

The individual reports were user-submitted text entries and had a wide range of lengths. This made it a bit tricky while planning the layout of the application because too little space would have a lot of scrolling or cut off the text, and too much space would create a lot of whitespace.

The layout of the application was mainly determined by how we wanted the text to be displayed. We had the two maps on the first row since that’s how English text is read, and a wide text area on the second row. This allowed any extra white space for smaller descriptions to be towards the bottom of the application and meant that there would be no awkward white space between elements of the application. The {bslib} layout allowed us to use the Bootstrap 12-grid system to layout the components, and also reflow in the order we want the user to interact with the application on a more narrow browser window.

Value boxes

Value boxes are a newer component in the {bslib} package. They allow us to provide quick bits of information into an application in an aesthetically pleasing manner. A lot of the information from the original data would be lost if we just showed the location and UFO sighting description. The value boxes allowed us to make use of the other columns in our data, mainly:

• The shape of the craft
• Duration of the encounter
• Date of the encounter
• Whether aliens were reported in the encounter

The value boxes provide an aesthetic way to bring attention to bits of information on the page. You can provide a title, value, image, and text in a valuebox. Since we wanted a way to distinguish between reports that reported alien activity from no activity, we needed to dynamically display the “Aliens Reported” value box with a different showcase image and text using the uiOutput() function.

The current version of {bslib} does not allow a reactive text input to be placed in the theme parameter of the value_box() component. So we created a reactive output component with renderUI(). Here we looked at the user description for the existence of alien related keywords, and if any of the keywords were detected, we would return a value_box() component with a green background with theme = "success" instead of the blue theme = "primary" that were used for the other value_box() components.

Filtering results

Since one of the value_box() components detected whether or not there were aliens reported in the selected sighting, we wanted to expand the ability for users to look for their own keywords. Shiny’s reactive programming means that we can shim in a keyword search to filter down the underlying dataset used for the application without needing to change the logic for the entire app. Since the data filtering parameters are not part of the main application, we wanted to hide the filtering features in a sidebar so it does not detract from the main application.

When working with a reactive textbox to filter data, unless the text returns a match, you will end up with an empty dataframe result that causes problems with the rest of the application. The same set of problems can happen if you mistype a word, do not type fast enough, correct a spelling error with backspace, etc. You can fix this issue by creating a “search” button that triggers the filtering only when the button is clicked. Since we also have a date range filter, we can set all the filtering variables before the application reactively responds to the user’s inputs. We do this by creating an actionButton() component in the UI, and looking for a button click with observeEvent() in the server. When there are no results, we also wanted to let the user know by displaying a dialog across the screen with modalDialog().

Tracking the currently selected point

When we are only using leafletProxy() to draw red circle markers on a user click, each click will result in a red dot, but all subsequent clicks will create more red dots without clearing the previous red point until the entire state map is redrawn when a state is clicked on the choropleth country map. In addition, simply removing the red marker on a new click, would remove the old sighting from the map entirely. So, as the user interacts with the state map, fewer points will be shown, and they will not be able to click on a previously clicked sighting.

To fix this, we need to actually track 2 points, the currently selected point, and the previously selected point. We can create two reactive values using reactiveVal() that track the current and previous values.

   ## initial sighting to display
    featured_sighting <- reactiveVal({
      ufos_usa |> filter(id == "30")
    })

    featured_sighting_previous <- reactiveVal({
      ufos_usa |> filter(id == "30")
    })

When a user clicks a point, the current sighting becomes the previous value, and the newly clicked point will take the place of the new current sighting.

    ## when the user clicks a sighting
    observeEvent(input$state_marker_click, {
      featured_sighting_previous(featured_sighting())
      featured_sighting(ufos_usa[as.numeric(input$state_marker_click$id), ])
    })

Now when we are using leafletProxy() each UFO sighting click will always redraw the previous sighting in the default blue color and draw the currently clicked point in red.

   observe({
      leafletProxy("state", data = featured_sighting()) |>
        leaflet::removeMarker(layerId = featured_sighting_previous()$id) |> # remove the precious marker
        addCircleMarkers(
          lng = featured_sighting_previous()$city_longitude,
          lat = featured_sighting_previous()$city_latitude,
          popup = featured_sighting_previous()$summary,
          label = featured_sighting_previous()$summary,
          radius = 1,
          layerId = featured_sighting_previous()$id
        ) |>
        addCircleMarkers(
          lng = ~city_longitude,
          lat = ~city_latitude,
          popup = ~summary,
          label = ~summary,
          radius = 5,
          layerId = ~id,
          color = "red"
        )
    })

This gives a user interface where it is always clear from the initial application load which UFO sighting description is being looked at. You can browse through the server.R file for the app for the full context.