Introductions

I am Margaret Siple (I go by Megsie) and I work at NOAA's Alaska Fisheries Science Center in the Groundfish Assessment Program. I live in Beacon Hill with two cats, Molly and Loki.

Introductions

Here is a brief poll so I can get to know you.

Work and research

A note about public resources in this presentation

Many components of this work were made possible by public resources, including 18F.

Why I learned Shiny

Why I learned Shiny

My team at AFSC uses many FISH 549 skills

Applied fisheries management can be like playing music

Each musician has areas where they’re very specialized, and areas where they are clueless

What we do is a combination of highly technical skilled work, creativity and multitasking

We’re all working together to try to make a big, beautiful thing happen

To successfully provide scientific advice for fisheries management, we need many components to work together:

1) Best available science (+ reproducibility)

2) Well-defined pathways for implementing advice

3) Trust and communication between researchers and stakeholders

Shiny can help us do these things and create something beautiful that communicates data and models in a new way.

Outline

1. shiny basics - when to use it, what it's good for

2. How to make an app

3. Lessons learned from developing a Shiny app for management advice

If you want practice or you learn well from hands-on examples, check out https://github.com/mcsiple/shinyoverview

There are many other things available in the repo that we won't cover today, but examples are included so you can try them on your own:

1. Live-translating your Shiny apps into other languages using {shiny.18n}

2. Using Shiny to teach remotely with {learnr}

3. Generating Markdown reports from Shiny

What is Shiny?

When is Shiny useful?

When we want to make R code accessible outside of an R or RStudio environment. For example,

• teaching people how to use a package

• giving non-experts a way to "get to know" models and data

• streamlining certain code-intensive activities (like summarizing and communicating simulation outputs)

Starting a new Shiny app

Install shiny:

install.packages("shiny")

From The RStudio IDE, pick New File -> Shiny Web App

You can choose between single (app.R) or multiple files (ui.R and server.R)

Does it matter which one you choose?

Not really. Some like the organization of having multiple files 🤷

Each Shiny app has two components

shiny::titlePanel("Here is a title")

<h2>Old Faithful Geyser Data</h2>

Each Shiny app has two components

shiny::titlePanel("Here is a title")

<h2>Old Faithful Geyser Data</h2>

ui.R

ui <- fluidPage(
    titlePanel("Old Faithful Geyser Data"),
    sidebarLayout(
        sidebarPanel(
             sliderInput("bins",
                        "Number of bins:",
                        min = 1,
                        max = 50,
                        value = 30)),
        mainPanel(
           plotOutput("distPlot"))
    )
)

ui.R

The ui code contains the following information:

1. The UI type

   • fluidPage() puts elements in rows that can include columns 🍰
   • navbarPage() has a navigation bar 📁

2. Layout elements (sidebarLayout() etc.)

3. Theme information (e.g., {shinythemes})

4. Output objects (plotOutput(), etc.)

5. Input objects (sliderInput(),fileInput() etc.) - also called "widgets"

Input objects link the UI to R code that runs on the server.

server.R

The server builds a list-like object called output. The contents of output can be displayed in the ui.

server <- function(input, output) { 
    output$distPlot <- renderPlot({
        # generate bins based on input$bins from ui.R
        x    <- faithful[, 2]
        bins <- seq(min(x), max(x), length.out = input$bins + 1)
        # draw the histogram with the specified number of bins
        hist(x, breaks = bins, col = 'darkgray', border = 'white')
    })
}

ui.R/server.R

The server builds a list-like object called output. output objects are displayed in the ui. Here is how they are linked:

server <- function(input, output) {
     output$distPlot <- renderPlot({
        # generate bins based on input$bins from ui.R
        x    <- faithful[, 2]
        bins <- seq(min(x), max(x), length.out = input$bins + 1)
        # draw the histogram with the specified number of bins
        hist(x, breaks = bins, col = 'darkgray', border = 'white')
    })
}

ui <- fluidPage(
    titlePanel("Old Faithful Geyser Data"),
    sidebarLayout(
        sidebarPanel(
            sliderInput("bins",
                        "Number of bins:",
                        min = 1,
                        max = 50,
                        value = 30)),
        mainPanel(
            plotOutput("distPlot"))
    )
)

What's on the server?

R code... mostly 😜

server.R

• Rendering functions (renderPlot(), renderTable(), etc.)

  • Build a new object to display every time the inputs change

• Reactive expressions are "lazy" - they don't execute unless they are specifically called to do something.

  • reactive() caches reactive objects so you can access them later in the server logic -- very important!
  • eventReactive() creates reactive objects but only when a specific input changes (e.g., a "Fit this model!" button is clicked)

• Observe expressions are "eager" - they automatically execute when their dependencies change. Expressions like observe() can:

  • autopopulate default values in a form
  • change the range for one input based on another input

The long (and rewarding!) path

• The Ocean Modeling Forum's request: a free, online app that would allow stakeholders to do a scenario analysis for a marine mammal stock of their choice
• International target audience
• Year 1: Consultation with scientists; building and testing the population dynamics model
• Year 1: Consultation with international stakeholders interested in the tool
• Year 2: Show app to actual web developers (humbling 😆)
• Year 2: Testing with students, stakeholders, other scientists, other developers
• Year 3(?): Publish R package and app in JOSS; present finished product

UI is worth your time

Shiny defaults are not the most intuitive / appealing / accessible version they can be.

If you are designing an app for management, a good UI is essential.

• my #1 tip: if you have time, pilot test with subject matter experts AND users

• use UX resources if they are available!

• if your institution doesn't have UX resources, design pilot testing so that you get helpful feedback on UX:

  • 18F Methods and Maze have great lists of testing questions and methods
  • 18F Methods also has an example agreement for testers
  • Depending on the final format, places like UsabilityHub have interfaces that will provide data on clicks and scrolling behavior when testing is remote
  • Check accessibility using the app's URL using the Web Accessibility Evaluation (WAVE) Tool

UX = user experience.

Quick poll

What material would you like to cover on Wednesday? Poll here